Page 1 of 2

Mediawiki upgrade from 1.24 to 1.30

Posted: 21 Jan 2018, 13:02
by webwit
I've updated mediawiki on a copy running at:

http://staging.deskthority.org/wiki/Main_Page

Username: dtstaging
Password: InigoMontoya

(These details are not secret, it's just to prevent bots indexing our staging area.)

Please check if everything works as it is supposed to do, and post any findings below, before I update the main install.

Two things I've found:

In the left navigation area, obviously the logo is placed too low, the title of the first navigation block is missing ("NAVIGATION"), and there are horizontal lines at the top of the blocks.

This seems to be because Beardsmore put some custom css rules in:
http://staging.deskthority.org/wiki/Med ... Common.css
which no longer work supposedly because of skin css updates in this version with slightly different css rules.

Can someone fix that?

Also the rss feed is no longer working on the main page, this extension is no longer available because it wasn't updated after a security exploit was found. Personally, I don't mind.

Posted: 21 Jan 2018, 13:13
by Daniel Beardsmore
My password isn't recognised in the staging wiki — is that to be expected?

I never cared for that RSS panel anyway.

Posted: 21 Jan 2018, 13:23
by webwit
Works for me.

It's probably this new setting in the phpBB auth extension, which was true by default but I changed it into false after reading the comments. Do you login as "Daniel Beardsmore" or "Daniel beardsmore" ?

Code: Select all

$wgAuth_Config['UseCanonicalCase'] = false;      // Setting this to true causes the mediawiki usernames
// to match the casing of the phpbb ones (except with
// the first letter set uppercase.)
// Setting this to false causes usernames to be all
// lowercase except for the first character.
// Before June 2016 this setting was always false,
// changing it to true on an install where it previously
// was false will cause users with uppercase characters
// to appear as separate users from their previous
// all-lowercase account.

Posted: 21 Jan 2018, 14:12
by Daniel Beardsmore
I tried both, neither one works.

Posted: 21 Jan 2018, 14:22
by 002
I can't login with my deets either...

Posted: 21 Jan 2018, 14:24
by Myoth
Image

The categories are off (even after refreshing).

EDIT : I can login with my username/ password on the staging site.

Posted: 21 Jan 2018, 14:27
by 002
Looks like the References section for a lot of pages will need to be tidied up as the tag is visible:
References.png
References.png (4.76 KiB) Viewed 85912 times
Edit: This might be my fuckup actually. I think the closing tag is wrong... :oops:

Posted: 21 Jan 2018, 14:31
by Daniel Beardsmore
It's not page tidying — the extension that provides that tag isn't working properly if at all.

Posted: 21 Jan 2018, 14:34
by webwit
Please try again to login.

Posted: 21 Jan 2018, 14:37
by 002
Daniel Beardsmore wrote: It's not page tidying — the extension that provides that tag isn't working properly if at all.
Actually I think (as per my edit) that it's just a mistake with my closing tag. Reference sections on other pages seem OK.
Also, I can log in now.

Posted: 21 Jan 2018, 14:38
by webwit
Check. It was checking the password against an older phpBB database copy on staging. :D

Posted: 21 Jan 2018, 14:40
by webwit
Myoth wrote: Image

The categories are off (even after refreshing).
Anyone else having this problem? Looks fine here with multiple browsers.

Posted: 21 Jan 2018, 14:44
by Myoth
webwit wrote: Anyone else having this problem? Looks fine here with multiple browsers.

It now looks like this, I have my browser zoom at 90% if that matters


Image

Posted: 21 Jan 2018, 14:48
by 002
I have the same as Myoth. It's even worse when you expand the categories.

Posted: 21 Jan 2018, 15:11
by webwit
Hmm yeah that's quite shit.
https://phabricator.wikimedia.org/T92767

Posted: 21 Jan 2018, 15:29
by webwit
I tried reverting that extension, but that didn't fix it.

Posted: 21 Jan 2018, 16:23
by Daniel Beardsmore
OK, CSS is patched.

I see that the editing tabs (Wikitext/Preview/Changes) across the top of a page edit box didn't make it across — can that be resurrected?

Posted: 21 Jan 2018, 16:55
by tactica
Everything looks OK from here...
Daniel Beardsmore wrote: I see that the editing tabs (Wikitext/Preview/Changes) across the top of a page edit box didn't make it across — can that be resurrected?
Those tabs are available at the time of this posting.

PS. This may be a good time to check whether renaming several pages at once works now :)

