It is currently Wed Aug 16, 2017 10:47 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Mon Jan 09, 2012 3:47 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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:
* 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...


Top
 Profile  
 
PostPosted: Mon Jan 09, 2012 9:31 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 09, 2012 11:15 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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:
<?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?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 10, 2012 7:13 am 
Offline

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

Quote:
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.

Quote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group