<?= ?>
(from <?php echo ?>
) Because I felt like it. I wanted to years ago, in my beginning of this project, but my web host was still on some 5.3 version of php, and didn't always have 'em enabled. But now, as php is up to v7.something, and most hosts have, at least, php 5.4, it seems like a safe move at this point. If not, oh well!The $ACCESS_ROOT option has been reimplemented and is now fully functional*. This option limits access to a specified folder (and it's sub-folders). To use, just specify a valid path relative to the root of the website (no leading slash).
(*Well, as best as I can tell...)
All OneFileCMS configuration variables that reference external files ($CONFIG_file, $LANGUAGE_FILE, $WYSIWYG_PLUGIN) must be specified in one of two ways:
Slightly adjusted how wysiwyg plugins are implemented - removed $WYSIWIG_SOURCE config variable.
(It's value is now specified directly in the "init" file specified by $WYSIWYG_PLUGIN.)
Two steps forward, one step back...
Just for now - removed the $ACCESS_ROOT option. I was coding in circles and getting no where while trying to reconcile various issues:
A solution is in the works, but I'm going to take some time to make sure no new problems are introduced by the eventual fix. (hahaha...) It will probably end up being simple, but it's not yet...
Just a general note on security: due to the fundamental structure of OneFileCMS - primarily that it's one file, and that there is no seperate database for authentication - there are certain inherent security limitations that should be kept in mind:
Of course, everything comes with a price (exacerbated by my apparent lack of testing...)
WYSIWYG is here!
Due to popular demand (ie: it has been requested more than once), WYSYWIG editors can now be "plugged in" and used with OneFileCMS. Currently, only TinyMCE and CKEditor have been tested (and on a very limited scale). Others may work - but I don't know yet. And, naturally, the use or inclusion of such editors is completely optional, of course.
No actual WYSIWYG editors are included with OneFileCMS - any desired editor must be obtained seperately.
A brief how-to on using either editor can be found in their respective sample "init" files included in the plugins folder of the OneFileCMS repo. Any suitable init file for a given editor may be used, as long as the correct path to the editor's javascript source file is specified, and - for CKEditor - the id of the OneFileCMS textarea, "file_editor", is also be specified.
Now, while everything seems to work, I have little to no experience using TinyMCE, CKEditor, or any other such application. So, if there is something missing or not working as expected, please let me know (open an "issue" on the Issues page).
Notes:
These editors have their own, extensive, event controls (responses to keyboard & mouse input), so the OneFileCMS edit page event scripts are not loaded when an editor is in use. The primary effect is the loss of incidental file status indicators - [Save] will not change to [SAVE CHANGES!], background color will not change, etc., and any "unsaved changes" alerts should be handled by the active editor. Also, the [Wide View] button will be unavailable.
The TinyMCE "init" file included in the OneFileCMS repo specifies the use of the TinyMCE "fullpage" plugin, which produces an "unsaved changes" alert every time you exit the Edit page - even if no changes have been made to the file in the editor.
The CKEditor, on the other hand, does not seem to present an alert at all when you leave the editor page - even with unsaved changes.
Added client-side hashing of passwords. This is primarily a benefit for the user, as it does not really add any security to the server side application that uses it (such as OneFileCMS). The reason is that this "pre-hash" simply becomes the actual password as far as the server is concerned, and is just as vulnerable to exposure while in transit. However, it does help to protect the user's plain-text password, which may be used elsewhere.
Also added a "please wait..." message while computing the client-side hashes - primarily for IE versions < 9, which are MUCH slower than FF or Chrome (by a factor of 37 or more). Subsequently, the number of iterations for the client-side hashing is quite low (compared to the server side), but still causes a 1 - 2 second delay on the login screen, and a 3 - 6 second delay on the Change Password screen. On FF and Chrome, however, the delay is much shorter, almost unnoticable.
I want to thank fermuch for the client-side hashing suggestion. While a somewhat different approach was ultlimately employed, his original solution provided the insight needed to approach the idea in general.
OneFileCMS is now actually ONE FILE! No external style sheets or icons.
(Of course, external style sheets & icons can be added back in, if you like.)
This is OneFileCMS "Lite", and will be maintained along with v3.0