Wow, I'm a little confused, and actually shocked at the same time. I hope I'm misunderstanding what you're talking about.
Let's establish this up front: all the HTML returned to the browser, in the case of MediaWiki and phpBB, is provided via PHP. All of it. Every last line.
Per user forum/wiki style are selected from a pre-set pulldown. For phpBB, this is labelled "Board Style" in Profile; for MediaWiki, "Skin" under "My Preferences". Thus, the style name the user wants is stored in some sort of DB/config file/whatever (along with everything else; shown username, password, their preference for date/time formatting, language choice, blah blah).
The style CSS itself therefore can/should be a flat file. Neither MediaWiki nor phpBB have support for "customise EVERYTHING", nor should they (IMO). Consistency is good when it comes to presentation of text content.
Said PHP scripts would therefore already know what style the user wants, and therefore within <head> simply reference the applicable CSS. The PHP scripts absolutely have some kind of hash (or at bare minimum, lookup function) that can return the users' preferences. Thus, for CSS, all the script has to do is:
Code: Select all
<?php
$userstyle = $prefshash{"style"};
echo '<link type="text/css" media="screen" href="/styles/',
$userstyle,
'.css" />',
"\n";
?>
The browser then fetches /styles/$userstyle.css from the web server, which can be configured to handle gzip compression for text/css MIME types, or whatever else.
For languages (since I mentioned them), somewhere within the code/application someone stores English texts, Hungarian texts, Japanese texts, etc.. The PHP scripts already have to extract that from wherever (since it's being output in the HTML), so moot point again I think.
For JavaScript, same thing. <script type="text/javascript" src="$whatever.js"></script>. Done.
I don't see what kind of user-level customisations would be needed on a per-account/per-profile basis in MediaWiki or phpBB at the CSS or JavaScript level.
Neither MediaWiki nor phpBB offer a per-user way to customise the styles (CSS) or JavaScript returned; WordPress does this, and therefore the whole "load.php" concept for WordPress makes more sense. Though, admittedly, there ARE ways to do this with flat files but that often doesn't scale well when you have 50,000 viewers all viewing something unique at the same time.
My point is that somewhere within the PHP code there has to be handlers/code that exists to echo back certain types of crap to the browser. Thus, "load.php" really solves absolutely nothing other than adding more abstraction solely for the benefit of "having everything stored in a database", which is the wrong mentality.
In the case of MediaWiki, I did spend a little time looking at ResourceLoader, and all I see is a bunch of buzzword bullshit. They argue the extension/model allows for optimisations by not returning content that isn't needed for the individual browser type/version; so then don't include that <script> or <link> line. Good grief.
So where's the problem / what am I missing here?