We are pleased to announce the arrival of Marketpath CMS Profiles with this release. Profiles are our term for frontend logins, so users of your site may create their own "accounts" to allow for secure personalization.
For a more complete understanding of profiles, check out our Profiles Training Course.
Profiles
In short, profiles contain secure credentials for frontend website logins along with some additional information related to those credentials. There are a number of built-in mechanisms to protect credentials, as well as additional tools that template developers may utilize to add their own protection.
Profiles may either be created in the Marketpath CMS administrator interface or directly from the live site. Profiles created from the live site must be activated before they can be used, however. Activation is primarily a matter of verifying the email address associated with the profile, although you may bypass it if desired.
Profiles may be enabled or disabled altogether from your site settings. When disabled, profiles will no longer be able to sign in on your site site. Alternatively, you may leave profiles enabled but disable live signup so that users may not create their own profiles. As part of this release, all sites will have profiles signup enabled by default, but will not be able to use them without properly coded templates to support them.
As with most Marketpath CMS objects, profiles can be customized beyond their original implementation. You may associate custom fields with profiles just like you would with datastore items. Additionally, profiles may contain custom attributes which do not require validation (similar to existing client and session properties).
Unlike any other object currently in Marketpath CMS, profiles may be updated using template code directly from the live site. This is made possible by the new {% auth %}, {% set_profile %}, {% unset_profile %}, {% set_profile_setting %}, and {% unset_profile_setting %} methods. However, because of the unique ability for profiles to be changed directly on the live site, any requests that check for or potentially change profile information will not be able to utilize fast caching.
Any updates to profiles from live sites are aytomatically synced back to the management interface, and any updates to profiles from the management interface are automatically published to the live site. In most cases profiles will only take a second or two to publish and up to 15 seconds to sync. In rare cases it may take longer - such as when publishing and/or syncing is disabled for maintenance.
Template Improvements
To accompany profiles, we have also made some small improvements to our templating captabilities. In addition to the profile objects and methods mentioned above, we have also added some improved type-checking and other capabilities. We have updated our liquid reference documentation to include these improvements, but in summary here are the changes:
- Added new conditions for use in the {% if %} and {% unless %} methods: is_number, is_string, is_boolean, is_date, is_list, is_simple_type, and is_object.
- Added a new to_boolean filter for convert string inputs to true or false (or null if it can't be converted).
- Added a new object_type filter to return the type of the current object (null, string, boolean, date, object, list, etc...)
- Upgraded the format filter to format dates, numbers, and time_diffs. Added a new format_number filter. Improved timezone handling when formatting a date as a string.
- Added a new shuffle filter to randomly order lists. Using the shuffle filter prevents the page from being fast-cached.
- Upgraded the rand filter to be useful for a variety of purposes, including returning a random number, a random string, a random object from a list, or even multiple random objects depending on the input type and the arguments supplied. Using the rand filter prevents the page from being fast-cached.
- Upgraded the syntax for most methods that take multiple arguments to accept one or more muliple-argument variables using the new *variable arguments syntax.
- Added a new {{ request.method }} property to identify if the current request is a get, post, or other type of request. Also added a new {{ request.post_params }} object to grant the template developer access to HTTP post variables.
Dictionary Field
Also as part of the profiles release, we have created a new dictionary field which you may now use anywhere that you use custom fields - including template fields, datastore fields, custom site settings, etc...
The dictionary field simply holds an unordered collection of key-value pairs. There is very little validation except that the keys may only contain letters, numbers, dashes, and underscores. You may also choose to require a minimum or maximum number of keys.
Improved datastore item and profiles query
You were previously able to query datastore items using syntax like "field1 < 3 and field2 == something". You were limited to using "and", and any numbers (3 in the previous example) were still treated like strings, so that comparing "3" to "11" for example would return the wrong result. That capability has now been expanded with the capability of treating numbers as numbers, using "not" and "or", and performing more advanced grouping. Eg: "field1 < 3 and not (field2 == 'a' or field3 == 'b')".
Other
Also in this release:
- Renamed "Site Properties" to "Site Administration" to reduce confusion between Site Properties and Site Settings
- Fixed the request.query_params and request.headers objects to properly make properties such as "count" and "keys" accessible
- Improved the import workflow so that the "Verify", "Commit All", and "Publish All" toolbar buttons are only visible when they are actually applicable.
- ...and other miscelaneous fixes and improvements.
