Bug reports
GeSHi colourisation problems
I also found a weird problem in <ctype.h>. Apparently, int ispunct(int); looks weird with the coloring (int ispunct">ispunct(int); or something like that). Could you look into it? -- Gregory Pietsch 21:24, 5 February 2006 (GMT)
There were some duplicate entries in the list of keywords for the syntax highlighting, one being ispunct, and that was causing the problem. I've removed the most obvious duplicates. --Flash Gordon 21:42, 5 February 2006 (GMT)
The line of "=" in the diff listing a couple of sections down breaks editing the section after it. Instead you get the diff listing itself!
--Flash Gordon 00:35, 20 February 2006 (GMT)
sizeof still looks weird. Comments on the same line with preprocessor directives should be highlighted appropriately,too.
#include <string.h> /* memcpy() size_t */ /* above and below looks bad. */ sizeof
--Jannis 17:59, 14 March 2006 (GMT)
- It seems that removing '#' from the COMMENT_SINGLE array in C.php is a reasonable short-term solution to the comment problem. --Netocrat 03:43, 22 March 2006 (UTC)
- Also, GeSHi 1.0.7.8 has just been released allowing keywords to contain the # character. It would take a bit of mucking about since MW (sensibly) doesn't allow hashes in article titles, but we could get it to link preprocessor directives - not yet the standard headers of #include directives though... but see the new section I've added bottom-of-page. --Netocrat 13:00, 29 March 2006 (BST)
Test server's LocalSettings.php
Line 64 of LocalSettings.php reads:
include_once('/home/clc/LocalOverrides.php');
It would be handy if "out-of-the-box" that line specified a different file than the live server's as is done for the PrivateSettings.php file:
include_once('/home/clc/TestLocalOverrides.php');
GeSHi changes
It looks much better without the underlining of links - that one's a keeper. The test site changes that also remove the link symbol on php and other code blocks are improvements too. I'm not sure that removing all whitespace with ltrim is best though - it's only necessary to remove a single initial \n or \r\n - someone might intentionally include leading spaces as part of a comment block indentation. I suggest instead (untested):
if ($text{0} == "\n") { $text = substr($text, 1); } else if ($text{0} == "\r" && $text{1} == "\n") { $text = substr($text, 2); } $geshi = new GeSHi($text, $lang, "extensions/geshi/geshi");
--Netocrat 22:59, 5 February 2006 (GMT)
OK, I've changed it to that and updated Planning:Wiki_customisation#Syntax_Highlighting.
--Flash Gordon 23:16, 5 February 2006 (GMT)
I've just noticed that the underlining of links wasn't occurring in the original 1.5.4 install. It does occur in my recentish CVS HEAD checkout. I've checked in CVS and found that the revision of skins/monobook/main.css used for the 1.5.4 and 1.5.6 releases is identical (but very different to the file as it exists in my CVS HEAD checkout)... so can you explain why changes were necessary to prevent underlining? One other thing to note is that other skins use different css files - for example the Nostalgia skin still underlines links (although it doesn't include the link image). It's not of that much concern as I doubt that many (if any) people will select a different skin to the default. Also, the comment in the css block in Display improvements is unclosed. --Netocrat 00:43, 6 February 2006 (GMT)
It might be that applying the original change suggested to remove the external link symbol added in the underlining. The change being:
Index: main.css =================================================================== RCS file: /cvsroot/wikipedia/phase3/skins/monobook/main.css,v retrieving revision 1.49.2.1 diff -r1.49.2.1 main.css 576,577c576,580 < special external link styling */ < #bodyContent .plainlinks a { --- > special external link styling; the second rule switches off > external link styling for the geshi C code syntax highlighter > as it makes the code less readable */ > #bodyContent .plainlinks a, > #bodyContent .c a {
This change was reverted when implementing the new version in main.css
I'm not an expert on css (this is my first hack at it) so I don't guarantee what I've done is perfect.
As to other skins, if people want them changed that can make sugesttions, and if they look reasonable I'll hapily apply them. Equally, if someone writes a new skin I've no problem adding it.
I've fixed the Display improvements secton. Obviously just an editing error on the Wiki page.
--Flash Gordon 20:07, 6 February 2006 (GMT)
Link Beautification
I propose beatifying the links for actions like edit, purge etc as I have now done on the test site. This has been done by adding the following to LocalSettings.php:
# Nice URL's for actions $actions = array('edit', 'watch', 'unwatch', 'delete', 'revert', 'rollback', 'protect', 'unprotect', 'info', 'markpatrolled', 'validate', 'render','deletetrackback', 'print', 'dublincore', 'creativecommons','credits','submit','viewsource','history', 'purge'); foreach ($actions as $a) { $wgActionPaths[$a] = "/wiki-cmd/$a/$1"; }
and adding the following to the Apache configuration:
RewriteEngine on
RewriteRule ^/wiki-cmd/([a-z]*)/(.*)$ /mediawiki/index.php?action=$1&title=$2
If I don't see any objections then I will implement this on Sunday since it is a minor and I think non-controversial change.
--Flash Gordon 23:00, 16 February 2006 (GMT)
The edit rewrite breaks the ability to edit a specific section, so if anyone else is watching this and knows about Apache rule rewriting it would help. --Flash Gordon 00:31, 20 February 2006 (GMT)
Allowing Per-user Javascript
I suggest enabling the per-user javascript setting, which allows a user to create a sub-page of their user page named for a specific javascript file which then gets included in headers for general MW page views. I'm prompted to suggest this after seeing that there's then a simple way to override MW's hijacking of Alt-D, which on many browsers focuses the location bar, as a "delete article" access combo. Enabling per-user javascript requires adding this line to LocalSettings.php; the page I read about it on indicates there may be slight performance issues but I doubt it'll be a problem on this wiki - Flash you can test if you're concerned about performance though:
$wgAllowUserJs = true;
There's another setting to enable per-user css ($wgAllowUserCss = true;), but I don't have a need for it at present - others might.
--Netocrat 11:10, 23 February 2006 (GMT)
OK, I've enabled both on the test site. Please give it a test and if it works I'll put it live.
I don't think server performance will ever be a major issue. We would almost certainly hit bandwidth problems and need to go to a more proffesional hosting service first.
--Flash Gordon 12:36, 23 February 2006 (GMT)
- The js works fine for my purposes anyhow - finally free from that alt-D hijacking. Let's put it live. I haven't tested css. Btw, did you receive the email I sent with latest voting ext. code? I ask because I've experienced a few email issues recently. --Netocrat 12:45, 23 February 2006 (GMT)
OK, the change is now live.
I did recieve your email, but I've been rather overloaded with work recently. I'll try to deal with it this weekend.
--Flash Gordon 13:30, 23 February 2006 (GMT)
Hiding spambots from the user listing
The following patch adds support for a global variable $wgHiddenGroups which contains an array of user groups to hide members of from general display on Special:Listusers. They can still be listed by choosing the group from the dropdown. This allows us to hide the (growing) collection of spambots without having to delete them (account deletion is discouraged by MW devs).
Recommended additions to LocalSettings.php (the 'testing' group is so that we can hide the 'Test' account from a general listing too):
$wgGroupPermissions['spambot']['read'] = false; $wgGroupPermissions['spambot']['edit'] = false; $wgGroupPermissions['spambot']['talk'] = false; $wgGroupPermissions['spambot']['move'] = false; $wgGroupPermissions['spambot']['upload'] = false; $wgGroupPermissions['testing'] = array(); $wgHiddenGroups = array('spambot', 'testing');
Patch:
--- SpecialListusers.php 2006-03-22 14:18:29.000000000 +1100 +++ SpecialListusers.new.php 2006-03-22 14:15:39.000000000 +1100 @@ -152,7 +152,7 @@ } function formatResult( $skin, $result ) { - global $wgContLang; + global $wgContLang, $wgHiddenGroups; $userPage = Title::makeTitle( $result->namespace, $result->title ); $name = $skin->makeLinkObj( $userPage, htmlspecialchars( $userPage->getText() ) ); @@ -170,10 +170,16 @@ $dbr->freeResult( $result ); if( count( $groups ) > 0 ) { - $name .= ' (' . - $skin->makeLink( wfMsgForContent( 'administrators' ), - htmlspecialchars( implode( ', ', $groups ) ) ) . - ')'; + if ($this->requestedGroup == '' && + isset($wgHiddenGroups) && + count(array_intersect($wgHiddenGroups, $groups)) > 0) { + $name = ''; + } else { + $name .= ' (' . + $skin->makeLink( wfMsgForContent( 'administrators' ), + htmlspecialchars( implode( ', ', $groups ) ) ) . + ')'; + } } }
This is now implemented on the test site --Flash Gordon 21:29, 29 March 2006 (BST)
Maintainership of GeSHi 1.2 C language support
GeSHi 1.2 - currently in alpha as the 1.1 series - fixes some of the highlighting limitations of the 1.0 series. It didn't yet have a C context so I went ahead and created initial support for C which has just been committed to CVS on sourceforge. GeSHi's author is willing for the author/maintainer of the C language support to be listed as a page on this wiki, and to provide CVS access to members of this wiki who want to co-maintain it, so if there's general agreement, I'll create a page something like Project:GeSHi C maintenance, bug reports_and patches.
A side-benefit is that the links for highlighted keywords, library functions, etc already point to clc-wiki.net articles and we won't need to customise that when we migrate the live site to GeSHi 1.2.
Flash would you be willing to add GeSHi CVS code to the test server? It would require some commenting in the extension harness since not all functionality is supported yet - in particular load-source-code-from-file. --Netocrat 13:00, 29 March 2006 (BST)
I would say adding the page would be a good thing. I've also no problem with using the CVS code on the test site. I was going to do maintenance on it starting this evening anyway since a new version of mediawiki is out. It may take me a little time to work through things since I've got to port the patches forward. --Flash Gordon 20:03, 29 March 2006 (BST)
- Well you're already part-author as I copied the keyword list from the one that you added to the GeSHi version running on the live site. Btw, how did you obtain that list and how complete is it? --Netocrat 01:48, 30 March 2006 (BST)
I've done a vanilla install of the main line GeSHi code in the geshi-src module and hacked the mediawiki GeSHi extension to work with it. I've also forced an immediate update of the test wiki tarball so it is now available with this change. --Flash Gordon 21:53, 29 March 2006 (BST)
- Great; looks like it's working OK although you might want to disable the call to
load_from_file()in the GeSHi extension harness - maybe get the output to read: "Not yet supported" - since it prevents the article page of this talk page from loading on the test site. Also, the CSS changes that you made for underlining need to be modified to useprerather thancode:
#bodyContent pre a:hover { text-decoration: underline; background: none !important; padding: 0; } #bodyContent pre a { text-decoration: none; background: none !important; padding: 0 !important; }
- --Netocrat 01:48, 30 March 2006 (BST)
- Actually replacing GeSHi's load_from_file() isn't all that hard either - here's a patch to "GeSHiHighlight.php":
99,101c99,105 < $geshi = new GeSHi("//nothing", $lang, "extensions/geshi/geshi"); < $geshi->load_from_file($file_name, array($lang => array($lang)) ); < return wfSyntaxDefaults($geshi); --- > if (is_readable($file_name)) { > $text = file_get_contents($file_name); > } else { > $text = "Included source file was not readable...\n"; > $lang = ''; > } > return wfSyntaxCode($lang, $text);
- --Netocrat 05:43, 30 March 2006 (BST)
Removing auto-capitalisation; adding subpage support
As described on Talk:Standard Library, I think it would be useful if these directives were added to LocalSettings.php:
$wgNamespacesWithSubpages[NS_MAIN] = true; $wgCapitalLinks = false;
The first adds the navigation links for subpages to the top of the page for articles in the main namespace. The second prevents auto-capitalisation of the first letter of article titles in page links and through browser redirects when a url is requested. This will break existing links that rely on auto-capitalisation, but if the recapitalisation script is run afterwards any broken links should be fixed up.
- Implemented on both live and test sites. The existing pages will need renaming of course.
At the same time as doing this and amongst the general restructuring subpages will entail, how about adding another alias for apache so that we can directly access articles without the initial "/wiki"? This will compensate for the extra length of the url due to subpage hierarchy. --Netocrat 15:53, 30 March 2006 (BST)
- That will make other content, such as the download of the tarballs more difficult. To allow for that I will have to split out the sub-domain www.clc-wiki.net as a seperate space so I've got space to put such things. Not a major problem, but more than a 5 minute job, so it will have to wait until I've finished the rest of the maintenance on the test site.
