FS#1897 Support multiple script (and style) files for plugins

Plugins

• 

  2010-02-19 adrianlang

  If a directory ›/script‹ or ›/style‹ exists, all files in it should be included.
• 

  2010-02-24 ryan.chappelle

  I'd rather welcome a mechanism to load a CSS file on runtime. An action plugin can load any available JS by issuing <link href> and PHP files can be loaded via include/require_once, but with CSS we're stuck.
  
  Not a bad idea, though.
  
• 

  2010-02-24 ChrisS

  Luis/Ryan, do you have a use case?  
  
  Typically, css & js is loaded once and cached by the browser for the duration of the session. The advantage in reduced web accesses outweighs the disadvantage due to increased file size.  This isn't because one extra file is a particular imposition, but because when you go this route you quickly end up with lots of little files. It doesn't take much extra latency to equate to a lot of extra bytes you could have included in your one big file.
• 

  2010-02-25 ryan.chappelle

  The one use case I can think of is if someone develops a plugin that affects page visuals and is based on modules, each one with its own CSS/JS. For example, a plugin that would "automatically" modify the CSS and JS calls to restyle the entire Wiki on certain holidays (X-mas, April's Fool, First Day of Spring, Sysadmin Day, No-CSS day, things like that).
  
  I was working on the next version of my "clock" plugin, but have stopped development because there is no way I could do the different modules truly modular (they would all share a CSS file) -- and I don't think there's much need or market for fancy sundial or binary or SVG 3D clocks in DokuWiki... The solution would be to go the same route the "command" plugin took, but I feet it was hardly worth it.
  
  
• 

  2010-02-25 ChrisS

  For the first one, Splitbrain has done that.  I'm not sure how.
  
  For the second one, you can differentiate the style by a class name in the outer container and prefix those style selectors that require it by the classname.  That prefixing could be done in some form of post processing.  
  
  However, I think your describing a case for some interaction between the css & js aggregators and the plugin.  I envisage a mini event for each plugin.  [css|js]_plugin_retrieve.  plugin data would be plugin name and a list of css/js files.  default action would be to read and concatenate all the files (for that plugin).  A before handler could alter the file list.  An after handler could change the css/js.
  
  Back to your original comment.  Individual JS and CSS files can be loaded using an action plugin and modifying the metaheaders with the TPL_METAHEADER_OUTPUT event, http://www.dokuwiki.org/devel:event:tpl_metaheader_output.  Store them with a name or location that isn't checked by the main aggregator script.  
• 

  2012-05-10 andi

  Some more thoughts on the original request first: Multiple script files can be loaded through our JS include mechanism. For CSS there's no such feature. You can use the @import mechanism but this will not be pulled through our CSS dispatcher and no replacements will be done.
  
  So I agree there's a need.
  
  Currently plugins can not only have a style.css but also a print.css or a rtl.css. Supporting these different output formats in a style/ directory would be difficult or messy.
  
  But supporting these different output files is somewhat deprecated (but not officially AFAIK) because you can address these different outputs through media queries.
  
  So the question is: should we implement it as suggested in the original ticket? I think we should, but I'd like to get some more feedback first.
• 

  2014-02-25 Klap-in

  Including the multiple style files is now possible since the use of the less parser.
• 

  2014-02-25 Klap-in

  see last comment