Wikitech-l January 2011

wikitech-l@lists.wikimedia.org

94 participants
75 discussions

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12

Hi everyone, I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent. I would prefer a script written in Python, but any recommendations would be very welcome. Do you know of anything suitable? Kind Regards, Hugo Vincent, Bluewater Systems.

6 13

NNTP access for Wikimedia mailing lists
by River Tarnell 08 Feb '11

08 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've set up an NNTP gateway for Wikimedia mailing lists. The "wikimedia.*" hierarchy is available via news.tcx.org.uk. More information: <http://news.tcx.org.uk/wikimedia.html>. Unlike GMane, this gateway does not rename lists (all lists are wikimedia.<list name>), and does not munge email addresses inside posts, which breaks PGP signatures. However, posting via NNTP is not currently possible. (I expect to fix this in a few days.) Only a few lists are available right now, but if people find it useful, I will add the rest of them (at least those with public archives). - river. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk1HLeEACgkQIXd7fCuc5vJFWwCeJvcsA+RSvgF8IXkRxxlk1q2r t0oAn1ei8J9VqHfb/EUy7h1o8VWehE4r =omjK -----END PGP SIGNATURE-----

4 20

Sentence-level editing / InlineEditor extension update
by Jan Paul Posma 04 Feb '11

04 Feb '11

Hey all, I've been working on the InlineEditor extension again, primarily working on a new interface that doesn't use the different edit modes anymore, as the usability testing showed that this was not the right approach. Luckily, without a change in the underlying algorithms, it was doable to combine all the edit modes into one interface. This also resulted in the deletion of tens of files plus hundreds of lines of code [1], which usually is a good thing, because it shows it's a simpler and more natural approach. If you're interested in testing this on your own wiki or looking at the code, grab your copy from SVN. [2] If you're interested in testing this, a wiki has been set up here: http://janpaulposma.nl/sle/wiki As you might know, some more usability testing will be done soon by GRNET [3], so we can see if this interface works better or not. Feel free to ask questions and throw in suggestions, etc. Best regards, Jan Paul [1] http://www.mediawiki.org/w/index.php?path=%2Ftrunk%2Fextensions%2FInlineEdi… [2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/InlineEditor/ [3] https://code.grnet.gr/projects/wikipedia-wysiwyg/wiki

8 15

Farewell JSMin, Hello JavaScriptDistiller!
by Trevor Parscal 01 Feb '11

01 Feb '11

For those of you who didn't see bug 26791, our use of JSMin has been found to conflict with our GPL license. After assessing other options ( https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I decided to try and use the minification from JavaScriptPacker, but not its overly clever but generally useless packing techniques. The result is a minifier that outperforms our current minifier in both how quickly it can minify data and how small the minified output is. JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript code at about 2x the speed of Tim's optimized version of JSMin, and 4x the speed of the next fastest PHP port of JSMin (which is generally considered the standard distribution). Similar to Tim's modified version of JSMin, we chose to retain vertical whitespace by default. However we chose not to retain multiple consecutive empty new lines, which are primarily seen where a large comment block has been removed. We feel there is merit to the argument that appx. 1% bloat is a reasonable price to pay for making it easier to read production code, since leaving each statement on a line by itself improves readability and users will be more likely to be able to report problems that are actionable. We do not however find the preservation of line numbers of any value, since in production mode most requests are for many modules which are concatenated, making line numbers for most of the code useless anyways. This is a breakdown based on "ext.vector.simpleSearch" * 3217 bytes (1300 compressed) * 2178 bytes (944) after running it through the version of JSMin that was in our repository. Tim modified JSMin to be faster and preserve line numbers by leaving behind all vertical whitespace. * 2160 bytes (938 compressed) after running it through JavaScriptDistiller, which applies aggressive horizontal minification plus collapsing multiple consecutive new lines into a single new line. * 2077 bytes (923 compressed) after running it through JavaScriptDistiller with the vertical space option set to true, which applies aggressive horizontal minification as well as some basic vertical minification. This option is activated through $wgResourceLoaderMinifyJSVerticalSpace, which is false by default. The code was committed in r80656. - Trevor (and Roan)

18 31

Parser postprocessor
by Daniel Friesen 31 Jan '11

31 Jan '11

