Release 2.0.0

By TrollGirl on Deviant Art

There are comparatively few visible changes in this release compared to the amount of effort that it required. The two major accomplishments are upgrading and modernizing the backend and some of the application architecture, and moving from our own in-house authentication solution to OAuth2.0 + OpenID Connect in a separate but tightly-integrated application. So what does that mean for our users?

New Authentication Mechanism

Let's start with the obvious change in this release: we have completely rebuilt our application authentication mechanisms and moved from our own in-house proprietary authentication solution to an industry-standard OpenID Connect + OAuth2.0 solution which also allows us to maintain full control over the appearance and functionality. This change was the catalyst for nearly all of the other changes in our application.

Here are some of the greatest benefits of this change:

1. You can now log in using one of several external OAuth providers - including your Google, Microsoft, LinkedIn, and GitHub accounts!
2. Ability to authentication to additional services and providers using your Marketpath user account, including:
   1. Improved "offline" authentication for services and microservices - enabling development in new and innovative directions.
   2. Increased flexibility to provide the option of logging in to your third-party service. Contact us if this is something you would be interested in.
3. Industry-standard security using well established and trusted authentication and authorization mechanisms.
4. Voluntary two factor authentication
5. Streamlined new user onboarding. In most cases, users may start using Markepath CMS immediately without having to verify their email address or enter additional information first. There are some limitations:
   1. There is some functionality that we do not allow until your email address has been verified (eg: managing accounts, custom domains, other users, etc...)
   2. Users will still be required to verify their account before they are allowed to log in again in the future.
   3. We will still ask for additional information on subsequent logins - this information is very helpful for us and for our users (eg: to customize the UI based on their user type)
6. Seamless migration. You will still log in using the same username and password following this release - making the change painless for most users.

Modernizing Backend

The world of technology continues to innovate and grow in new directions, and we have been using the same backend technologies for years. As we updates our authentication solution, it became apparent and even necessary to update our backend code to a more modern platform with better security features, regular updates, and support for the various features and requirements of our new authentication solution.

This update touched every application, system, service, and process in our application. That is a lot of technology to update without introducing any new bugs, regressions, or other issues. In an effort to make the transition as painless as possible, we made a concerted effort to consistently update the entire code-base without making any unnecessary changes to our core logic, structure, and features. We also spent a significant amount of time testing everything using every option available - from unit testing, integration testing, UI testing, and even a great deal of distributed manual testing!

The result should be a faster and safer content management experience that is ready to take us into the next chapter of software improvements with a high degree of confidence.

Feature Improvements

While we intentionally tried not to introduce new features or make unnecessary major changes to our application, there were a few features and improvements that we felt were absolutely necessary to implement at this time, including:

Updates to image processing

We have been using an image processing solution in Marketpath CMS that has served us well for many years, but is unfortunately no longer actively supported. Recently this has started causing some pain for us as we have not been able to support new and upcoming image standards as quickly as we had hoped, and when we encountered bugs and issues we did not have a recourse for addressing them other than costly and/or time-intensive workarounds. Finally, our migration to a modern platform in this release has forced us to migrate from our old solution to a newer option.

Before updating our image editor and processor, we did a thorough review of how they have been used so far. In the process, we discovered that the vast majority of functionality was unused. Although our new image processing solution has the ability to maintain feature parity with our old image processing solution, we determined that it would be in the best interest of our users to remove the unused functionality which further allows us to simplify our interface to make the features that are desired more prominent. To repeat, we did NOT remove any functionality that was actively being used by our user-case.

One of the major improvements that this update allowed us to implement immediately is better support for the .webp image format. Although we previously had limited .webp support, our new image server handles compression of .webp images much better.

Another major improvement is improved image caching, particularly for compressed images. Compressing images can be a costly process on the image server in terms of both processing time and memory utilization. Although we already had a CDN implemented for serving cached copies of compressed images, we determined that the CDN was not serving the cached images in many cases and we needed to manually implement an additional layer of caching. What does this mean for you? It means that in almost all cases, images should only have to be compressed the first time they are generated which will result in faster image load times from the server for all images on all sites.

There is a downside to this as well, however, and that is that cached images do count towards the storage quota. For the vast majority of sites this should not make any meaningful difference, but if your site is already close to your storage quota, it contains a large number of images, and you heavily utilize image presets, then this change could result in storage utilization overage fees. If you are concerned that you could be negatively impacted by this change, please contact support.

Hey, as far as that is concerned, if you have read this far into the release notes we would love to hear from you - you are a rockstar! Sometimes it feels as if we only write release notes for our own benefit so it would be nice to know that other people do read them 😀.

UI Communication Fallbacks

This is one of those half-frontend half-backend features that benefits users in ways they didn't even know they needed. If the UI fails to connect to Marketpath CMS using the primary communication method (websockets), it will automatically attempt to remain responsive using a secondary communication method (the REST API). This improvement in error handling for communication protocol failures will hopefully go unnoticed, but may also contribute to a long-term positive content management experience.

Other Minor UI Improvements

There were some additional minor UI improvements in this release, including adjusting some of the dialog widths, improving the consistency of the version compare dialog, and improving the UX for several dialogs (eg: the advanced option in the site administration dialog, or the dialog for adding a domain to a site).

Bugfixes

We have found and fixed a large number of bugs.

Tasks Left to Complete: Out-of-Date Documentation

We have waited until this release is complete before updating our documentation, which still refers to our old authentication and profile management workflows. Please be patient with us while we gradually bring all of our documentation back in line with the current state of our application.