Ticket #246 (closed task: duplicate)

Opened 7 years ago

Last modified 12 months ago

New config parameter: additional_stylesheets

Reported by: BrianKoontz Owned by: unassigned
Priority: normal Milestone: 1.3.3
Component: architecture Version: 1.1.6.5
Severity: normal Keywords:
Cc: JavaWoman, DotMG, DarTar

Description (last modified by BrianKoontz) (diff)

There is no way I can tell to add additional CSS stylesheets to the <head> section of Wikka output without modifying header.php. For plugins, it would be convenient to permit the specification of additional stylesheets in wikka.config.php. I propose a new config parameter, "additional_stylesheets", that would allow users to specify a space-delimited set of additional stylesheets, depending on the plugins they are using. This would also alleviate the problem of polluting the Wikka core stylesheets with plugin CSS elements. A future package manager would simply add its stylesheet to the user's existing list of stylesheets:

additional_stylesheets = "bookmarkmgr.css someotherplugin.css"

To implement, add the following codeblock to actions/header.php: 

    <link rel="stylesheet" type="text/css" href="css/<?php echo $this->GetConfigValue("stylesheet") ?>" />
// Change starts here:
<?php
    if($this->GetConfigValue("additional_stylesheets") != NULL) {
        $sheets = preg_split("/[\s]+/", $this->GetConfigValue("additional_stylesheets")); 
        foreach($sheets as $sheet) {
            echo "<link rel=\"stylesheet\" type=\"text/css\" href=\"css/".$sheet."\" />\n";
        }
    }   
?>

Related tickets

  • #446 - xtensible architecture for Wikka components
  • #817 - Hooks to preprocess page output
  • #842 - Normalize separators in config file

Change History

Changed 7 years ago by NilsLindenberg

Nice idea Brian! However, this hack still involves managing the config entry. So perhaps we can take this idea even further? Since we use an output buffer, we could place a token instead of the css into the header. And very time we include an action, Action() could trigger someting like AddStylesheet() which would look if a) a style sheet with the given name / path exists (depends on giving AddStylesheet a path or simply the name of the action) and b) if it hasn't been included yet. Both a) and b) beeing true, it would add the stylesheet to an array. At the end of processing the page another function would replace the token placed in the header with the list of the style-sheets. So the only thing necessary would be to copy the action and the stylesheet into their directories. Handlers could be managed the same way. Disadvantage: a lot of css files.

Changed 7 years ago by Brian Koontz

Yes, I agree, a hook would be preferable over modifying the config file!

Changed 6 years ago by BrianKoontz

  • type changed from enhancement to task
  • component changed from core to architecture
  • milestone changed from 1.1.7 to 1.2

A good time to address this issue will be when plugins are addressed (#287). I'm changing the milestone to match the plugin ticket.

Changed 6 years ago by DotMG

(In [420]) refs #246, #456

Processing content body before header and footer. Adding new method called AddCustomHeader() and a variable $additional_headers

'd like to close ticket #246 with these changes.

Changed 5 years ago by BrianKoontz

(In [1227]) Backport of AddCustomHeader() functionality. Refs #804, #246.

Changed 5 years ago by JavaWoman

(copied from #804 - some of this may appear in 1.1.6.6, the rest could be done later - or not :))

Interesting... I'd already added AddCustomHeader() to my local Wikka copy last year, but when I looked at it again now concluded it needs more work to make it really useful ;)

Oh, and adding things "to the <meta> header" is incorrect, of course - don't know where that came from - should be "to the <head> section".

I haven't gone further yet than making these notes, but I'm thinking along the following lines:

  • start with an array with standard headers, one subset per tag
  • adding a header would add an entry to the appropriate subarray, with an option to specify priority (a higher priority header should come later to override a previous one - needed for both CSS and JavaScript)
  • potentially this could also replace, or even delete a header from the array
  • then when it comes to page output, have header.php (or a subroutine of that!) go through the array to produce the whole <head> section - this should come last of all, so other bits (even footer.php) have a chance to adapt/add headers

A (much) later refinement might be to merge CSS to one file and "cache" that - Drupal can do something of the sort (but it's not simple).

Anyway, just some ideas to ponder...

Changed 5 years ago by DarTar

  • cc JavaWoman, DotMG, DarTar added
  • version set to 1.1.6.5
  • reporter changed from Brian Koontz (brian@… to BrianKoontz

(note: title and description need to be updated to match #804 !)

FYI there's a related issue here: http://wush.net/trac/wikka/ticket/446#a2.Directives where we suggest that actions and handlers may include directives to control the kind of headers (both HTTP headers and HTML headers) sent along with the page. These directives will probably need to operate through something similar to the AddCustomHeaders() method.

Also relevant to this ticket is the proposal (I can't find the ticket, but it's a longstanding discussion with DotMG, similar to the points made by JavaWoman in the comment above) to store the output of the Wikka formatter in a variable before sending it to the browser to enable some kind of preprocessing. Output preprocessing can be useful for afterburner rendering (e.g. typographic engines to use correct entities for punctuation). However output preprocessing might also be needed by actions that, instead of adding content to the page, control how the page is displayed, modifying headers or page-level attributes. For instance, we could have an action to override the default title generated via PageTitle() or an action adding custom CSS to the current page.

Changed 4 years ago by DarTar

  • description modified (diff)

Changed 4 years ago by BrianKoontz

  • description modified (diff)

Changed 4 years ago by BrianKoontz

  • status changed from new to closed
  • resolution set to duplicate

Incorporated by reference in ticket #446.

Changed 4 years ago by BrianKoontz

  • description modified (diff)

Changed 12 months ago by BrianKoontz

  • milestone changed from 2.0 to 1.3.3
Note: See TracTickets for help on using tickets.