An interesting idea just popped into my head, as a combination of my explorations through the dom preprocessor and my attempt at deferring editsection replacement till after parsing is done so that skins can modify the markup used in an editsection link in a skin-specific way without breaking things, and so that we can stop fragmenting the parser cache by user language just for edit section links. A postprocessor. It would be quite interesting if instead of html we started outputting something like this in our parser output: <root><html><p>foo</p><h2></html><editsection page="Foo" section="1">bar</editsection><html>bar</h2><p>baz</p><h2></html><choose><option><html><p>foo</p></html></option><option><html><p>bar</p></html></option><option><html><p>baz</p></html></option></choose></root> ((don't get scarred off by all the entities, this is nothing new, try looking at a preprocess-xml cache entry)) Course this is a Postprocessor_DOM oriented look, like Preprocessor_Hash we'd have a Postprocessor_Hash and it would store a different format like we already do with Preprocessor_Hash (serialized?). The idea being the creation of new markers that aren't 100% parsed but are outputted in a easy to deserialize format and finish parsing with minimal work and extensions can output and have a postprocessor hook expand later on. In essence the idea here is two fold. Firstly things like the <editsection page="Foo" section="1">bar</editsection> I tried to introduce now is no longer a hack. And we can try to start deferring minimal processing cost things which fragment the parser cache if they aren't needed. Ideally in the future if something like {{int:asdf}} isn't used in a [[]] or in a parser function and is just a base level bit of display isolated from the rest of the WikiText we might be able to output it in a way that we don't have to fragment the cache by user lang but can still output the message in the user's lang by deferring it. And as a big extra bonus, think of the RandomSelection extension. Right now extensions like RandomSelection end up disabling the entire parser cache for a page, just so they can output a random one of a series of options. With a postprocessor they could instead craft partially parsed output where all the normal wikitext is still parsed, but all the options given in the source text are outputted and the postprocessor handles the actual random selection on each page view, only outputting one of the three html nodes. Likewise we might be able to implement "Welcome {{USERNAME}}!" without fragmenting the cache by user or having to disable it. The key being that we get things as variable as complete randomness, at the level of re-executing that randomness on each page view, yet have barely any more processing to do than we did before. (like the rest of the ui that isn't part of the page content) -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

5 4

Inclusion request for the Validator extension
by Jeroen De Dauw 31 Jan '11

31 Jan '11

Hey, Over the past year I've been working on an extension to facilitate parameter handling in MediaWiki, with a focus on parser hooks. It's titled Validator [0], which currently is a bit misleading since it enables a lot more then simple validation. As the only thing this extension does is facilitate parameter handling in other extensions, I think it makes sense to include it into core, or at least in the default MediaWiki distribution. I created this extension out of frustration as an extension developer that to create a parser hook, you need to do the same plumbing over and over again, and have to write a whole mess of parsing and validation code that is similar for almost every parser hook. Of course this is doable, but it's error prone, causes small differences in how exactly parameters are handled in different parser hooks (not very nice for the end users), and is hard to maintain. If you have done this a few times, it becomes rather obvious that a more generic framework to handle parameters would be a big win. You want to describe a parameter, not all the details of how it should be handled. Using Validator is somewhat similar to how API classes and their getParameters methods work, but more powerful and extendible. A parser hook can be created by deriving from the ParserHook class added by Validator, and implementing or overriding some methods to specify the name, aliases (if any), parameters (and all their meta data) and actual handling function of the parser hook. This last method gets called with a list of all parameters handled by Validator, and in most cases won't need any extra work. This ParserHook class is just a wrapper around creating parser functions and tag extensions and using the actual validation class of validator. You can directly handle parameters using the Validator class. A nice example of ParserHook usage can be found in the SubPageList extension [1]. The Maps and Semantic Maps extensions also use Validator, and contain more complex examples (with parameters dependent on others, ect) that implement the display_map and display_points parser hooks [2]. Putting this functionality in core would be a big help to everyone writing new parameter handling code, and would enable cleaning up existing implementations where this is desired. As this functionality does not replace anything in core, putting it in would not disrupt anything. I'm willing to do the little work required to merge Validator into core. I could just do that right now of course, but I'm quite sure some people would object to that. So can these people please respond to this email in some constructive manner, so this request does not simply get ignored for no good reason? [0] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:Validator [1] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:SubPageList [2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Maps/includes/pa… Cheers -- Jeroen De Dauw http://blog.bn2vs.com Don't panic. Don't be evil. --

6 21

Deprecating content_actions
by Daniel Friesen 31 Jan '11

31 Jan '11

Right now in the skins system (if you consider vector part of the skins system) we have two parallel methods of adding tabs to the page: - Into content_actions via SkinTemplateTabs, SkinTemplateBuildContentActionUrlsAfterSpecialPage, and SkinTemplateContentActions, - Into vector's navigation_urls via SkinTemplateNavigation (the missing two hooks should be added) The only important difference between these (besides some vector specific stuff that can stay in vector) is that content_actions is a flat array, and navigation_urls is an array of arrays organized into categories. Besides that, they are basically mirrors of each other with the same functional purpose, but you need to add tabs to both of them to avoid something not showing up in vector. There's also the misfortune that other skins can't take advantage of the organized navigation_urls because the actual implementation (which is basically a reimplementation of buildContentActionUrls with code duplication) without being a vector subskin because the code in question is inside of vector. Right now we have extensions using both methods of adding tabs to the page, code duplication on their part. And a few extensions that are broken in vector because they haven't added the hooks. Doing a quick grep, it appears the following extensions are missing vector support: Oversight, CommentPages, Todo, WikiTrust, Tasks, CategoryTree, DeleteQueue, Wikidata, Imagetabs, purgetab, Tab0, AuthorProtect, TidyTab, Purge, SpecialTalk Shouldn't be to hard to fix, especially if we fix the bug of missing hooks for navigation_urls. Now onto my focal point. As I've been improving the skin system trying to pull out the thorns that make building skins troublesome and mesh in new features and helpers which are missing, I'd like to remove the content_actions hooks and deprecate content_actions in 1.18 and start using navigation_urls style data everywhere. Since content_actions and navigation_urls are the same, content_actions can be built by having SkinTemplate take the navigation_urls data and flatten it into a single array. Similarly to how I already have $wgFooterIcons work and fold it for some skins like Monobook which don't organize it the way vector does. The effects will be like this: - The three content_actions related hooks will no longer work in 1.18, thus extensions that haven't started supporting vector tabs will also stop showing tabs in other skins - In their place extensions will use 3 navigation_urls related hooks (most extensions are already using the one hook available) - Extension code for those already using both forms of hooks will stay the same, the only difference being that 1.18 will use the navigation_urls related hooks and the content_actions related ones will become redundant code which the extensions can keep for back compat but drop once they stop supporting pre-1.18 installations - All standard skins will be using navigation_url based data and content_actions will be available but deprecated - 3rd party skins will still function using content_actions but it would be preferred for them to be updated to use the new BaseTemplate and use the helpers in there (a navigation_urls related one would be added) once they don't need to support pre-1.18 - SkinTemplatePreventOtherActiveTabs will probably still work, though I may want to find a cleaner method to transition to (ie: one that says "this is the active tab" rather than "don't make other tabs active"). Any comments, rejections? -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

7 18

Wikipedia behaves differently in Firefox 4 Beta 10
by Amir E. Aharoni 31 Jan '11

31 Jan '11

A little bug i reported to Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=629878 This happens in Wikipedia and Wordpress, but not in GMail, so it may interest MediaWiki developers. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com "We're living in pieces, I want to live in peace." - T. Moore

2 1

Re sourceLoader + Windows + PHP bug 47689
by Aaron Schulz 31 Jan '11

31 Jan '11

In JavaScriptDistiller, inside of the createParser() function, we have: $parser->add( '/\\/\\*(.|[\\r\\n])*?\\*\\//' ); It took me hours to track down that this was causing Apache 2.1.11 to crash on nearly any page view on my test wiki. This happened when a large JS bundle is loaded, such as: load.php?debug=false&lang=en&modules=jquery.checkboxShiftClick|jquery.client|jquery.cookie|jquery.makeCollapsible|jquery.placeholder|mediawiki.action.watch.ajax|mediawiki.language|mediawiki.legacy.ajax|mediawiki.legacy.diff|mediawiki.legacy.mwsuggest|mediawiki.legacy.wikibits|mediawiki.util&skin=vector&version=20110129T005517Z I made a simple php file to reproduce this. It crashes when viewed over apache but not CLI. It appears to be http://bugs.php.net/bug.php?id=47689 (which uses a similar regex). Is something worth adding a note somewhere about or tweaking some code? -- View this message in context: http://old.nabble.com/ResourceLoader-%2B-Windows-%2B-PHP-bug-47689-tp307922… Sent from the Wikipedia Developers mailing list archive at Nabble.com.

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l January 2011