| v3 | v4 |
|---|---|
| section > page > content > content_data | content > revision > view |
| section.parent_id, page.parent_id, content.page_id | content.parent |
| content_data.content_id | revision.content_id |
| page.template_id | content.template |
| page.parent_id (for alternate pages) | content.master |
| section.template_id | n/a |
| page filename=index.html | section |
Note that the home page of a section is the section itself, not a special page named “index.html”.
Content objects are related to each other in 3 ways:
| v3 | v4 |
| foo.com/contact.html | foo.com/contact |
| foo.com/directions.html | foo.com/contact/directions |
| foo.com/cgi/page.cgi/directions.html | foo.com/cgi/ex.cgi/page/contact/directions |
| foo.com/map.jpg | foo.com/contact/directions/map.jpg |
| foo.com/cgi/content.cgi/map.jpg?id=1234 | foo.com/cgi/ex.cgi/view/contact/directions/map |
| foo.com/_Library/images/picture.jpg | foo.com/images/picture.jpg |
| foo.com/_Template/base/stylessheet.css | foo.com/base/stylessheet.css |
Each content object has a path, defined by its parent-child relationships. The path is used for addressing the content in dynamic queries, as well as for publishing the content to disk.
Each type publishes either as a directory or as a file. If as a directory, then the content can be viewed at its path:
http://foo.com/path/to/content
This is equivalent to:
http://foo.com/path/to/content/index.html
but the “/index.html” is optional, and usually left off to simplify the URL.
If the content is published as a file, then it can be viewed as a filename at the path of its parent:
http://foo.com/path/to/content/filename.html
Since each content type has control over its own publishing, these default rules can be bent. For example, calendars can publish their events to special dated subdirectories, for example:
http://foo.com/calendar/2012/09/event-X.html
In this example, the calendar publishes to the directory /calendar/ and the individual events publish to files, eg. event-X.html. But the calendar first creates dated subdirectories to hold these events.
If a content item is restricted access or dynamic, then the published version still exists, but consists of a redirect to the dynamic version. So the static URL always works for GET requests.
The dynamic URL to a page at path /foo/bar is
http://foo.com/cgi/ex.cgi/page/foo/bar
The dynamic URL to content at path /foo/photo is
http://foo.com/cgi/ex.cgi/view/foo/photo
This will display the “bare” content directly. To display the content formatted (in the style of a page), simply change this to the page-style URL:
http://foo.com/cgi/ex.cgi/page/foo/photo
This does not actually make it a page; it merely formats it as a page, with HTML wrappers, menus, etc. surrounding the content.
Note that any content object can define its own custom URL. This can be a remote URL (eg. you can create a “page” in your menus that actually links to a remote website), or it can be a local URL (which needs to either make sense to the webserver, or needs to be configured separately using some kind of server alias).
You do not have to specify whether content should be static or dynamic. ExSite 4 content objects can intelligently make their own decisions about their presentation mode, by using their own internal logic to respond to the publish_rule() method (which can return static, dynamic, hourly, daily, or weekly). You can still manually set a publish rule for a particular piece of content, but that overrides the logic of the content class.
Examples: Member-only content defaults to dynamic, since it depends on the access level of the person viewing it. Calendars default to publish daily, since that is when the upcoming events listings may change. Events accepting registration default to dynamic before the event, so that fee deadlines and sellouts are displayed accurately, and static after the event is done.
Note that HTML content may include plugins; in that case, those plugins are queried using $module->ioctl("PublishRule") to find out if the plugin recommends a particular publish rule. For example, menu plugins can reply with "static" since menus are always the same on a particular page. Pages without a manually set publish rule will use the most dynamic publish rule requested by the plugins contained in that page.
The permalink to a content object is the “best” user-friendly URL to the content. This can be a relative, static URL, even if the content is ultimately delivered dynamically. Permalinks should generally be used for URLs that are targeted at people, such as internal hyperlinks and published URLs.
Permalink Example: /sale
The Canonical URL to a content object is the most direct absolute URL to the content. If the content is ultimately dynamic, the canonical URL must also be dynamic. Canonical URLs should be used for search engines, so they access the content directly.
Canonical URL Example: http://foo.com/cgi/ex.cgi/page/sale
Canonical URLs are determined automatically. However ExSite 4 also supports a manual override: allow a content type to define metadata under the name "canonical", and that will be used instead. This might be useful if referring to off-site URLs.
| v3 | v4 |
|---|---|
| content_data | revision |
Each content object can have multiple revisions. In v3, there were two special revisions, newest and active. In v4 there is the additional concept of a draft revision:
When saving a new revision, they will automatically be saved as a “newest” revision, unless you “save as draft”.
In ExSite 4, no actual content is stored in the revision record. The revision record contains only the creation and publication timestamps, original mime-type, and comment. The content itself is stored in the views.
| v3 | v4 |
|---|---|
| content_data.data (or fdata) | view/normal |
| content_data.thumb | view/thumbnail |
Each revision can have multiple views. A view is simply a viewable representation of the content. ExSite 3 supported only a single view of the content, with an exception for images, which could also have thumbnails. In ExSite 4 any MIME-type can have multiple views, and five views are supported:
normal: this is the default view that would normally be inserted into web pages,
large: a larger or more high-res view than the default; for example, an HD video, or high-res photo.
small: a smaller version than the default; for example, a low-res view for previews or index listings
thumbnail: a very small version, suitable for thumbnail galleries
icon: an ultra-small version, suitable for inlining into text
When content is installed, a normal view is created by default. Any of the other views can also be created. The views do not have to be the same mime-type as the original content. For example, a video could have an image as its small view (and also as its thumbnail and icon, for that matter).
When inserting views into pages, the normal view is used by default, but you can select other views optionally. If the requested view is not available, it will automatically find the closest matching view. For example, if you ask for a thumbnail image, but there is only a small image, the system will simply resize the small image to the standard thumbnail dimensions.