MediaWiki-l September 2011

mediawiki-l@lists.wikimedia.org

53 participants
48 discussions

Image caching on File: pages... any workaround?
by Daniel Barrett 07 Sep '11

07 Sep '11

The most frequent problem on our wiki (MediaWiki 1.17.0) involves re-uploads of images, where users are fooled by browser caching: 1. A user uploads a modified version of an existing image (File:Foobar.jpg) 2. After the upload, user views File:Foobar.jpg but the old image is still showing. 3. User tries uploading 10 more times. The old image is still showing. 4. User calls tech support, who says, "press ctrl-F5 to refresh your browser." 5. User presses ctrl-F5 and the new image shows up. Obviously the problem is due to browser caching. Is there any way for the MediaWiki software to prevent this problem from happening and show only uncached images on File:Foobar.jpg? The average user doesn't know anything about browser caching. (We already added a note to the Upload page that explains the problem. People don't notice the note - their attention is focused on uploading their image.) Thanks, DanB

3 3

Question about internal links
by juliana tchoua 06 Sep '11

06 Sep '11

Hi everybody i want change color of internal links only not links which appear in toolbox and navigation. I add the parameter a.internal{color:orange;} but it doesnt give the result attented. Please someone ca help me? Thx in advance.

5 6

Reversing "Add HTML Meta and Title" extension
by Kenneth Barry 05 Sep '11

05 Sep '11

