Dotclear

A tiny update to fix a problem which prevents the backend for new installation from correctly displaying (updates are not concerned). A too strict application of the CSP (Content-Security-Policies) is the cause of it. It also demonstrates that this protection might be efficient!

Your dashboard should also offer you to upgrade your installation today or tomorrow (depending on your settings). There's also a patch for the developers who prefer this method.

We should celebrate the 13th anniversary of Dotclear today so here it is, the 2.10 release is available now and very soon on your dashboard^[1]!

The menu of this release (non exhaustive list, see CHANGELOG for further details) :

• Some vulnerabilities have been fixed
• Lot of bugs killed (some may still remain)
• A new template-set, named dotty, using as far as possible the new HTML5 semantic tags
• New options to customize and improve the use your Dotclear backend (favorites folders in media manager, optional columns for posts and pages lists, …)
• Implementation of the Content-Security-Policies for the backend, prelude to an implementation in public side (blogs) for the future 2.11 release^[2]
• New facilities and opportunities for plugins developers (they are detailed below)
• Some javascript libraries have been updated (CKEditor, Codemirror, …)

Not a revolution but developments for a more secure and robust application ; and finally, happy birthday Dotclear \o/

PS : This release requires PHP 5.3 at least but I would strongly advise you to switch to PHP 5.6 or PHP 7 without delay — this last one offers a very welcome increase in speed. Anyway, the next version of Dotclear might require a newer version than the already obsolete 5.3.

Some technical details for plugins (and themes) developers and for blogs administrators:

CSP, aka Content-Security-Policies

Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.

[ Wikipedia « Content Security Policy » ]

The parameters used (activation and directives) are available via the about:config module (System settings menu, see “system” part) ; these parameters are:

• csp_admin_on : activation/deactivation
• csp_admin_default : default-src CSP directive
• csp_admin_img : img-src CSP directive
• csp_admin_script : script-src CSP directive
• csp_admin_style : style-src CSP directive

A 3rd party plugin needing some external services may complete one or many of these directives using the behavior adminPageHTTPHeaderCSP which provides as parameter an key-indexed array. Each of these keys refers to the according CSP directive (see list above), its value giving the list of authorized sources (separated by space).

Example :

Imagine a plugin using the Google Maps API (for scripts), it should add the corresponding Google server by this way:

$core->addBehavior('adminPageHTTPHeaderCSP',array('myAdminBehaviors','adminPageHTTPHeaderCSP'));

class myAdminBehaviors
{
	public static function adminPageHTMLHead($csp)
	{
		if (isset($csp['script-src'])) {
			$csp['script-src'] .= ' maps.googleapis.com';
		} else {
			$csp['script-src'] = 'maps.googleapis.com';
		}
	}
}

Private folder /var

A new folder, named var, has been created with the 2.10 release of Dotclear. It is at the main level (as the cache folder is) and should be used for local storage that should normally not be set in cache folder. Note that this cache folder may be deleted at every moment without any negative consequences for the installation.

A new constant, DC_VAR, is available and may be customized in the config.php file in order to build paths. Two new functions are also available to retrieve URLs:

• dcPage::getVF() for an URL based on the backend root URL of the installation
• dcBlog::getVF() for a public URL (based on the public URL of the blog)

Plugin developers are encouraged to create their own directory within this directory /var to maintain a semblance of order.

Code highlighting with Codemirror

The Codemirror library, used by the theme editor, is now available (in the backend) for every plugin. Two functions are available to load and run this library :

• dcPage::jsLoadCodeMirror() for loading
• dcPage::jsRunCodeMirror() for running

Example for CSS code :

# Get interface setting
$core->auth->user_prefs->addWorkspace('interface');
$user_ui_colorsyntax = $core->auth->user_prefs->interface->colorsyntax;
$user_ui_colorsyntax_theme = $core->auth->user_prefs->interface->colorsyntax_theme;

# in <head>
if ($user_ui_colorsyntax) {
	echo dcPage::jsLoadCodeMirror($user_ui_colorsyntax_theme,false,array('css'));
}

# in <body>
if ($user_ui_colorsyntax) {
	echo dcPage::jsRunCodeMirror('editor_css','css_content','css',$user_ui_colorsyntax_theme);
}

Turning on (or off) syntax highlighting and choosing the theme to use (among the forty+ proposed) are in "My Preferences", "My options" tab.

If you need more information about the technical stuff, use the forum and/or the development mailing-list, or also the #dotclear IRC channel (irc.freenode.net) where some of us sometimes hang…