SHA1 is not an ideal password hash, even when salted, because it is cheap to compute. Since version 5.5 PHP offers bcrypt built in, which is a more expensive and secure hash function specifically suited for passwords
The prior code stored encrypted user data in the cookie that was then checked. This new approach is cleaner, as it only stores a token, and it does not use problematic crypto functions deprecated in PHP 7.2
!empty verifies that $username has been set with a significant value of any kind; is_string makes sure the type is really what is being expected in the following code.
Iconfont icons are of no value to screenreader users; in our case,
they get alternative text. By adding 'aria-hidden="true"' to the
<span> holding the iconfont icon, we avoid the screenreader trying
to announce the iconfont icon.
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.
- This introduces a new option "template_backend" that will be set to indicate the backend template, defaults to 2k11.
- The "Engine: xxx" line in info.txt still works, but only for the frontend
- The frontend fallback chain defaults to the old "default" template to ensure that themes will work that have "old-style" HTML output
- The backend fallback chain only falls back to 2k11 and then "default"
- In the future, we will remove templates/default/admin once the mechanism is proven stable
To test this in all cases you can:
- Copy 2k11/ to 2k11-custom, edit info.txt, give it a distinct name. Edit the admin/index.tpl file to add some code to ensure that you will see that template in the backend if you pick it, or adjust the style.css or whatever.
- Copy idea/ to idea-custom, edit info.txt, add a "Engine: 2k11" line. Now you can test how a template would look like that fallsback on 2k11 instead of "default"
Those permutations can be checked and come to my mind:
- Backend: 2k11, Frontend: 2k11
- Backend: 2k11-custom, Frontend: 2k11
- Backend: 2k11, Frontend: 2k11-custom
- Backend: 2k11, Frontend: idea
- Backend: 2k11, Frontend: idea-custom
- Backend: 2k11-custom, Frontend: idea
- Backend: 2k11-custom, Frontend: idea-custom
They seem to work.
Currently the display of backend and frontend theme in templates.inc.tpl takes up some larger space. Maybe it could be prettified somehow, maybe put frontend and backend template next to each other, not beneath each other? Maybe @yellowled has some suggestions.
@onli and @ophian - please have a look at this, since you both also worked on the fallback chains. Please tell me if you have issues with this. We can easily revert, if you see this approach as not workable. This is more a "proof of concept" draft.
Engine: default in info.txt will now lead to the template to use template/default as fallback before the default-template (2k11 currently). An approach to fix#130
Also, template_engine is not automatically set to default, as this was implicitly always the case
Debug-messages still may use echo, and some functions in functions_image and trackback still use it to generate progress messages, which should get cleaned up as well but is not that urgent
