MediaWiki 1.18.0 now in place -- weekly archives offline

Discussion about the site's wikis, including bugs/issues encountered.

Moderator: Moderators

Post Reply
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

MediaWiki 1.18.0 now in place -- weekly archives offline

Post by koitsu »

I upgraded the nesdev wiki from 1.15.5 to 1.18.0 a day or two ago, per this thread.

Since then, things seem to be working, but I need folks to browse around and make sure everything looks OK. If folks could do that I'd appreciate it.

However, there's one major drawback: it appears that starting with MediaWiki 1.17.x, the developers moved away from using flat files for CSS and JavaScript bits and instead "siphon" the data through PHP. This is documented in the MediaWiki 1.17.x release notes as follows:

Code: Select all

* ResourceLoader, a new framework for delivering client-side resources such as
  JavaScript and CSS, has been introduced. These resources are now delivered
  through the new entry point script "load.php", instead of as static files
  served directly by the web server. This allows minification, compression and
  client-side caching to be used more effectively, which should provide a net
  performance improvement for most users.
Why this is a problem: this badly breaks CSS/JavaScript for the "weekly archive" that folks wanted so badly so they could view the Wiki while without a network connection; Banshaku has verified the breakage. Specifically, the dumpHTML extension does not deal with this situation well. Technically I understand why, and do not believe there is an easy solution for this; alternate tools like wget --recursive and so on will not address the problem either.

As such, I've disabled the weekly archive generation and taken them offline for the time being. I need to get an idea of how many people use the archive, because I really don't see a way to solve this problem easily.

Too much software is doing this crap these days, and for no good reason; why people can't let the actual web server/daemon do its job I'll never know. Sigh...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: MediaWiki 1.18.0 now in place -- weekly archives offline

Post by tepples »

koitsu wrote:Too much software is doing this crap these days, and for no good reason; why people can't let the actual web server/daemon do its job I'll never know. Sigh...
Probably because the actual web server/daemon has no concept of MediaWiki or phpBB user accounts and thus can't send the correct customized style and script for each user based solely on the session cookie. Or did you want MediaWiki and phpBB to use HTTP Digest authentication instead?
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu »

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?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

koitsu wrote:Per user forum/wiki style are selected from a pre-set pulldown.
Say you either A. have a script that combines the style selected with the preset pull-down with the user style to form one file (that gets cached during the user's session), or B. send the style selected with the preset pull-down in one HTTP request, served from a static file, and send the user style in a second HTTP request. Which results in more PHP executions? Neither. Which results in more HTTP requests? B. What increases page load time? HTTP requests.
Neither MediaWiki nor phpBB offer a per-user way to customise the styles (CSS) or JavaScript returned
Since when? Wikipedia uses both user style and user script. I seem to remember turning user style on for Nesdev Wiki but leaving user script turned off because of past vulnerabilities.
They argue the extension/model allows for optimisations by not returning content that isn't needed for the individual browser type/version
Each <script> or <link> line incurs the latency of an HTTP request and response pair.
Post Reply