Should've been tested in the alpha, but given the problems with the preview logic (see http://board.s9y.org/viewtopic.php?f=3&t=20791) I'm convinced we need this now. This mainly reworks serendipity_getTemplateFile to follow a simple scheme on where to look for templates – either in the backend or frontend, based on where we are but overridable, then in the engine, then in the defaultTemplate as fallback.
A first approach at fixing s9y for php 7, which makes it possible to
write an entry without any error message. The specific changes are: 1.
__construct for the plugin classes 2. Update Cache Lite to a modern
version to fix its similar constructor problem 3. Remove the
session_regenerate_id call from the session destructor (should get
re-added to session creation where necessary) 4. Remove error handler to
prevent silenced warnings from becoming fatal exceptions
This fixes the plugin tpl fallback for all plugins, already using the parseTemplate() method. All others, which may still follow the themes fallback (like contactform etc), would need to always be part of the user template $serendipity['template'], or be fixed later on.
This also fixes the backend chaining, which now simply follows the force with a possible engine and then uses $serendipity['template_backend'] (2k11), $serendipity['defaultTemplate'] (2k11), 'default'.
As a third, this now uses the correct preview_iframe.tpl file on save and checks for a correct set jquery_backend.js in the user theme $serendipity['template'].
Please double check this approach for cases I did not find yet. Thanks! :)
References #343
PHP 5.4 sets UTF-8 as the default for htmlspecialchars, htmlentities and html_entity_decode. The first two will echo an empty string when given a string with umlauts. This commits introduces serendipity_specialchar-wrapper that are meant to be a temporary solution for the s9y-core until PHP 5.6 fixed the bug, so the native charset option of s9y continues to work.
Instead of using global JS-variables and ignoring serendipity[textarea]={$view}, this
approach actually uses the variable and therefore reinstates wysiwyg_init.tpl.
ckeditor_custom_config.js (Thx Ian!) is still respected, but the toolbar got restored to the old version. We need an easy way to remove _underline_, for example. It could be extended though.
This fixes #{107} somewhat, as serendipity_image_selector.php is useable now, but still with display errors (and without an upload widget). Probably still a good idea to copy the ML-eapproach of the normal textareas
This also works with htmlnuggets, without using spawnnugget from the core, instead wysiwyg_init.tpl gets reused in the plugin-config.
ckeditor_custom_plugin.js got emptied, the relevant code (which should only be the part that adds the plugins into the toolbar) should be integrated into wysiwyg_init.tpl).
