The majority of changes made in this release should be completely transparent. For those interested, we will dip into a small explanation later in the release notes, but first let's talk about the changes that you can see.
Updated Edit Icon
In an effort to make managing content more intuitive, we made the decision to change one of our core icons - the good old "Properties" (
) icon. We have replaced this everywhere with an "Edit" (
) icon - including updating the titles. We hope this change makes it easier for new users to understand how to update their content.
Max Image Size on Upload
To improve site performance as well as reduce unnecessary strain on our image servers, we have added a new "Max Image Size on Upload" site setting. When set, uploading an image taller or wider than the size specified (in pixels) will automatically shrink the image to the configured size.
On new sites, this will be set to 3000px by default, but may be increased or decreased as desired - though no larger than 4000px. This functionality may also be disabled by deleting the setting. You may even delete the setting in order to upload a full-size image, then re-enable it to be applied for future image uploads.
This feature will be disabled by default for existing sites for backwards compatability and to reduce unnecessary frustration for editors who are not used to this new feature.
Simultaneous Editing of a Single Object
We made some notable improvements to the editing experience when multiple users try to edit an object at the same time. With this change, when another user checks out an object for editing while you still have it open you will be notified of their action. If you choose to continue editing anyways, you may easily overwrite their checkout in order to save your changes - at which point they will also be notified of your action. Ideally you both know each other and can determine for yourself who should edit the object and who should wait. But that is not something that Marketpath can solve for you.
Object Versioning
One requested feature that we were able to include in this release was the ability to combine versions created in a single editing session so that they do not overwrite older versions as quickly. This presented a couple of challenges with our version limits, but we believe we now have a solution that should be fair and satisfactory.
Our improved solution for object versioning is to maintain a combined list of "long-term" and "short-term" versions. The "long-term" versions ar maintained as before, in addition to the "short-term" versions - which are consistently cleaned up as needed in order to maintain a shortened list of the most significant changes to your content.
Note that this solution is specifically aimed at users on paid sites who make a number of small changes and publish them in quick succession (a common method of editing content).
The number of versions of an object is still limited by the site's plan - starting with free sites only being allowed one version up to pro sites having 15 versions. However, for paid sites the number of versions that are retained may temporarily nearly double while they are in an "editing session" due to the retention of their "short-term" versions.
There are several factors that could indicate the end of an "editing session" and therefore trigger the removal of all but the latest version in that editing session. The most significant of these are another user editing the same object at the same time, marking a version as permanent, and waiting an hour or more before publishing the object again.
An example of how this works. On a standard site (which comes with 5 versions). For the sake of this example, every time the object is updated we will assume that it is also published:
| Action | Change | #Versions: Long-Term |
#Versions: Short-Term |
|---|---|---|---|
| You create and publish an object | 1 short-term version created | 0 | 1 |
| You update it | 1 short-term version created | 0 | 2 |
| You wait an hour | Your 2 short-term versions combined into 1 long-term version | 1 | 0 |
| You update it | 1 short-term version created | 1 | 1 |
| Your coworker updates it | Your short-term version becomes long-term 1 short-term version created |
2 | 1 |
| Your coworker updates it 4 more times | 4 short-term versions created | 2 | 5 |
| Your coworker updates it 4 more times | 4 more short-term versions created 4 short-term versions removed |
2 | 5 |
| You update it | Coworker's short-term versions combined into 1 long-term version 1 short-term version created |
3 | 1 |
| You update it 4 more times | 4 short-term versions created | 3 | 5 |
| You update it 4 more times | 4 more short-term versions created 4 short-term versions removed |
3 | 5 |
| You mark the second short-term versions as permanent | Your 2 short-term versions combined into 1 permanent long-term version | 4 | 3 |
| Your coworker updates it | 3 short-term versions combined into 1 long-term version 1 short-term version created |
5 | 1 |
| You update it | Coworker's short-term version becomes long-term 1 long-term version removed 1 short-term version created |
5 | 1 |
| You wait an hour | Your short-term version becomes long-term 1 long-term version removed |
5 | 0 |
Scheduled Publishing Improvements
Scheduled publishing is now more precise. That is to say - it is now considerably more likely that any objects that you have scheduled for publishing or unpubishing will be published (or unpublished) the exact minute that it was scheduled for. Along with this improvement we have also reduced the amount of time in the future that you can schedule a publish from 1 hour in the future to 5 minutes. While most users are not likely to notice these improvements, they were easily accomplished within the scope of our other updates and it just feels good.
Behind the Scenes
For those who are interested, we made some significant changes in the backend code that powers Marketpath CMS. We did this to address some performance bottlenecks that we noticed - particularly with regards to site creation, package installation, and large publishing operations - as well as to improve general stability.
Removing Database Transactions
The first change we made was to drastically reduce the number of atomic database transactions required by various operations. While data is being updated by a relatively small number of people the transactions were not really noticable, but as more people managed data at the same time those transactions sometimes caused "deadlocks" on data, which caused one or more operations to fail. By performing operations using other methods, deadlocks should become rare and accessing and modifying data should be both faster and ironically more reliable.
Agent Jobs/Microservices
Perhaps the biggest transaction that was run frequently had to do with publishing. We previously executed a significant amount of logic inside a giant transaction - which worked consistently well for a small number of editors. However, to improve performance and reliability for a large number of editors we have rearranged our publishing logic so that nearly the entire operation happens outside of any database transactions. Another giant transaction that taxed our systems was swapping site domains - which is now handled by a separate "microservice".
Similarly, we also rearranged a number of additional large operations to be handled by a microservice. Some quick examples of this are domain activation (moving a domain from one site to another), re-publishing the full site, and cleaning up old/expired content. This also positions us to be able to move more functionality to microservices if desired in the future - such as new site creation and package installation.
Live Site Stability
While working on this sprint we experienced some instability with our live sites as a result of our reliance on a particular trusted third-party service during auto-scaling procedures. Due to a confluence of events we experienced a short period of total live site downtime - which we consider to be unacceptable. Thankfully, we were aware of the problem as soon as it occurred and were able to intervene manually to bring sites back online as quickly as possible. To compound the nightmare the same thing nearly happened a few days later, although we were able to prevent any downtime the second time around.
So we shifted priorities for a few days to remove our reliance on the third-party service in question while simultaneously improving the stability of our live servers. One of the major benefits of the way we addressed this problem is that in addition to making our live servers more dependable, scaling out new instances of our live servers is now significantly faster.
Additionally, we have completely separated the application code that handles publishing on the live site with the application code that handles live website requests so that those two functions are no longer even handled by the same machine. This is a minor improvement but comes with two benefits: publishing will no longer affect live page rendering speeds (although we have no indication that this was ever actually a problem), and we have more specialized control over how we set up the machines that handle these two very different types of tasks.
Testing
Along with all of these massive changes, testing has been increasingly important. We are working to address this need head-on, both with regular manual testing and improved automated testing. During this development effort, we have dramatically improved our UI testing process to be fully automated. This increases our confidence that changes that we make either to the management interface or the backend do not break existing functionality. We are also positioned to ramp up some of our other automated testing processes.
Other Bugfixes and Improvements
- Bug #3883: Corrected an expiration malfunction when inviting an agency to work with your account or site.
- Bug #4103: Fix to make dev domains available again after a site is deleted
- Bug #4113: Storage utilization should have at least one decimal point
- Bug #4118: Dispatch error when deleting an account after one or more sites have been recently deleted from that account
- Bug #4121: UI bug after deleting a restricted user
- Fixed multiple bugs with moving domains from one site to another
- Fixed multiple bugs related to installing packages on sites. In particular install-only assets are now being mapped on subsequent updates, and documents are now being served from the correct CDN endpoint.
- Corrected a situational bug when upgrading from a free site to a paid plan with no billing information on file.
- Fix for live templates when date math spans multiple time zone offsets (eg: when adding a month spans a daylight savings change)
- Fixed file delete for uploaded files from form submissions that are converted to documents or images
- UI bugfix to make the "exists" condition work properly with checkbox and list fields
- Fixed a pagination bug in the site search dialog
Other Improvements
- Added account information to the "Card Expiring Soon" email notification
- Uncheck the "Allow Overages" checkbox by default in the go-live dialog for free sites
- Allow users to see their agencies that are awaiting verification
- Improved domain verification in the event that multiple parties attempt to verify the same domain in Marketpath CMS
- Improved the performance of purging files from the CDN
-
Improved UI and validation for package installation with regards to features that are limited by the site's plan.
-
Track the progress of domain swap operations (using a naive tracking mechanism that notably excludes waiting for republishing to complete)
