We're probably oversimplifying things by dividing websites into static and dynamic without considering other techniques such as the one you highlight.
If we look at things from the point of view of the server we can ask whether or not it allows mutation. Even a non-mutable server - one where all the internal files are read-only - can still run local scripts to deliver responses. Pages can be constructed by PHP scripts or stored pre-rendered to achieve a quicker response at the cost of more storage. In principle, such a site could run off a CD-ROM.
Another distinction is around whether a site permits interactivity between its users - an important feature of many dynamic sites. A static, non-mutable site, though it may deliver an interactive experience, can't let one user talk to another as this requires mutation of the server state (the database, usually).
You can get around this by using a third party, allowing the core functionality of your site to be kept static (non-mutable). For example, when hosting services offer database access they usually provide it on separate computers, so the pattern is well established.
In your comment you say that some sites do dynamic pre-rendering to provide pages that are stripped of all interactive features other than traditional hyperlinks. This amounts to a dynamic website voluntarily restricting itself to providing static, immutable content (albeit for good reasons).
So after struggling with this answer for well over an hour I have now reached the conclusion that to just say "static" and "dynamic" is over-simplistic. Most of the options are a lot more complex than that. I often find that as soon as we try to label and classify things they tend to sprout a host of exceptions, and that seems to be the case here.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We're probably oversimplifying things by dividing websites into static and dynamic without considering other techniques such as the one you highlight.
If we look at things from the point of view of the server we can ask whether or not it allows mutation. Even a non-mutable server - one where all the internal files are read-only - can still run local scripts to deliver responses. Pages can be constructed by PHP scripts or stored pre-rendered to achieve a quicker response at the cost of more storage. In principle, such a site could run off a CD-ROM.
Another distinction is around whether a site permits interactivity between its users - an important feature of many dynamic sites. A static, non-mutable site, though it may deliver an interactive experience, can't let one user talk to another as this requires mutation of the server state (the database, usually).
You can get around this by using a third party, allowing the core functionality of your site to be kept static (non-mutable). For example, when hosting services offer database access they usually provide it on separate computers, so the pattern is well established.
In your comment you say that some sites do dynamic pre-rendering to provide pages that are stripped of all interactive features other than traditional hyperlinks. This amounts to a dynamic website voluntarily restricting itself to providing static, immutable content (albeit for good reasons).
So after struggling with this answer for well over an hour I have now reached the conclusion that to just say "static" and "dynamic" is over-simplistic. Most of the options are a lot more complex than that. I often find that as soon as we try to label and classify things they tend to sprout a host of exceptions, and that seems to be the case here.