Support means to add pages to the website.
This does not automatically translate into "Post Content" since a page may just be a set of references to other pages, list of things, etc.
Creating a page requires:
1. Adding a title
2. Selecting a layout, Selecting a favicon1
3. Writing or attaching content
4. Mark a page as the child of another (i.e. to create a tree like a reference manual or book; threaded comments); this is optional meaning that by default a page is just a stand alone page
5. Mark a page as before or after another (i.e. comments are generally sorted by date, however in some cases it can be useful to sort pages in a specific order such as a chapter number.)
The page "immediately" appears as final (it may take a second to create the page on the server, of course.) The layout is the default user selected layout including the default boxes and their content (i.e. most recent comments, last post written, name of the author who wrote the last post, etc.)
While editing, all the parts are "electric". This means a click on pretty much anything (outside of some margins) will offer the user a way to edit the content of that thing.
For some features, it may not be practical to have an active area. In that case we can make use of a toolbar (as we already have in Snap!) For example, the layout will be the page itself and it cannot really be changed without some button somewhere. (Remember that in most cases the layout of a page is not the whole theme, although it will be possible to change the theme on a per page basis.)
The content of a box is defined by another feature.
Each page has a path. The path is used to determine which data to access when a user comes to the website. One important aspect here is that each path must be unique. Also a path may be dynamic in that it may support options (especially useful to access administrative resources.)
The page editor can offer an AJAX feature to check the unicity of a path. Also on a Save the software can generate a unique name by adding a number after a dash at the end of the path.
We want to support a way to let administrators choose how each field should appear in the create and edit forms.
For example, the title of a page may not be required in some specific circumstances. When that happens, you may want to create the title from some piece of data such as a random number, the first sentence of the body, the date and time, etc.
Assuming you can edit each field, you should have the ability to transform the fields by hiding them and defining a pattern of data that will be used when the field is saved in the database.
Pages need to have a mechanism that defines when they are published and they do so automatically. Before that date & time, it's not there and after another date & time, it's gone.
When you have both on both ends you can create content that appears temporarily. For example, you could create a product that appears for 1 week and then disappear.
Using the next/previous/parent/child links in a page (and also defining a first & last,) it is possible to generate a book with a valid path (properly organized) and the parent can include the children as chapters (i.e. links to said sub-pages.) This means we do not need to make use of a special feature to be able to build a top-down organized website.
The output plugin also generates a breadcrumb which is a list of anchors that reference all the parents from the Home page down to this page. The existing version needs some help to allow the end users and theme writers to enter various parameters such as the characters used to separate each link, what title should be used for the link label (short, long), whether the home page and current page should be included, etc.
The breadcrumb follows the Google recommendations as found in Structured Data: Breadcrumbs.
When editing a page contents, the previous version is kept. The new version is assigned a new revision number. This allows for users to go back to a previous version. Also, it is possible to moderate the new revision before publication.
In order to allow for multiple versions, one can use a separate branch. This means you can have two completely different versions of a page. Maybe one is public and the other is private (i.e. if user is anonym, then show Branch A; if user is part of group X, then show Branch B; if user is part of group Y, then show Branch C; etc.) However, the most interesting use of a branch is to offer a user a way to create a brand new version without forfeiting the possibility to continously update the existing version. Once the new branch is ready for prime time, publish it.
The data in a page includes a status to better handle parallelism (i.e. if a user makes an update, another can wait for the update to be completed or say that the page is invalid.)
The problem, especially for programmers, is that once in a while the status does not get restored back to Normal/Not Working or some other valid status. For that reason the content plugin includes an action to reset the status. This allows you to continue development and on a website without having to reinstall everything (and lose all your data, or restore your data to a previous valid state.)
This mechanism is actually used in the content backend to restore the state of a page which was marked as being worked on, updated, etc. for more than a few minutes because it is assumed that this status is turned on, the data written, then restored. In other words, if you need a large complicated caculation, it will happen before you change the status. So it is possible to force the status back to normal once in a while in a completely automated way.
Yes. We use RAII and thus the status should always be correct. Yet, once in a while the software terminate in a way that prevents the RAII mechanism from restoring the status before the software quits.