Version 8.7 of Zenario contains better support for optimisations in Cloudflare, as well as various new features for administrators and hosting providers.
A document envelope allows you to display multiple versions of a document (e.g. .pdf, .doc and .ppt) on a page in a content-managed way.
The document versions can be displayed together with an thumbnail and/or a description.
The Videos Manager module has been updated to better support Vimeo privacy settings, and the Videos FEA module has been updated to allow creating/editing videos.
When looking at an email template in an admin box, we now show whether an email template is protected, and how it was created (i.e. upon installation by a module, or manually by an admin).
Emails in the sent email log now display their "CC" email addresses if they have any.
When you log in as an administrator, the diagnostics screen will now show you the time that you last logged in previously.
It also shows the last IP address used, and its country.
In 8.7, we've adjusted how our plugins work to support for some of Cloudflare's more disruptive optimisations.
You can now enable the feature that strips HTML comments from webpages without causing some of our plugins to break.
Zenario versions 8.6 and 8.7 fix several PHP notices that were appearing when running using PHP version 7.3.
Note that better support for PHP version 7.4 is coming in Zenario version 8.8.
Zenario now has a feature where you can disable database restores in the admin backend. You set this by setting the RESTORE_POLICY constant into your zenario_siteconfig.php file (and they'll be a nag-message on the diagnostics screen prompting you to do this).
There are three possible options:
define('RESTORE_POLICY', 'always');
This disables the protection. This is the same functionality as in version 8.6.
define('RESTORE_POLICY', 'never');
This enables the protection, preventing database restores.
define('RESTORE_POLICY', '2012-12-21');
This temporarily disables the protection on the given date. This format is recommended if you wish to temporarily enable restores, as it guards against the possibility that you forget to turn it back off later!
We've dropped support for MariaDB and no longer do testing on it. (Actually, we never "officially" supported it, but used to do testing on it unofficially.)
The reason for this is that MySQL introduced some new functionality that we now use in a few places, that MariaDB doesn't have, and doesn't plan to add.
We are now recommending that you use either MySQL 5.7, or the equivalent version of Aurora.
Most special pages can now be hidden if not required.
Also special pages are no longer automatically created in every enabled language, but may still be added manually if you need them.
Existing translations of special pages may now be trashed/deleted/hidden if not needed.
If a module uses the classes folder, then for every admin box/Organizer panel/visitor plugin there will need to be a class file present. Zenario will display an error if a class file is missing, as well as inform where the file is expected, and what the class definition should be. If a module stops working because of this problem, you need to create a class file.
Previously the Content Summary List plugin would work when filtering by category was enabled, but no categories were selected. Now the filtering will need to be disabled, as otherwise the plugin will not display any results.
In Zenario 8.6 and earlier, we had a directory full of reference files aimed at developers called zenario/api/.
We originally named it "api" because when it was first created it contained reference files with lists of API functions into Zenario's core that plugin developers could call to interact with the CMS.
However now there are many more different types of file in this directory, containing references on more things than just the Zenario core functions, so we've renamed it to zenario/reference/, to make the reference files easier to find if someone's browsing the filesystem.
In 8.7 we've rewritten how a developer flags that their FEA plugin is a list-type plugin or a form-type plugin.
Before, we had you write a JavaScript method to decide, however from version 8.7 there is now a new TUIX property to decided this. Now, all of the YAML files for your FEA plugins/modes need to contain either:
fea_type: form
or
fea_type: list
(depending on which type of FEA plugin you are writing).
You must set this, otherwise your FEA plugin will not do anything, and the property must be written in your .yaml file and it can't be changed in PHP. (The reason for that is it’s actually needed before your plugin is loaded.)
(You may also need to clear the site cache and do a browser reload if you've just changed it but your changes are not yet appearing.)
You no longer need to write the typeOfLogic() JavaScript method, and should delete it anywhere you’ve used it before.