Following the last major release, we are once again doing a major update. Unlike most previous releases, however, this release has only one focus: The complete merge of entities with pages.
As of this release, it is now no longer possible to create multiple pages for a single entity.
While the ability to create multiple pages for an entity is incredibly flexible and has a lot of potential to be used in powerful ways, the reality is that it is virtually never used and precludes our ability to make other system and usability improvements that will have a greater actual benefit.
Although this was the sole focus of this release, it touched so much core functionality that half of the frontend and backend systems were dramatically affected and had to be overhauled as a result.
Frontend "Page" Changes:
| Before | After |
|
Pages and Content were listed separately in the menu prior to this release.
|
After merging entities and pages, they can be listed together in a single "All Content" dialog which includes all of the combined information from the previous "All Pages" and "All Content" dialogs.
|
|
Pages an entities were viewed separately before. "All Pages" included the URL and Browser Title of each page. The search could only search for information saved directly on the "Page" - which meant that you could not search or filter pages by entity name, title, tags, authors, or folders (to name the most significant filters).
By contrast, "All Content" included Name and Title and could be filtered by name, title, author, folder, and tag. It did NOT include information from pages, however - which meant that you had to go to "All Pages" to search by or view URLs (for example).
|
After combining pages and entities, the newly combined information can all be viewed from a single combined dialog. This includes the entity name and title as well as the page URL. Furthermore, you can search and filter by anything that you could previously search or filter by in either the "All Pages" or "All Content" dialogs.
If you specifically want to search for "pages" (entities with URLs), you can still open up the Advanced Filters and filter by "has url" (or no url to view entities that do not have "pages"). You can also access a number of additional advanced filters here.
|
|
To view all of the properties of an entity with a page, you previously had to open the entity and page properties separately. This is the previous page properties dialog:
And this is the previous page properties dialog:
|
To view all of the properties of an entity with a page, all you have to do now is open up the entity (or page, they are the same thing!) properties. Information about the "page" is viewable and editable directly inside the same context as information about the entity. This includes the ability to create and edit redirects, or even to view the preview or live page. As an added bonus, now the tags, authors, and folders apply to the page as well as the entity!
|
|
Editing custom data in the previously separate page and entity properties dialogs was a consistently awkward experience. For starters the data had to managed in two separate locations. To further confuse matters, it was impossible to enforce conditional fields, field validation, or field grouping. The best we could do was display the fields that had been filled out and allow users to edit or delete them at will.
|
After combining pages and entities, the combined custom data can be edited properly as dictated by the template developer. Conditional fields, field validation, and field grouping can all be properly understood and enforced in the new combined properties dialog - making for a more consistent and usable interface. Furthermore, the custom fields can be displayed directly alongside the core entity fields instead of being relegated to below all other content in its own easily ignored section.
|
|
The previous page edit interface utilized its own separate design and implementation. While there were a number of benefits to this, it also meant having to learn how to navigate a new interface for users and more opportunities for bugs or "glitches" in the interface.
|
The new page edit interface utilizes the same design and implementation as the properties dialog - with only a few minor customizations such as the removal of the "Has URL" checkbox. We expect this change to ultimately mean a more consistent user experience with fewer bugs and enhanced functionality in both the object properties and page edit interfaces.
|
|
To view the live page from the page edit interface before this release, you had to click on an icon with relatively little to announce what affect clicking on the icon would have.
|
To view the live page after this release, we included a well-marked button with a hopefully obvious meaning.
|
Backend "Page" Changes
Here is a short list of some of the backend changes we had to make to support the new model:
- Merge all entity and page data (particularly custom template data), including in saved versions and other metadata.
- Change all references in pages globally to reference the entity instead. This includes updating nearly every object on every site along with all of their saved versions and other metadata.
- Update the way entities are created and updated in order to properly validate page fields - but only if the "Has URL" checkbox is checked. If the entity is published with a URL and then the URL is udpated, automatically create a redirect. If an entity with a URL is copied, the new entity should have a similar URL.
- Update the way entity versions are created and restored to handle the added page fields. Update all existing entity versions to include all relevante page data - as closely reconstructed to the way it was when the entity version was created as possible.
- Update publishing and unpublishing of pages and entities, including scheduled publishing, publish all functionality, publishing to preview, etc... Publishing/unpublishing entities should auto-publish redirects the same way publishing pages previously did.
- Update the way that entities are trashed, untrashed, and purged to properly trash/untrash/purge and update redirects, error pages, menu items, etc...
- Update exports and imports to no longer care about "pages" and include the relevant fields on entities instead. Identify any import definitions that are re-used by clients which import pages and either update them accordingly or create a plan for updating them during or after the release.
Data Migration
One of the most time-intensive processes during this release was managing the migration from the old model to the new model.
This includes the relatively simple and straightforward migration of "structured data" as well as the much more tricky "unstructured data" and the potentially treacherous template migration.
One quick example of the trickiness of migrating data is the saved object versions - which includes the custom template data - which in turns includes old page and pagelist fields which need to be update to entity or entitylist fields with the relevant values. The object versions may also include url fields which may or may not have a reference to a page which needs to be updated to reference the entity instead. Updating everything quickly devolves into a mammoth task which is time-intensive even for advanced computer processing to handle.
Template Migration
The template migration was the scariest part of the entire operation since it directly impacts all live sites. The last thing we want to do is perform a release which negatively impacts live sites.
Any change to the templating engine has potential live site impact and it is not always possible to determine if changes are beneficial or harmful (eg: if the ordering of a list changes - was it a "fix" or a "breaking change"?). Unfortunately, combining entities and pages necessitated a large number of updates to the templating engine.
Thankfully, we were able to automate the updating of all templates to properly reference data where it needed to be referenced - even making a couple improvements and fixing a couple bugs in the process!
To ensure that the migration caused as few changes to live pages as possible, we developed and improved a full migration testing tool which compares all live pages - including pages with query parameters - before the migration and after the migration. We then tested the migration multiple times to examine all pages for differences and addressed them as they arose.
Some differences were valid (eg: random sorting or filtering based on the current date), and some were even verifiable improvements (eg: a number of broken links were fixed). By the time we completed multiple test migrations we were able to satisfy ourselves that there were ZERO negative templating changes as a result of this release. Naturally that is the only way that we were going to perform the release, but it was still a huge relief!
Risk Mitigation
The biggest challenge with this release: The potential risk from these changes are extreme and have to be treated as such. Not only did we need to test all of the new and update functionality, we had to do "extreme" testing.
Even after rigorous testing, we cannot guarantee that the system is 100% bug-free (any system that calls itself 100% bug-free is either lying or too miniscule to be useful) and that would always concern us but even more so with the scope of these updates.
To further mitigate this risk, we are saving much of the old data as it was prior to this release in case we need to do some advanced troubleshooting in the future. We will probably only keep this old data for the next one or two releases, however, assuming that this release does go as smoothly as we can reasonably hope and we do not need to reference the old data during that time.
Please let us know immediately if anything does not appear to function properly or have the correct data after this release. We do not expect any data-related issues to surface but if they do please let us know.
Other
Despite our single goal for this release, we did find time to fit in a small number of additional improvements:
Updated Dialog Functionality
Before this release, dialogs would slide open on the right side of the screen, automatically scrolling the screen to the right. While this functionality wasn't necessarily broken or bad, it did force people to regularly scan from the left to the right side of their screen and back and did not created the best user experience possible.
To improve the experience, we updated the functionality to immediately open new dialogs on the left side of the screen. Users can still scroll left and right if desired but now they at least do not have to scan back and forth as they work.
Furthermore, we added breadcrumbs at the top of the page which shows which dialogs the user has open and allows them to quickly and easily return to a previous dialog by clicking on its title in the breadcrumbs.
Updates to Scheduled Publishing Interface
One of the cool capabilities of Marketpath CMS is the ability to schedule any publishable object to either be published or unpublished in the future. One of the common comments on it, however, was that the interface for scheduling publishes and unpublishes was unintuitive to use.
Old Scheduled Publishing Interface
The old interface gave 4 primary controls - one for adding publish dates, one for clearing scheduled publish dates, one for adding unpublish dates, and one for clearing scheduled unpublish dates. Users found these controls a little clunky on their own - but some users found it completely unusable when combined with the unintuitive toolbar buttons. The "Clear" button in particular caused a lot of confusion. And to top it off, the interface does not even always say what it is that the user is scheduling to be published or unpublished.
New Scheduled Publishing Interface
The new interface aims to be both more intuitive and to provide users with more control over how it works. By default, all of the objects will be scheduled to be published and unpublished at the same time. Unchecking the "Schedule One Publish/Unpublish Date for All" checkbox will allow the user to set individual publish and unpublish dates on each selected item. There should no longer be any doubt about what will happen when the user clicks the "Save" button - now the only button present in the toolbar.
Updates to Domain Details Dialog
The new domain details dialog is faster, includes more details, and looks better than the old domain details dialog. Of particular note is that the new domain details dialog now tells you if your domain is not pointed at the correct Marketpath CMS live server and provides basic instructions for how to update your DNS records in order to view live Marketpath CMS pages.