We have "Add HTML Meta and Title" extension installed. ( http://www.mediawiki.org/wiki/Extension:Add_HTML_Meta_and_Title). We can easily "ADD" tags, but we don't see a method for removing them, or even modifying them. I don't even know where the information we add is being kept (Though i am sure its probably in the database, i have looked, and fear it might be kept in the "BLOB" blocks, and i have no idea how to vew/modify those fields, or if i would even want to. Someone mind looking at this extension and helping me understand where the data is kept, or how to remove/modify what the extension does to a page? What is completely confusing is that the Extension lets you use the Page Editor (i don't know the proper name) where the content of the page is created to add, using some special formatting. But once you save, the text you enter disappears, so you can't change it.

1 0

Tag Extensions Multiple??
by Mike Cody 02 Sep '11

02 Sep '11

Hello, I am have a problem embedding more than one tag extensions in any given post on my wiki. wiki version 1.16 Both tag extensions work fine by them selves but when ever I add the second one it causes errors or I just get a white page. I am using <servers/> and <contact/> to embed the extensions. I am guessing that when I add the second extension I am causing some type of problem with a global variable or some kind of name space issue. I have included all the code for the two extensions. any help would make my day! Thanks! ###ContactTag.php### <?php $wgHooks['ParserFirstCallInit'][] = 'ContactTag::setup'; $wgAutoloadClasses['ConatctTag'] = dirname( __FILE__ ) . "/ContactTag_body.php"; ###ContactTag_body.php### <?php // Create hello tag for the Wiki class HelloTag { const NAME = 'contact'; static function setup() { // The entry point. Associates the tag with a function. global $wgParser; $wgParser->setHook(self::NAME, array('ContactTag', 'render')); return true; } static function render() { //required for DB connection require "db_mysql.inc";// defined in /etc/php.ini path: /usr/lib/php/include/ require "define_hosts.php"; // defined in /etc/php.ini path: /usr/lib/php/include/ // Connection Parameters $em7_g3 = new DB_MySQL; $em7_g3->Host = $em7_host; $em7_g3->User = $em7_user; $em7_g3->Password = $em7_pw; $em7_g3->Database = "biz"; $em7_g3->connect(); $ris = new DB_MySQL; $ris->Host = $storm_host; $ris->Database = "sugarcrm"; $ris->User = $storm_user; $ris->Password = $storm_pw; $ris->connect(); //Get end of URL remove _ from client name for DB query $endURL = $_GET["title"]; $phrase = $endURL; $healthy = array("_"); $yummy = array(" "); $newphrase = str_replace($healthy, $yummy, $phrase); //Run DB query and run though loop to get DB client data if ($newphrase) { $q = "Select v.first_name, v.last_name, f.email_address from contacts AS v Left join accounts_contacts AS s ON v.id = s.contact_id Left join accounts AS a ON a.id = s.account_id Left join email_addr_bean_rel AS e ON v.id = e.bean_id Left join email_addresses AS f ON f.id = e.email_address_id where a.name ='$newphrase'"; $ris->query($q); $acnt = ""; $table ="<table border='4'>"; while ($ris->next_record()) { $company = $ris->f("first_name"); $device = $ris->f("last_name"); $active = $ris->f("email_address"); //$ip = $ris->f("ip"); $acnt = $acnt + 1; if ($company) { if ($acnt){ $addr_list[$acnt] = "<tr><td>$company</td><td>$device</td><td>$active</td><td>$ip</td></tr>"; $string = $string.$addr_list[$acnt]; } } } $tableEnd="</table>"; return $table.$string.$tableEnd; } } } ###ServerTag.php### <?php # Credits $wgExtensionCredits['other'][] = array( 'name' => 'ServerTag', 'description' => 'Print All Servers Based On Client Page Name.', 'version' => '1.0'); # Set up the hook, using different logic depending # on the version of MediaWiki if (defined('MW_SUPPORTS_PARSERFIRSTCALLINIT')) { $wgHooks['ParserFirstCallInit'][] = 'ServerTag::setup'; } else { $wgExtensionFunctions[] = 'ServerTag::setup'; } # Autoload the implementation class $wgAutoloadClasses['ServerTag'] = dirname( __FILE__ ) . "/ServerTag_body.php"; ###ServerTag_body.php### <?php class ServerTag { const NAME = 'servers'; static function setup() { global $wgParser; $wgParser->setHook(self::NAME, array('ServerTag', 'render')); return true; } static function render() { //required for DB connection require "db_mysql.inc"; require "define_hosts.php"; // Connection Parameters $em7_g3 = new DB_MySQL; $em7_g3->Host = $em7_g3_host; $em7_g3->User = $em7_g3_user; $em7_g3->Password = $em7_g3_pw; $em7_g3->Database = "master_biz"; $em7_g3->connect(); //Get end of URL remove _ from client name for DB query $endURL = $_GET["title"]; $phrase = $endURL; $healthy = array("_"); $yummy = array(" "); $newphrase = str_replace($healthy, $yummy, $phrase); //Run DB query and run though loop to get DB client data if ($newphrase) { $q = "SELECT company, device,master_dev.legend_device.active, master_dev.device_ip_addr.ip from master_biz.`organizations` left join master_dev.legend_device on master_biz.`organizations`.roa_id = master_dev.legend_device.roa_id left join master_dev.device_ip_addr on master_dev.legend_device.id = master_dev.device_ip_addr.did where company = '$newphrase'"; $em7_g3->query($q); $acnt = ""; $table ="<table border='4'>"; while ($em7_g3->next_record()) { $company = $em7_g3->f("company"); $device = $em7_g3->f("device"); $active = $em7_g3->f("active"); $ip = $em7_g3->f("ip"); $acnt = $acnt + 1; if ($company) { if ($acnt){ $addr_list[$acnt] = "<tr><td>$company</td><td>$device</td><td>$active</td><td>$ip</td></tr>"; $string = $string.$addr_list[$acnt]; } } } $tableEnd="</table>"; return $table.$string.$tableEnd; } } } Mike Cody Systems Administrator RELIAM (310) 348-9700 x 2 ( Support ) (310) 348-9797 FAX ---- Blog: http://www.reliam.com/news/reliam_blog Twitter: http://www.twitter.com/reliam Facebook: http://www.facebook.com/reliam ----

2 1

Skin system new features, changes (1.18): Autoloading, Legacy skins, RequestContext, Relevant Users and Titles, Login/createaccount links, content_navigation, BaseTemplate, and more... (+1.19 preview)
by Daniel Friesen 02 Sep '11

02 Sep '11

The format of $wgValidSkinNames has been changed. Previously it had been `$wgValidSkinNames[key] = name;` but now it's `$wgValidSkinNames[key] = ClassNamePostfix;` In essence the code that creates a skin class has now been changed to try to create a class named "Skin{$wgValidSkinNames[$key]}". This change is because of a bug with skins that are autoloaded. Previously when you defined a skin like `$wgValidSkinNames["bluebook"] = "BlueBook";` MW would try to load SkinBluebook rather than SkinBlueBook. This worked in core because we didn't autoload skins and instead did a `require_once( "{$wgStyleDirectory}/{$wgValidSkinNames[$key]}.php" );`, because php's class system is case-insensitive SkinMonoBook always loaded fine, however this wasn't the case for extension based skins which used our case-sensitive autoloader. Keep this in mind when making autoloaded skins if you want pre-1.18 compatibility you may have to add two autoloader lines, one for SkinBlueBook and another for SkinBluebook. Legacy skins are depreciated. The old skin system inside 'Skin' that powered the old skins CologneBlue, Nostalgia, and Standard/Classic has been dropped and replaced by a deprecated SkinLegacy system based mostly on SkinTemplate. New skins should all be SkinTemplate based, SkinLegacy only exists to support the 3 core skins that were ported, it may be eliminated from core in the near future along with the legacy skins. Note that this means a lot of methods like Skin::editThisPage() that were never meant to be used by SkinTemplate are no longer available, if you used $sk-> methods check over your skin to make sure it's not throwing errors because you were using outdated methods. We now have a context system, if building a skin for 1.18+ please ensure that you use ->getUser(), ->getLang(), ->getRequest(), and ->getOutput(), instead of $wgUser, $wgLang, $wgRequest, and $wgOut. The linker is now static, skins wishing to use linker methods should migrate away from calling them on $sk-> and use Linker:: properly. Note that doEditSectionLink is now explicitly part of Skin, it's no longer a Linker method, if you're using it take note of that. As a result of this and some parser changes skins can now customize the editsection link within their own skin by overloading the doEditSectionLink method. Note that if you did this before 1.18 you would pollute the cache and end up with other skins having your customizations sometimes, and your skin losing it's customization sometime. Make note of that if you override doeEditSectionLink as you may want to include a conditional to leave it alone if your skin is used in a release before 1.18. We have two new pieces of information for skin, a relevant title and relevant user. Relevant title is used when doing things like generating tabs, special pages like Special:Movepage use it to make skins display the tabs for pages they are relevant to instead of making them suddenly disappear on the user (1.19 or later may have a more robust way of handling tabs though). Relevant user is similar, pages like Special:Contributions use it so things like the block link in the toolbar are the same as when visiting a userpage. The specialpageattributes key is no longer needed in your skin if it's meant for 1.18+, there's better code in core now handling lang/dir for the body. The printfooter and debughtml have been pulled out of bodytext and are now in separate printfooter and debughtml keys (I think I need to make not of that in my own skins). ((I have some issues with this change (not mine), the situation may change a little before release if I try to backport something)) The "Login / create account" link can now be split into two separate "Login" and "Create account" links by user configuration using $wgUseCombinedLoginLink. For now it defaults to the same behavior as before. Skins which have a reason to need one behavior or another (eg: turning the links into buttons and wanting to make sure they're both there) can override the useCombinedLoginLink method and return either true (combined) or false (split) to override the configuration. A great one now. Sort of replacing content_actions we have a new content_navigation tplkey. The Vector code generating it's own hierarchical content_actions has been pulled out of vector and merged into SkinTemplate, any skin that wants to take advantage of the better organized namespace/variants/views/actions categorization of our tabs can now use content_navigation to take advantage of them. Skins using content_actions will still work, the content_actions array is created based on content_navigation now, the content_navigation arrays are annotated with information like 'primary' (vector uses this to stop collapsing of tabs into the menu on small screens) and 'redundant' for tabs like 'read' which tells the content_actions code that the tab is redundant and shouldn't be included in content_actions. Extensions which used SkinTemplateTabs and didn't add a SkinTemplateNavigation hook will stop working as the SkinTemplateNavigation hook has completely replaced SkinTemplateTabs (ok, I admit I think there's an old SkinLegacy hack that still uses SkinTemplateTabs for the tabs in legacy code). Extensions that had issues with vector's code not including replacements for the SkinTemplateBuildContentActionUrlsAfterSpecialPage and SkinTemplateContentActions hooks will be happy to know that content_actions now has equivalent replacement hooks SkinTemplateNavigation::SpecialPage and SkinTemplateNavigation::Universal which you can add. If you use these hooks in new code, and don't need pre-1.18-non-vector compat, and aren't worrying about SkinLegacy still using a SkinTemplateTabs hack you don't need to include the old hooks since content_actions is extracted from content_navigation. There is new message fallback code in the i18n system. Many of the messages for tabs like 'move' can be overridden per-skin with messages like 'vector-action-move', 'modern-action-move', etc... If not defined they will fallback to the normal message. Vector had some message customizations before because of changes from monobook in how it handled tabs so this was added so we'd have a way to keep those without doing it in an ugly hacky way. Other skins can now include similar customizations and individual wiki can include per-skin message overrides if there are things like the edit button you want to customize the message for but have an issue where it looks fine in one skin but messes up the intuitiveness of another. Skin QuickTemplates now have a $this->getSkin() method they can use instead of fumbling around with $this->data['skin']. We have a new BaseTemplate class that extends QuickTemplate, it includes a number of helpers for skins and you can start to take advantage of them in a 1.18 skin by extending from BaseTemplate instead of directly from QuickTemplate. This can kill a lot of ugly boilerplate from skins like the huge boilerplate for personal_urls and content_{actions,navigation}. Links and list items for many of the common tpl key arrays we have (ie: content_{actions,navigation}, etc...) where there are arrays like personal_urls that aren't in a format these helpers can handle we have helpers like getPersonalTools that will give you an array in the right format. The search input and search button have helpers to simplify them too (I couldn't come up with a good helper for the search form opening code though). You can replace the mess of bottomscripts, reporttime, and debug trail in your skin now with a simple `$this->printTrail();`. And those remembering my footerlinks and footericons code just introduced in 1.17 will be happy to know there are helpers here to simplify the boilerplate for those. Also that horrible ugly massive boilerplate for the toolbox you have to copy into any skin, we now have a getToolbox helper that returns an array that will work with the mageListItem helper, it also has a new hook BaseTemplateToolbox that will work on that rather than have you output raw html not customized by skin. So please do start using it in skins, it would be nice to deprecate those html hooks and have extensions stop using them. ---- 1.19 is in active development so there isn't much added yet, but I do have a nice quick note on what is in there now. Vector contains a pile of css for content styling which was basically copied from Monobook and modified slightly. That css has now been stripped out and put into three stylesheets in common/: commonElements.css: This stylesheet contains all your basic elements; Paragraphs, Links, Headers, etc... If you want anything from the common styles you'll want this at least. commonContent.css: This stylesheet contains more complex things which are contained within the content area, right now it contains things like the TOC and the frames that are wrapped around images. These are things you might not want default styles for in your skin and might want to customize in ways that having pre-existing styles could get in the way of (it's easier to override simple styles by commonElements than it is do undo the styling of the entire toc for example). commonInterface.css: This stylesheet contains some extra common stuff between MonoBook and Vector. These are tied to patterns in ids and classes for things like the usermessage, catlinks, etc... which are outside of the bodytext and the skin may decide on the ids and classes for. If you're making a skin that sticks with the MonoBook/Vector patterns of laying out and id/classing the content area you can include this stylesheet to get some of the common styles. There are a few notes on opting-in to this in your skins: - I haven't figured out how to deal with the icons for external links (the https, audio, etc... icons) yet, MonoBook and Vector use different icons so while the pattern is common the images aren't. So they aren't actually the same stylesheet wise. This may end up as a separate to include stylesheet later on. - When opting in you'll need to add a class="mw-body" somewhere into your skin to define the area where content css stylings for things like links will apply. In MonoBook this is on the same element as #bodyContent and in Vector it's #content. - To use these stylesheets include them into your ResourceLoader 'styles' array, that way it all gets combined into a single css file for your skin. -- I didn't make this a separate module because we include &skin=skinname into the /load.php call, that means that even if I make these modules they aren't reused between different skins. Hence there is no value in having them in a separate module and it's better to include them in the skin's own module where they'll be combined into a single css file. - With link styles and one or two minor changes from MonoBook to Vector the Vector difference was preferred since Vector has replaced MonoBook, MonoBook is now essentially outdated, and new skins will likely be Vector based rather than MonoBook based. If you want things to look a little more old and monobook like you may want to add some overriding css in your own styles like the rules that monobook adds in it's own css for links. - MonoBook and Vector use different bullet images for ul {}, since they're embedded images and would end up inlined in skins that might override them I opted out of including them in the elements stylesheet. If you want a list bullet image you'll have to embed one into your own stylesheet. We have an old .gif that looks like the one in MonoBook inside common, but the Vector one right now is only in vector. Though I may contemplate moving that to common. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

1 0

Skin system new features (1.17): Footer links, Footer icons, just a few helper methods
by Daniel Friesen 02 Sep '11

02 Sep '11

MediaWiki 1.17 contains some new features for skin authors, most of my skin system reform was backed out for later releases so it's only some small stuff for now: I'm not going to go over the ResourceLoader here since I didn't author it. But do make note of it, skins should update themselves and take advantage of the resource loader. If you ever thought that your skin's css file was far too big this is now your chance to split it up into as many cleanly separated stylesheets and have the resource loader combine them all into a single stylesheet automatically so you can get the organized code while keeping your skin nice and fast. Also make note to use @embed rules and @noflip. You don't need a separate rtl stylesheet anymore (though do test your skin in rtl environments so you know what rules you need to @noflip). You don't need to depend on css sprites anymore since images are embedded into stylesheets with @embed. However do try to avoid using multiple @embed's for the same image, if you use the same url() in multiple places in your css try to consolidate them all into a single combined css rule. Otherwise when you use @embed you'll be unnecessarily bloating your css since they're now inline and not combined into one by the browser's cache. Footer links: Previously the list of links in the footer was hardcoded into individual skins, there's now a new array managed by the skin template. Skin authors can now use $this->data['footerlinks'] and it's sub-arrays, the way to output the links is generally the same values in the footericons sub-arrays are tpl keys. Extensions can now tweak the list of footerlinks by registering a SkinTemplateOutputPageBeforeExec hook, modifying the one of the footerlinks sub-arrays in it by adding a new key, and setting a new key of the same name on the $tpl. One of these days the footericons may be replaced with a better system that'll actually be customizable by system message config, but for now for compatibility reasons this is what we've got. Footer icons: The previous copyrightico and poweredbyico keys are now depreciated in favor of a new footericons setup. The icons are accessible by $this->data['footericons'] which is populated from $wgFooterIcons, with some extra guarantees like if "src" is set a width and height will always be set so you don't need to test for them. There is a Skin::makeFooterIcon method skins can use to simplify the creation of the actual footer icons/text, actually I recommend that every skin makes use of this method with the same kind of boilerplate used by monobook/vector (for icons) or modern (for text). Users can now use $wgFooterIcons to customize the icons in the footer. Kill off the copyright icon, powered by, add an icon to wiki you host in a wiki farm, add icons for someone responsible for managing your wiki, etc... Extensions that want to customize this can look at how it's done in SMW. However do so very sparingly, ONLY if you're a really big extension like SMW that your users won't mind an icon showing up for (or of course if your extension's only purpose is to customize that, eg: an extension that creates a ui to let sysops add icons to the footer). If I see extensions start to abuse this and bloat the footer with vanity icons I'll personally go into svn and delete the icons from each extension. Skin and Extensions authors and users can check the $wgFooterIcons documentation for info. Skins also have access to Skin::getCommonStylePath and Skin::getSkinStylePath. These are helper methods you can use if you have a need to include the url for a skin or common resource within your skin itself. Mostly if you're doing something like inserting an image using an actual <img> rather than a background-image. Skins can override a new addToBodyAttributes method if there are any attributes or css classes not in the built-in headelement <body> tag that they want to be there. By the way if you haven't already, please do start using the headelement introduced in 1.16. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

1 0

Office Documents fix!
by McHale, Nina 02 Sep '11

02 Sep '11

Hi, all, I wrote earlier this week about the issue we were having with uploading and downloading Office docs to the wiki (it was zipping .docx, .xlsx, and .pptx files on upload and therefore not able to open them on Windows machines on download). I'm happy to report that simply upgrading to 1.17 appears to have resolved the issue! It's mentioned in the release notes, http://www.mediawiki.org/wiki/Release_notes/1.17, under "Bug Fixes for 1.17," https://bugzilla.wikimedia.org/show_bug.cgi?id=23688. Thanks to everyone who responded to my repeated pleas for help on this issue! Nina Nina McHale, MA/MSLS Assistant Professor, Web Librarian University of Colorado Denver, Auraria Library Facebook & Twitter: ninermac http://milehighbrarian.net<http://milehighbrarian.net/>

1 0

uploading broken
by André Meunier 01 Sep '11

01 Sep '11

Hello, I've tried to upload a file today, and got an error message saying the extension of the file doesn't correspond to the mime type. It was still working 3 weeks ago, and I didn't make any change to the wiki. Version is 1.16.0. I checked the Localsettings file and it's still ok. Any idea where this could come from? Thanks -- *André Meunier* Documentaliste et responsable IT Bibliothèque des Sciences de la Vie Téléphone : 04 366 2173 http://www.libnet.ulg.ac.be/mede/

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l September 2011