When setting up a Silva website the Chief Editors arrange the content in an information architecture. Typically this follows the internal hierarchy of the organization. For the public, if the organization's structure is known, this approach makes sense and helps site visitors find information. The architecture also works well for managing content, such as assigning roles to users and groups, as different people can be made responsible for separate sections of the site and they can delegate within their section. Meanwhile a few Managers keep the overview of the superstructure.
Within the content tree there are items that are published and items that are in draft mode or closed. The public sees a tree of the published content. The editors see the same tree, but possibly with more leaves and/or branches that haven't been published yet. For this blueprint we'll call this the physical tree.
Sometimes an alternate information architecture is desired which has a different structure than the organizational hierarchy. An example of this would be the "Information for..." and "Information about..." sections that are often used in large sites. In Silva today these sections are constructed using Ghosts, but since Silva 2.3+ we have robust references, and these bring new possibilities. The references have advantages over Ghosts and Ghost Folders because:
- Unlike Ghost Folders, assets are not duplicated.
- There is no need to synchronize as with Ghost Folders.
The purpose of this extension is to allow Silva users to construct a different content tree than the one seen when editing content. This allows site editors to:
- Have an internal organization of the content and alternate externals arrangements. Thus content within the CMS can follow the organization's internal structure, either in a hierarchy or by defining user groups (e.g. departments), while the presentation to external visitors uses a different content organization scheme.
- Create memorable and short URLs to deep content, so-called Marketing Links. This concept will augmaent the Short URLs implementation.
Public tree management
A new interface will be available to Chief Editors that allows alternate structures to be created using items in the physical content tree. We call this alternate structure a Public Content Tree. Multiple Public Content Trees can be created in Silva.
This interface will look like a folder content listing, where you can add either:
- A reference which refers to an existing item in the physical content tree (content or a container).
- A folderish item (wrapper?) that can be used to organize references inside it. Those will be standard references, however you'll be able to add references to other content which is not present in the original referred location. This overrides the structure found when referencing a physical container.
To add a reference, an editor will select:
- A content item, using the same reference selection widget as elsewhere in Silva (e.g. Ghost Folders, Links, select images in documents ...).
- Optionally an identifier to use for the URL. The ID of the referenced content will be suggested, however if no identifier is selected, a (short) random one will be generated, to act like an URL shortener.
References will not have metadata; they are not content, just references to content. A reference is analogous to an Alias on Mac OS, a symbolic link in Unix, or a shortcut in Windows.
Silva users editing content won't be able to delete any content which has been referred to from a Public Content Tree.
Editors will be able to edit the target of a reference. Renaming, moving, copying and deletion of those references will be possible from this same interface.
If an editor renames or moves a reference in an another container, there will be an option to keep a 'backward compatibility reference', that will provide an HTTP permanent redirect to the new URL of the reference (like silva.app.redirectlink does for regular content). It will be possible to (de)activate this with a setting, modifiable by a Manager.
Accessing the public tree
Visitors coming to the site will access the content with a URL formed by elements of the Public Content Tree. In the public tree, if you define a folderish item called 'cms' in which you add a reference called 'docs', which refers to the 'silva_docs' item in the physical content tree, you will access it via the URL: http://your-site/cms/docs. While in fact you are viewing http://your-site/silva_docs. If you then click on the Getting Started link, you will go to http://your-site/cms/docs/getting-started, which is in fact http://your-site/silva_docs/getting-started.
Multiple public trees will be definable in a Silva Root, where a Manager will be able to define criteria for which they will be used instead of the regular content tree. Default criteria can be:
- The HTTP/1.1 host in the incoming request.
- Protocol, i.e. either HTTP or HTTPS (if you want to have a different tree only if you view your site in HTTPS).
Criteria will be extensible, for instance a future extension could add criteria based on the IP of the HTTP client.
The SMI will always use the regular, physical content tree. Public Content Trees will have a dedicated interface.