(updated) R207.1 release announcement: additional changes to liquid data types and output - action required

With the  R206 release announcement, we've  announced a series of liquid data types updates to be included in the R207 release which will break backwards compatibility. With this release, we're going to further extend the list of updates with a few other data type changes made which aim to bring more language consistency and predictability as well as leave space for future developments.

Please find below the detailed list of changes, most of them related to the ones already announced with the previous release:

• Implicit parameter conversion in Liquid filters - we will update all filters to implicitly convert their parameters and the value on which they are applied to the required type. As an example, the replace filter expects to be applied on string values and one scenario where it is often used is in changing the decimal separator for numeric data represented as a localized string: totalInvoice | replace: ",", ".". That works  if totalInvoice is a string but what if at some point totalInvoice becomes a numeric? With the old filter behavior, replace would just break and would return null. With the new implicit conversions in place, it first brings the value on which it is applied to string and only after it applies the filter's logic. This is useful in multiple real world scenarios, one of them being keeping as much backwards compatibility as possible on the data types updates we performed in this release and which now ensure that numeric values from modules are actually set as numbers.
• Improved strip_new_lines filter - we'll add a new parameter to the strip_new_lines filter which represents a string to use as a replacement for the newline characters that are removed. A common use case is replacing newlines characters with a white space and that is now possible like so: myText | strip_new_lines: " "
• Updated split filter to  return no element when applying to an empty string - the split filter is configured to remove empty items from the result set. Because of that, splitting ",," by "," outputs no element. That has always been the filter's behavior. However, when splitting the empty string "" by ",", the result would have a single element consisting in the empty string. That is an inconsistency which has been fixed.

Backwards compatibility breaking changes:

• Updated replace filter to replace exact match - with he next release, we'll fix the replace filter which previously broke for some characters like * or $ as also reported on the developer forum: https://forums.adobe.com/ideas/4300. With the next release, replace will work predictably by replacing the exact matches of the first parameter passed to the filter with the second one. However, the update will no longer support escaping as this behavior was not consistently working for all characters. Sequences like "\*", "\(", "\$" or even "\n" will always be treated as string literals and will only match the sequence of two characters formed by the backslash and the character following it. Another example, you will no longer be able to replace new lines with a character using this syntax: myText | replace: "\n", " ". Instead, you will be able to use the strip_new_lines filter and add the character to replace the line with as a parameter to the filter (ex: myText | using strip_new_lines: " ").
• Empty strings replaced by null - with the next release, we'll use "null" to represent fields coming from modules that don't have a value. Previously, empty strings were used for that purpose but that approach is no longer appropriate since not all data is a string (could also be numeric). For example, it would be  inconsistent to return the weight for a web app item as number when such a weight is defined and an empty string when it isn't.
  • As such, the fields below will return "null" when they'll not have a value or return not set:        
    • Web apps rendering: weight, latitude, longitude, distance, previousPageUrl, nextPageUrl
    • Product rendering: maxQuantity, discountPrice, totalDiscountPrice, totalPrice, tax, taxCode, taxRate, retailPrice, salePrice, wholesalePrice, inStock
    • Orders rendering: productID, productName, productUrl, productExtension
    • Bookings rendering: percentFull, capacityEmpty, capacity
    • Blog rendering: postTitle
    • Rating rendering: items, pendingItems

In the case of empty strings replaced by null update, the backwards compatibility should only be present when checking if any of the fields from above has a value by comparing it against the empty string. For example:

• Today, we're using the following syntax to check for an empty string: {% if myItem.nextPageUrl != "" %}
• Following the release, the above check will have to be replaced with: {% if myItem.nextPageUrl %}
• A version that would work with both the current and the following release would be: {% if myItem.nextPageUrl and myItem.nextPageUrl != "" %}

The changes described in the R206 release announcement and the above changes, will be included in a separated release named R207.1 which is going to be pushed live on August 31st.

To avoid any problems with your sites, please make sure you update the pages using the changed functionality by August 31st.