Posted: 21 Jan 2018, 17:09
by Daniel Beardsmore
The one thing that would be nice to have working is whatever it is that's stopping SVG images from having sans-serif text. Selecting "sans-serif" produces badly-kerned, badly-rendered serif text, and has done since the server move. I'm guessing all the basic typefaces are missing as it should be able to find some sans-serif typeface!

Posted: 21 Jan 2018, 20:42
by webwit
I narrowed down the category tree bug...

It used to display it in a <table> with three columns defined by <td style="width: 33.3%;">, and now it does "proper" css columns. This has the advantage that on smaller/mobile screen, it automatically adjusts to two or just one column.

However, it works erratically it seems. For example here it works fine:
http://staging.deskthority.org/wiki/Cat ... s_by_brand
Although it does have the same effect of reordering to fit the column heights.

It just doesn't seem to like a smaller number of items per column, and then a large subcategory.

I've inserted this code into includes/CategoryViewer.php. I combined the new and the old code. If I change the "if (1)" to "if (0)", it uses the old code, and it works fine. So I guess we should use this lame patch. It doesn't scale as well on mobile, but at least it is not bugged. Can anyone think of a better solution?

Code: Select all

	static function columnList( $articles, $articles_start_char ) {
		// New style
		if (1) {
		$columns = array_combine( $articles, $articles_start_char );

		$ret = Html::openElement( 'div', [ 'class' => 'mw-category' ] );

		$colContents = [];

		# Kind of like array_flip() here, but we keep duplicates in an
		# array instead of dropping them.
		foreach ( $columns as $article => $char ) {
			if ( !isset( $colContents[$char] ) ) {
				$colContents[$char] = [];
			}
			$colContents[$char][] = $article;
		}

		foreach ( $colContents as $char => $articles ) {
			# Change space to non-breaking space to keep headers aligned
			$h3char = $char === ' ' ? '&#160;' : htmlspecialchars( $char );

			$ret .= '<div class="mw-category-group"><h3>' . $h3char;
			$ret .= "</h3>\n";

			$ret .= '<ul><li>';
			$ret .= implode( "</li>\n<li>", $articles );
			$ret .= '</li></ul></div>';

		}

		$ret .= Html::closeElement( 'div' );
		return $ret;
		}

		// Old style
		else {
		$columns = array_combine( $articles, $articles_start_char );
		# Split into three columns
		$columns = array_chunk( $columns, ceil( count( $columns ) / 3 ), true /* preserve keys */ );

		$ret = '<table style="width: 100%;"><tr style="vertical-align: top;">';
		$prevchar = null;

		foreach ( $columns as $column ) {
			$ret .= '<td style="width: 33.3%;">';
			$colContents = array();

			# Kind of like array_flip() here, but we keep duplicates in an
			# array instead of dropping them.
			foreach ( $column as $article => $char ) {
				if ( !isset( $colContents[$char] ) ) {
					$colContents[$char] = array();
				}
				$colContents[$char][] = $article;
			}

			$first = true;
			foreach ( $colContents as $char => $articles ) {
				# Change space to non-breaking space to keep headers aligned
				$h3char = $char === ' ' ? '&#160;' : htmlspecialchars( $char );

				$ret .= '<h3>' . $h3char;
				if ( $first && $char === $prevchar ) {
					# We're continuing a previous chunk at the top of a new
					# column, so add " cont." after the letter.
					$ret .= ' ' . wfMessage( 'listingcontinuesabbrev' )->escaped();
				}
				$ret .= "</h3>\n";

				$ret .= '<ul><li>';
				$ret .= implode( "</li>\n<li>", $articles );
				$ret .= '</li></ul>';

				$first = false;
				$prevchar = $char;
			}

			$ret .= "</td>\n";
		}

		$ret .= '</tr></table>';
		return $ret;
		}
	}

