This release contains a few bugfixes but is mostly dedicated to a single developer feature - the combination of liquid collections and lists.
Bugfixes
- Bug #2894 - Creating a new site setting, saving, then exiting prompts the "unsaved motifications" despite having just saved
- Bug #3061 - Unable to view timezone scroll bar on calendar event
- Bug #3076 - Login expiring on a per tab basis
- Bug #3113 - After session timeout and user logs in, session times out on other open tabs on first call
- Bug #3117 - Export of Form Submission Errors
- Bug #3148 - Maximize content area in properties view is cut off
- Bug #3150 - "Text" field missing if HTML is in p tag of Link
- Bug #3153 - Timezone alert is thrown when it shouldn't
- Bug #3154 - UI auto-adds root path to URL and shows published
- Bug #3158 - Site properties not retaining timezone selection (sort of)
- Bug #3159 - Image Dimensions Need to Be width by height
- Bug #3161 - Custom field Select List - unable to edit field after initial creation
- Bug #3170 - Account Profile needs changed to User Profile
- Bug #3172 - URL Fields in the live API are wrong
- Bug #3173 - Live Edit button is not displaying
- Bug #3174 - Partial Update Errors
- Bug #3203 - Error creating new site - dispatch failed
About Liquid Collections and Lists
Prior to this release, there were two ways to pull multiple objects from the database inside a template - collections and lists. Collections would pull objects based on filters that were input into the method
{% blog_post_collection posts blog:entity.guid limit:10 %}
Lists would convert inputs into the specified type and combine multiple inputs into a single output:
{% blog_post_list posts entity.featured_posts from_a_variable "from a string" %}
The syntax and wording of these two types of methods were similar yet different enough to cause some confusion when reading the documentation and authoring templates. Furthermore, these two types of methods returned two types of objects - collection objects and list objects. The collection and list objects were also very similar except that collections had several properties that lists did not.
We combined both of these methods into one, which is essentially a pluralized version of the object:
{% blog_posts posts blog:entity.guid limit:10 %}
While we were combining these objects and considering common use cases and desired functionality, we were able to capitalize on a few additional feature opportunities related to creating lists of objects. Specifically, the newly combined methods have a built-in capability of enforcing uniqueness on the results as well as a max-size for combining prepended, fetched, and appended items. Continuing on that theme, the newly combined result also stores the prepended, fetched, and appended items for separate consumption if desired.
Additionally, we had identified a consistency and readability issue with a number of our liquid methods where some methods would use an equals sign to separate the left-hand and right-hand arguments and some would not. Some methods would also output to the template by default while others required the explicit "output_to_template" argument.
In general we found that methods which contain the equals sign were easier to read and understand (and consequently write) than those without. Since we already had to manage a large template migration process to combine collections and lists we were able to take this opportunity to standardize on using an equals sign as well as standardize on how to balance saving results to a varaible vs outputting to template (if not assigning the result to a variable or output_to_template is specified than the result will be output, otherwise it will not).
