« HS-CMS documentation home

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

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 type of “authored” are listable by list-generating pages (indexes, sitemap, navigation menus, etc.) such as one that, say, searches for pages with a certain tag. By default, they are shown in news feeds (RSS), visible to search engines, and cached as a rendered whole.


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 index_friendly); they may be hidden from search engines; and they certainly never show up in news feeds (RSS), at least by default.


Applications, or pages with type = “app”, take command of all URLs beginning with their own and ending with anything under the moon, as long as there is no more-specific page of another type. Example: app “foo” does not get “foo/bar” if “foo/bar” is an actual page.

By default, pages of type “app” are visible to search engines and listed in sitemaps and navigation structures. By default, they are not shown in news feeds (RSS) and not cached as a whole. They also will not be cached.


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 type = “dynamic” page with uri of “test” would not respond to “test/foo” even though the exact same page with type of “app” would (assuming “test/foo” is not its own page). Dynamic pages are also not cached.


Make a request act as if it was a request for another page.

By default, these are hard redirects (with HTTP/1.1 301 Moved Permanently as the status header and a Location: header).

Soft redirects can be achieved by setting the format to soft.  There is no reason to set format to hard as that is the default (and generally preferred, for SEO and bookmarking and tracking reasons) redirect method.

Pages’ file column value is the URL/URI that an alias redirects to. For internal redirects and all soft redirects, it must correspond to the format of the url column (flexibly, so app-type pages still work properly). E.g., if you move from a Drupal site, you may want to add rows to the pages table such as a url of node/4, type of alias, and file like full/nice/path where the page is really on http://yoursite.com/full/nice/path (and was formerly available at http://yoursite.com/node/4 thanks to Drupal being stupid about URLs). 

To be clear, if the file column value starts with “http://”, then an external redirect (301) occurs.


Pages like “About me,” “about us,” etc. which are not considered blog entries or readily taggable, categorizable, etc. These are, of course, cached.


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:

  • Inclusion in sitemap / search engine awareness
  • If user attempts to go to a non-existent page spelled almost like the representative, they could be redirected to it
  • They can be listed, tagged, given descriptions, and placed in menus (just like pages handled by HS-CMS), making your site easier to navigate and more cohesive.

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!


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.


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 type of “authored”; wiki pages show up in news feeds, indexes, search engines, and the like, and they are cached fully rendered (if the person logged in isn’t editing them, basically). Visibility rules are believed to be currently working already, just not group editing. Can be cached, at least for GET requests.