Posted: 21 Jan 2018, 21:55
by Daniel Beardsmore
What is meant to have changed?

Posted: 21 Jan 2018, 22:21
by webwit
The fix is currently not enabled because maybe someone has a better fix.

Posted: 21 Jan 2018, 22:38
by Daniel Beardsmore
I am not even sure what the solution is, because even if you had proper control over column breaks in CSS, inline category expansion only works if the column sizes are static, and in which case, what is the real advantage of CSS columns in the first place? I guess you could use CSS to handle the dynamics and then use JavaScript to "fix" the columns in their height, and then temporarily switch off the fixed heights each time the window is resized or old-school scaling is applied …

Posted: 21 Jan 2018, 22:46
by webwit
The patch is now enabled. It's now using the old method. Of course, it won't survive a next update (unless reapplied).
Daniel Beardsmore wrote: The one thing that would be nice to have working is whatever it is that's stopping SVG images from having sans-serif text. Selecting "sans-serif" produces badly-kerned, badly-rendered serif text, and has done since the server move. I'm guessing all the basic typefaces are missing as it should be able to find some sans-serif typeface!
Can you send me such an svg?

Posted: 21 Jan 2018, 22:54
by webwit
Daniel Beardsmore wrote: OK, CSS is patched.

I see that the editing tabs (Wikitext/Preview/Changes) across the top of a page edit box didn't make it across — can that be resurrected?
It's there? Kicks in a bit late with javascript. Although both are a setting I once enabled, and it seems they are no longer "supported", and where taken out of the documentation:
https://www.mediawiki.org/w/index.php?t ... id=2640582

Posted: 21 Jan 2018, 23:43
by Daniel Beardsmore
webwit wrote: Can you send me such an svg?
See the diagram here:

[wiki]UKF DS03[/wiki]

It's incorrectly rendering as serif face, with kerning that would make Signature Plastics proud.

Posted: 22 Jan 2018, 10:40
by webwit
Ok I managed to fix it.

It launches a shell command to generate the png, e.g.:
rsvg-convert -w 681 -h 385 /tmp/test.svg -o /tmp/test.png

Which works fine with the correct font. Until I tried it as the web server user:
"Fontconfig error: Cannot load default config file"

Which is in /etc/fonts/fonts.conf, here it maps font names to actual fonts. It does generate the png without this file, but with shit fonts.

For some reason the web server user couldn't see /etc/fonts/ but it could see /etc/mail/ with exactly the same file permissions:

Code: Select all

drwxr-xr-x  root  root   ?                                fonts/
drwxr-xr-x  root  root   ?                                mail/
...while SELinux seems disabled:

Code: Select all

> sestatus
SELinux status:                 disabled
However, it turned out the web server user was in a "jailed shell", which I changed into a normall shell, which fixed it. Jails, how do they work? I don't know, but it works now. This most likely improves font rendering on other svg as well.

Posted: 22 Jan 2018, 12:36
by andrewjoy
Jails ?

Thats a BSD thing.

Its a whole copy of the OS running on-top of the OS ( its not quite this but for discussion lets say it is) its for security between apps, so say if you had a server, the web server would run in one jail and the mail server in the other and they cannot see one another unless you mount a folder between them.

Posted: 22 Jan 2018, 12:46
by webwit
Not that kind of jail. Apparently it uses VirtFS (of which I know nothing) here to jail a shell.

Posted: 22 Jan 2018, 22:18
by Daniel Beardsmore
As I recall, a jail gives you a virtual root directory that can only see approved parts of the machine. It's not an especially intuitive name!