Page MenuHomePhabricator

Directory change for skins affected by rewrite rules.
Closed, InvalidPublic

Assigned To
None
Authored By
bzimport
Mar 21 2005, 2:47 PM
Referenced Files
F1909: phpinfo.html
Nov 21 2014, 8:16 PM
F1908: Screenshot.pdf
Nov 21 2014, 8:16 PM
F1906: Special_Specialpages.html
Nov 21 2014, 8:16 PM

Description

Author: ovvldc

Description:
I just upgraded to MediaWiki 1.4.0 from 1.3.x and found that all of my
formatting is lost. Opening page source showed that many " codes are now
rendered as '

These do not render and completely mess up all skins.

See this excerpt:

<div id='content'>
<div id='topbar'>
<table border='0' cellspacing='0' width='98%'>
<tr>
<td width='152' rowspan='1'>&nbsp;</td><td class="top" align='left' valign='top'>
<a href="/wiki/index.php/Main_Page" title="Main Page">Main Page</a>


Version: 1.4.x
Severity: blocker
OS: Mac OS X 10.3
Platform: Macintosh

Details

Reference
bz1727

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:16 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz1727.
bzimport added a subscriber: Unknown Object (MLST).

ovvldc wrote:

Special pages with broken rendering

Example

Attached:

ovvldc wrote:

I downloaded 1.4.0 at 11:40 CET from the Brussels mirror of Sourceforge.

Feel free to contact me privately to get rid of this bug.

jeluf wrote:

HTML specification allows usage of both " and ', see
http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2

Can you please tell us which browser you used? Exact version number and
operating system would be helpful, too.
What is rendered incorrectly, can you provide screenshots?

ovvldc wrote:

I used Mozilla Seamonkey 1.8ß2 running on Mac OSX 1.3.8. I get the same results
with Safari 1.2.4 (v125.12).

I will attach a screenshot in a minute and an anonimized php.info.

ovvldc wrote:

screenshot of broken rendering

Text renders, but the formatting is smashed.

Attached:

ovvldc wrote:

PHP info for more configuration details.

Attached:

ovvldc wrote:

The screenshot shows a classic skin with a floating left bar (well, it should).

Using monobook puts everything vertically in order, which makes it even harder
to find stuff..

ovvldc wrote:

Updating summary

I also noticed there are slashes in the code where I do not expect them. I can
send .js files and .css files as needed, but I just unpacked the 1.4.0.tar.gz
archive and moved it to my server directory so nothing should have gone missing.

rowan.collins wrote:

I couldn't immediately see what the problem was, but loading meta.wikimedia.org
in "Classic" skin, it looks to me like the CSS rules just aren't being loaded at
all. The most obvious error is the URL-expansions showing up on external links
(they should be hidden except for on print-outs).

Are the CSS files being loaded correctly? Are the paths to bits of the skin set
up correctly and accessible? I note that the logo in the top left has been not
found as well.

Note that the location of these files has changed completely from 1.3 to 1.4, so
make sure you've:

  1. put all the files in the right place
  2. set any newly created files, such as these, to be readable/servable by the

webserver

Try loading the CSS files referenced in the source directly in your browser and
see what happens (and maybe watch the server log while you do it)

ovvldc wrote:

OK, thanks everyone. I found it.

I put in some rewrites as per http://meta.wikimedia.org/wiki/Rewrite_rules

Those were still pointing at stylesheets, rather than skins. Oddly enough, I had
to restart and reload several times before the new skin came on line but it
works now.

Apologies for the fuss, and thanks again. An extra notice in the release notes
might be useful.

rowan.collins wrote:

(In reply to comment #10)

Oddly enough, I had to restart and reload several times before the new skin

came on line but it

works now.

That's probably caching - combinations of pointing at
"...page_title?action=purge" and holding down Ctrl/Shift/similar while clicking
"refresh" usually deal with the various kinds of problem this creates (the
former being to bypass *internal* caches when the actual page rendering has
changed).