Although our focus for this effort was supposed to be an overhaul of package manager, we ended up having to shift focus due to an increasingly evident issue with image compression. As a result, this sprint took a little longer than we would have liked and includes a significant backend change to how images are produced. Nevertheless, if we did our job well, the typical user should not notice many differences following this release.
Image Compression
Over the last several months, we have repeatedly experienced dramatic image compression failures. The failure occurred in third-party code that we licensed and ran on our image servers. This would be unpleasant enough if it only resulted in the failed image not being returned. Unfortunately, this bug went way further and would crash our server's ability to return any image at all. In a word, this is unacceptable.
In response, we completely disabled image compression for all images while we wrote a permanent fix into this release. Uncompressed images are better than no images after all.
So we went back to the drawing board and replaced all of our image compression functionality with code that we have more control over. In our testing the new functionality is reasonably effective, although we still hope to improve our results over time (most notably for lossy png images).
Our main goal with this change is that we never have another image outage again. At the very least we now have the means to troubleshoot any issues within our own codebase should another issue arise. In the short-term this may result in some slighly larger images, but in the long-term we hope to match or even exceed the efficiency of our previous image compression solution; which would be a nice bonus.
Package Manager Changes
This release focused heavily on package manager changes designed to improve the usability and usefulness of packages. To summarize, these changes include two major efforts:
- Removing the concept of "Repositories" as a top-level container for packages and moving the previous "Repository" functionality to "Packages".
- Removing the old package manager interface and merging the package authoring functionality into the primary Marketpath CMS interface.
No More Repositories
There is one feature we have permanently retired in this release - repositories. Repositories were intended as a convenient way to group packages and manage them together. In particular, repositories were supposed to control who was granted access to which packages.
While this seemed like a good idea at the beginning it turned out that it made managing packages more difficult instead of less. Furthermore, it was a relatively simple matter to restructure both the frontend and backend code such that repositories were no longer necessary.
So now access is managed at the individual package level. You can still make packages public or private, and you can still share private packages the same way that you could share private repositories before.
Package Authoring
Prior to this release, packages were authored in a completely separate interface. While this worked, and allowed us a great deal of flexibility in the package authoring workflow, it also added several barriers to creating new packages and managing old ones.
Now we have moved all of the package authoring functionality into the same site management interface that you use for everything else. This move further allows us to take advantage of existing functionality in new ways - most notably by introducing a "Package Authoring" mode which allows you to find content the same way you always have and add it to the current package with a single click of a button.
Labels Field
One final addition we made in this release is the addition of a new "Labels" field to make it easy to associate more flexible tag-like data with objects. This is immediately useful for packages, which may be organized by numerous criteria - everything from "Type", "Color", "Industry", and beyond. This data will be particularly helpful in the future for finding packages based on a number of different - and flexible - factors.
One notable feature of labels field is that it is OK to include multiple labels with the same key. This may useful, for example, to assign the same item to multiple categories (or sub-categories). One example might be to associate movies (for example) with multiple genres (Adventure + Romance).
Labels are accessible in templates as the {{ labels }} field.
Bugfixes
- Exclude "noise words" from search strings (eg: "of", "in", "and", "the"). Search terms including these noise words would previously not return any values.
- Fix for default value validation during publishing.
- Fixed a situational error when the same item is both published and unpublished at the same time.
- Fixed a situational bug where changing the location and order of menu items would not properly update the preview site.
Other Improvements
- Improved the usability and reliability of package installation in several situations (eg: dependent packages, improved mapping, feature validation, and other options)
- Miscelaneous frontend stability improvements
- More backend stability improvements - notably for a faster and better release process
