Types of Pages in HS-CMS
It should be noted that the term "Pages" is used loosely. Drupal might call what we call "Pages" by a number of names, such as "nodes," "stories", "pages", or even "aliases". Ruby on Rails would occasionally call pages "applications." This is because the HS-CMS "page" can be anything from a static web page, to a dynamic page, to an application which handles URLs downstream from it (i.e. example.com/application/called/for/id/4), to a representative of a page not handled by HS-CMS at all, etc.
Here we attempt to list everything an HS-CMS page could possibly be, and how these are kept straight in the "Pages" database table under the "type" column.
Please note that the default behavior by page type
is listed below, but it can be overridden on per-page basis.
Database value | Description |
---|---|
authored |
A typical website page, blog entry, or anything else that is fundamentally (but not necessarily entirely) static content made for reading and has an author. Typically this kind of page is categorizable and not an "about" page or anything like that. Most certainly, this type is meant to exclude 404s and other error pages not "meant" to be read or searched for. By default, pages with |
error | Error pages, such as a custom 404 file-not-found or 403 forbidden
handler, are, by default, never shown in any
public lists, menus, or sitemaps (e.g. not |
app | Applications, or pages with By default, pages of |
dynamic | Dynamic pages are just like app pages in terms of default behavior except that they do
not respond to requests for URIs that start with their URI. A |
alias | Make a request act as if it was a request for another page. By default, these are hard redirects (with Soft redirects can be achieved by setting the Pages' To be clear, if the |
static | Pages like "About me," "about us," etc. which are not considered blog entries or readily taggable, categorizable, etc. These are, of course, cached. |
representative | Representatives are just that: Not actual pages, but representatives of them. They should be used when HS-CMS would benefit from being aware of pages outside its control. While at first this might sound silly, you get the following, totally-worth-it benefits:
Naturally, representative pages will probably have empty and non-applicable columns in the Pages database. Obviously, they won't have a stored content location defined, or a custom skin, etc. If this paragraph is still here, there is probably not a "representative importer" tool, but there should be. Whine for one at https://alanhogan.com/contact, please! |
index | Automatically generated lists of other pages. Not yet fully implemented. By default, they do not show up in news feeds, but are search engine friendly and themselves show up in indexes like sitemaps and navigation menus. They can run dynamic content, yet their output is cacheable, since indexes should not theoretically be changing often. |
wiki | Pages which may be edited by a group of people or the public. Not yet implemented.
Aside from editing permissions, behavior is just like that of pages with a |