[dokuwiki] New PR: Css modification actions

  • From: "gamma" <wiki@xxxxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Thu, 9 Feb 2017 14:39:35 +0100 (CET)

Hi,

gamma opened a new pull request at 
https://github.com/splitbrain/dokuwiki/pull/1830:

This is the second part of the #1002 PR - which I think should be closed now.

There is a new event `CSS_CACHE_USE` which unifies the cache usage of js.php 
and css.php (js.php already has it). The CSS generator can now make use of this 
special event to determine whether the cache may be used or not.

The `css.php` and `themplate.php` have been updated to support different 
flavours which will result in different requests for the css resource. This 
allows template creators to not only structure by different files but also 
requests. Using the new event `CSS_STYLES_INCLUDED` site owners - and plugin 
creators - can decide which styles of the core or other plugins should be send 
to the browser at which time or view mode.

  * new event: `CSS_STYLES_INCLUDED`
    * plugins can modify the list of files that will be used for this media type
    * plugins can modify the encapsulation string (default: `@media 
$mediatype`) and whether to encapsulate at all
    * plugins can prevent a media type and flavour from being printed at all
    * there is a special media type `DW_DEFAULT` to indicate the default 
interwiki and file icon styles (which can be prevented)
    * the resulting file list will influence the cache

### Motivation

I think it is good to have more options to customise the css output. We're 
using DW for our professional website in a readonly mode. It is therefore not 
necessary to include styles and scripts that are only really used for editing 
or admin or user management purposes. Also, we mostly want our own custom 
styles only with the DW backend - so the default styles are not really needed 
as well.

The changes allow us to implement:

  * a plugin that controls what is send to our visitor - especially from the 
default styles
  * an extra flavour with e.g. administrative styles and styles for the media 
manager that is only delivered to admins/editors.

I gave the last point some thought. I wanted the template to be able to split 
its css into flavours (as I call them now) - or chunks. This way it is easier 
to define certain modes. The problem is: at which point in the request of the 
page do we bring everything back together (multiple requests vs. many checks in 
the css.php).

First I implemented flavours to be checked in the `css.php` by adding them to 
the `style.ini` and putting an extra [stylesheets:flavor] section in it. But 
the output from parse_ini_file would have to be post processed. I thought about 
the array syntax in the ini file, but I think it is harder to read and 
understand (`my_style.less[flavour1,flavour2] = screen`).

A subdirectory for multiple ini files could have worked, but needed more code 
on the css.php as the current solution. I think that reading the filenames of 
all ini files for a template and putting each of them into the list of 
stylesheet files is a good compromise.

What I'm not sure about for the current solution is whether we should restrict 
the flavours to: 'always', 'editor', 'manager, 'admin' - corresponding to the 
permissions of DokuWiki. Also: there could be special RTL definitions by having 
either a 'rtl.ini' or 'admin-rtl.ini'

I hope that most of this makes any sense to you, but I'm happy to discuss and 
improve the changes.

Please help us to review this pull request, so new contributors get feedback in 
a timely manner.

310caf00-eecd-11e6-9e2b-d0aa3f33c2ba


-- 
DokuWiki mailing list - more info at
http://www.dokuwiki.org/mailinglist

Other related posts:

  • » [dokuwiki] New PR: Css modification actions - gamma