Many of the specifications you update in GenHelm are used to create entire web pages. You can tell that a model is associated with the creation of web pages by the fact that you will see Common Page Properties as part of the specification. This help explains how these common page properties are used.
Most of your pages will be defined as type Normal Page. This just means that there is no special handling required for the page.
If you are defining the default page for the site, you can designate this as the home page. This is normally the page that is shown when no page identifier is specified in the url. Note that it is actually the default page indicated within the site_settings that controls which page will be shown.
If this page contains links to all of the pages of your site, you can designate it as a sitemap page.
The form model allows you to build a series of pages that must be traversed to complete a logical unit known as a transaction. If the page is designated as type Transaction Start, you must specify a transaction name as one of the form specification parameters. Note that, in this context, a transaction differs from a database transaction.
This page type should be used for the second and subsequent pages of a transaction series. So the first page is assigned type Transaction Start and the second page is assigned type Transaction Next, as is the third page, etc. Pages of this type cannot be navigated to directly and won't be indexed by search engines.
If this page is intended to be part of a simple blog stored on the file system, choose this option. When doing so you must also enter the Simple Blog Properties indicated further down in the common page parameters. Refer to the Database Blog Overview help to learn about the different types of blog pages.
This option should be used if the current page is not intended to be a page that can be accessed directly from a web browser but rather is part of another page that is embedded using the $page function. When the page is designated as a component, many of the remaining fields do not apply.
Occasionally you may want to serve the same URL with different versions of content depending on whether the user is visiting the page from a mobile phone vs. a large screen device. If the current page has been designated as a Desktop Alternate Page of a partner mobile page, you must designate this page as such. Many of the remaining fields do not pertain to Desktop Alternate pages.
Most pages will allow direct access from a web browser. If this page is designated as a page component, you will normally not allow browsers to access the page directly. You may want to allow this temporarily in order to facilitate the development of the page component in isolation of its container.
If a page becomes obsolete, it is recommended to keep the page definition but redirect the page to a different page of your site. When using one of the redirect settings you must also specify a Redirect To page value. Try to choose a page whose content closely matches the deprecated page. When choosing the permanent or temporary redirect option many of the other fields do not apply however you must supply the name of the page that you want to redirect to.
Occasionally you may develop components that are not intended for production use. For example, you may build pages to generate test data or to facilitate debugging. These pages can be designated as Sandbox Only pages. In so doing, the pages will not appear in promotion search results and, even if they are accidentally promoted, it will not be possible to load these pages within a production environment. We recommend naming these pages starting with an underscore to make it clear to developers that these are Sandbox Only pages. You can also use this designation for pages that are intended for production but are not yet ready for production use. This will prevent such pages from being promoted until the Sandbox Only status is removed.
This value is used to build the title tag for the page and, as such, is very important to SEO. Keep the title short and focused on the main topic of the page. Note that the actual page title may be prefixed or suffixed with the company name (or other information) indicated in site_settings (depending on options specified using the site_settings model). Sometimes you want to override this behaviour set at the site level. This can be done by prefixing the title with a "!" character. This tells the system to use what follows ! as the exact title, ignoring any prefix or suffix indicated in site_settings.
The title is not used (at runtime) for pages that are defined as page components or desktop alternates.
The short link text is used when generating links to the page when the length of the link is constrained such as on the navigation bar or menu. As a shortcut you can use =t to set this to match the title, =h will set it to match the header.
This field is used to define the contents of the h1 tag for the page (assuming your layout supports such a tag). If you don't want an h1 on the current page, leave this field empty. You can make this equal to the title above by entering =t.
The long link text is used to build links to the page is situations were the link length is not constrained. Use =t to set this to the title value, =h to set this to the header value or =s to match the short link value.
This is used to generate the title tag associated with links to the page. The title tag is shown when the user hovers their cursor over the link. Note that mobile devices do not support a hover event so this text will not be shown on phones and other such devices.
Sometimes you can serve many pages using the same main definition. For example, let's suppose you have several pages of your site that show a Google Map where the only difference is the lat/long associated with the center of the map. To handle situations like this (without having to repeat all of the details of the map definition), the system allows you to create a single page (or page component) to specify the map. This map page can then be "pointed to" by all of the other pages just by filling in the Based on Page value within the related pages. The map page would need to be "fed" the lat/long value from the other individual pages. Often this is done by setting Internal Parameter values (see below).
This option should only be set when developing multilingual sites. For such sites, the default language can be set within the site_settings specification. This language can be overridden at the page level for pages written in other languages.
In some cases, the mobile (phone) and desktop (non-phone) versions of a page are so different that it does not make sense to implement these using the same specification. For example, let's say the mobile version of the page is just a single column but on the desktop version you want to define several related columns. Rather that trying to achieve this using CSS Media Queries, you could just specify on the mobile version of the page that there is a Desktop Alternate Page. In such a case, this alternate will be used to render the page for users who are on a desktop device. The same URL will be used for both versions of the page.
Certain pages of your site may contain confidential or secure information that you don't want users to access directly (without going through a controlled link or redirect). Use this option to force links to these sensitive pages to be encrypted. This will obfuscate the URLs to these pages and make it difficult for users to manually navigate to the page or change the content of the querystring to access information that they are not permitted to view.
If access to this page is only permitted for registered users who are logged in, check this field.
By default, all pages of the site will be set up to allow indexing except for the following pages:
Additionally, you may want to generate the noindex directive for pages with little SEO value. Keep in mind however, that links to pages defined as noindex are still allocated a portion of the pagerank passed on by your page so this "link juice" is effectively squandered when linking to pages that are not indexed. All pages flagged or implied as noindex will not be generated into the default xml sitemap so it is a good idea to check your sitemap before launching a new site to make sure that all of the pages listed are intended to be accessed via search engines.
By default, every page is generated with a canonical link to itself. If the page you are building is very similar to another page or if the same page can be accessed with different URL parameters but show similar content, you should point all versions of the page to the Canonical Page that you want to be indexed by Search Engines. Basically, by filling in the Canonical Page you are telling search engines not to give the current page much weight because it is very similar to another page that is more complete or important. This option helps Search Engines decide which pages to favour and helps avoid duplicate content penalties.
If the canonical page indicated requires a query string (set of URL parameters) enter these here. During testing, be sure to use the browser's view source or inspect options to review the generated canonical link and make sure that it references the desired link noting that this will be a sandbox link in the sandbox but will change to a live site link in production.
One of the powerful features of GenHelm is that it allows you to specify a special layout when rendering on phones and other small mobile devices. This eliminates a lot of complex CSS Media Queries and improves overall site performance. In most cases you will leave this field empty since your pages can often default to the mobile layout specified at the site level. Occasionally, you will need pages with special layout requirements and for these pages you can override the layout by entering an alternate mobile layout name here.
For pages where the default desktop layout specified in site_settings is not suitable you can override the layout using this field. For responsive sites (that have the same mobile and desktop layouts) you can enter =m to default to the mobile layout indicated above.
If the page type has been set to one of the redirect options, this means that the current page has been deprecated and it is necessary to specify the page to be redirected to. This will generally be a page that is similar to the current obsolete page. If no suitable page exists you can specify the home page of the site.
If parameters are required for the page you are redirecting to, enter these here.
It is best to place most of your style definitions in a common css file so that they can be shared across your entire site to ensure consistent styling. Nevertheless, there will be cases where you want to style elements that only appear on one page so it is unwise to add this styling to the shared css file since this needs to be loaded for every page of your site. In such situations it is best to add local styling that only applies to the current page. These styles will be rendered inline in the current site. Since these styles are defined after the common stylesheets, you can also use this area to specify page-specific overrides to common styles.
This field can be used to enter JavaScript that is specific to the current page. Normally JavaScript is saved in separate script files so that it can be shared by other pages. However, there may be cases where your script is very specific to one page and in this case you can code it on the page specification itself using this field. The script entered here will be placed at the end of the html (just before closing the body tag).
A common pattern for web pages is that you have some introductory text, followed by some main content followed by some summary text. The preamble section is used to supply text to introduce the main content of the page. It is placed above the main content in a separate div tag. The postamble section is added below the main content in a separate div tag. Both the preamble and the postamble text can include dollar functions.
By default, the preamble and postamble text is rendered as is. Therefore, if you want to create your own html tags within these sections you are free to do so. If these sections contain simple text, lists, sub-headings, etc. it is possible to have them embellished with suitable html tags automatically. Please refer to the help associated with the markdown model to learn what syntax you should use to format the preamble as markdown.
Check these options to automatically format the preamble and/or postamble according to the markdown rules.
To add one of more classes to the div generated to contain your preamble and/or postamble, enter the class names here. You will need to define the styling of these classes within one of the style sheets used by the page or within the Local Styling field.
The wrapper tag allows you to wrap the preamble, main content and postamble within a container tag. To do so, choose the html tag that is most suitable according to the content of the page.
If you have specified a wrapper tag to be used, you can use this field to add properties to this tag.
This feature depends on the layout being used by your page. Most layouts contain an H1 tag near the top of the body section. When supported, you can move the header into the wrapper tag and indicate the heading level that you want to use for the heading.
The feature can be used for page components to allow the header value to be generated as part of the the component.
Internal parameters allow you to add extra settings at the page level that can be used to refine the contents of the page. The parameters are expressed similar to a query string, that is using keyword=value pairings separated using &. For example: price=95&color=red might be used on a generic product page to control certain values used in the page content. To render this content you would use the $iparm function. For example, $iparm(color) would render as red in this scenario.
Internal Parameters are often used on pages that also have a "Based on Page" value set since these parameters can be used to configure the base page.
By default, all dollar functions defined within the page content will be parsed and converted into the value returned by the dollar function. Occasionally, you may create a page wherein you want the dollar functions to be preserved. For example, if the page represents help for dollar functions you might want to show the dollar functions without having them execute. Another way you can achieve this us to use the html entity $ instead of the $ symbol.
This field allows you to render pages having a certain extension. For example, if you want to render all of your pages using the .html extension you could enter html as the extension of all of your pages. The more common use case for this is to render pages such as sitemapindex.xml which are generated dynamically using a custom page definition.
For some pages you may want to generate links that include parameters in the URL. In such cases, enter the desired parameters here. These URL parameters will be generated for all link references to the page. If this field begins with http: or https:, this value will be treated as an entire URL. Therefore, any $link references to this page will link to the indicated URL.
There is another use for URL parameters which requires a detailed explanation. Follow this link to learn about automatically converting folder-based URLs to querystring parameters.
Open graph is a system developed by Facebook to classify web pages. You can enter any "og" tags you that want in the Page Specific Meta Tags section. For convenience, you can also automate the creation of many of these tags. If you want to do this on most of your pages, check the Generate Open Graph Tags option within site_settings. The like named field defined at the page level is used to override what has been set at the site level. You can set this value to one of these options:
Note that this option only applies to automatically generated open graph tags. If you explicitly enter "og:tags" in the Meta Tags section, these will be generated even if automatic generation is set to No. The same is true of the og:image tag, this is triggered by the presence of an image in the Open Graph Image field.
Let's review which og tags get generated:
If the current pagetype is indicated as a Simple Blog Page the og:type will default to "article", otherwise it will default to "website".
The og:description value will be defaulted to the meta description, if supplied.
The url field will default to the current url.
The sitename will be taken from the _Open Graph Site Name specified in site_settings (if present).
The og:title will be defaulted using the page title.
It should be noted that any of these defaulted values can be overridden by hand-coding an alternate value within the Meta Tags specification section.
You may designate an image that will be referenced in the meta tags section for the purpose of instructing Facebook and other social media sites to show this image when referencing your page. Enter the id of an image to be used for this purpose.
Specify the size of the image to be used in the social media meta tags for the image indicated above. Facebook enforces a minimum image size of 600px x 315px so make sure the image you choose is larger than this if you want it to be shown.
This can be used to provide hint to search engines as to how frequently the content of the page changes. This will be generated into the xml sitemap definition for the page.
This is also generated into the xml sitemap and can be used to inform search engines of the relative importance of the page.
Simple blogs are used to define lists of pages associated with a certain topic or category. These simple blogs are defined within the native file system, there is no need for a database as is the case for a complex blog. Any page-oriented model can be used as a blog page. Pages don't have to be strictly blog pages. In fact, this help page was created as a "blog" called help.
The blog parameters described below are only used for pages indicated with page type Simple Blog Page.
The system allows you to create any number of independent lists stored within blog folders. These folders are stored under the private_data blog folder. If you don't enter a blog identifier, your blog will be stored under the blog/blog folder. Otherwise, the identifier you enter will reflect the name of the folder to be created under the blog folder.
The post date is used to control the sequence that the posts will be shown. The latest posts are shown above older posts. There is no requirement to show this post date but it must always be entered in order to control the post sorting. If your blog is not updated frequently, you might not want to show the post date since this can "age" your site if your visitors see that the "recent" blogs are actually very dated.
If you want to associate an author with the blog posting, enter this here.
For Meta Tag help visit Meta Tags.
Packages are created using the package model and they allow you to group CSS and JavaScript references within a reusable object. Certain package definitions are supplied with GenHelm. For example, the bootstrap package combines the CSS and JavaScript references required by Bootstrap. Therefore, if you want to base your site on Bootstrap you can simply add the bootstrap package reference to your site settings rather than having to know names of all of the individual CSS and JavaScipt Files. Packages also make it easier to upgrade your sites to newer versions of these files since you only need to change these references in one place.
For CSS and JavaScript help please visit Styles and Scripts.
Function access can be used to add function security to your site. This only applies to pages which require a login. For such pages you can assign groups and roles to your users and specify which groups and roles are allowed to access the page. To learn more about function access, refer to the help associated with the user model.
These settings are used to configure the page for models and other objects that allow certain settings to be specified using configurations options. Learn about some of the common Runtime Config Settings.
| GenHelm Architecture | GenHelm Architecure. |
| Why GenHelm? | Summary of the GenHelm methodology. |
| Getting Started | Learn how to start a new website. |
| Naming Conventions | Naming web pages and other items. |
| Common Web Page Fields | Descriptions of fields that are common to all page models. |
| Layouts | Defining codeframes and layouts. |
| Styles and Scripts | Descriptions of fields that are common to all page models. |
| Meta Tags | How to configure meta tags for your site and specific pages. |
| Dollar Functions | General information about dollar functions. |
| Navigation Tips | Navigation Tips and Techniques |
| Favourite Icons | How to configure favorite icons for your site. |
| Blog Maintenance | Blog and post administration. |
| Direct Command Help | Help for the direct command field. |
| Programming with GenHelm | Writing programs that interact with the GenHelm framework. |