User talk:Bawolff: Difference between revisions

I just saw your Extension:Whitelist Namespaces, works great! Thank you :) Would it be difficult to change it to write-whitelist an entire namespace? on what line in the code do i need to look? Thanks Mauro Bieg 07:57, 29 June 2010 (UTC)Reply

Should be fairly easy, just change the

if ($action == 'read') {

to

if ($action == 'edit') {

Should work (but I have not tested). Bawolff 18:56, 29 June 2010 (UTC)Reply

Thank you for your quick reply! Unfortunately it doesn't work for me, even an if (TRUE) doesn't.. :S so apparently it isn't enough setting that $result to TRUE.. whatever exactly happens afterwards. Mauro Bieg

Thanks for expressing an interest in MediaWiki for Google Summer of Code 2010. Please note (if you haven't already done so) that you must apply and a submit proposal at http://socghop.appspot.com/gsoc/student/apply/google/gsoc2010 by April 9 at the latest or a slot will not be reserved. Thanks! -- RobLa 19:38, 1 April 2010 (UTC)Reply

Thank you for the message. I will do that. Bawolff 19:43, 1 April 2010 (UTC)Reply

Hi, you add a warning to this extension. Can you please explain what the risk means for sites with this extension? I want to know if I shall uninstall it or that I can still use it. Thanks for your answer. 145.94.74.23 15:20, 17 July 2010 (UTC)Reply

Hi. Basically the warning means that someone with knowledge of the insides of that extension would be able to inject html (including javascript) into your page if you have the extension enabled. Someone could potentially exploit this to put a code in the wikipage to make anyone who views that wikipage make edits to some other page for example. Another example is someone could put code into a wikipage that causes everyone who views that page to be redirected to another website. The most recent version of the extension is slightly harder to exploit, but someone familiar with the internals of that extension could still exploit it. See also wikipedia:Cross-site_scripting#Persistent and bugzilla:24199. As a side note, if you're only using the basic features of the extension, you could try using extension:DynamicPageList (Wikimedia) which does not have the above mentioned security issues but has significantly less features. Bawolff 15:50, 17 July 2010 (UTC)Reply

Thanks for the explanation. One more question: Does someone need to log in and be able to edit pages on the site to use this exploit? Or is it something that can be used without any rights? 145.94.74.23 15:20, 18 July 2010 (UTC)Reply

Yes, one would need to be able to edit. Basically the exploit is that someone can use the dpl extension to make part of the page behave as if manual:$wgRawHtml was set to true. Thus, all the warnings that apply to that setting also apply to that extension. If its a private wiki and you trust everyone who has access, you should be fine. Bawolff 21:16, 18 July 2010 (UTC)Reply

Ah, great. That's good to know. Thank you very much for answering the questions. Would it be useful to copy this discussion to the talk page of the mod, or at least link to it? 145.94.74.23 18:24, 20 July 2010 (UTC)Reply

Feel free to if you want. Bawolff 20:14, 20 July 2010 (UTC)Reply

I've just sent an email to two of the maintainers of this extension, so they are aware of this. --Ciencia Al Poder 17:32, 23 July 2010 (UTC)Reply

Cool. Although as a sidenote i think Algorithmix is the only semi-active maintainer of the extension. Bawolff 20:52, 23 July 2010 (UTC)Reply

Maybe you know... would 'RunFromProtectedPagesOnly' setting (from here) be enough to make DPL usage safe? Wassily Steik 07:38, 12 August 2010 (UTC)Reply

Assuming that its implemented correctly, I believe it should (at least for the issue I found. I have not read the entire source code so there could potentially be other things wrong with it, etc so no guarantees, etc) Bawolff 07:49, 12 August 2010 (UTC)Reply

Thanks. Well, at least it makes DPL usable... Of course, I'll check this twice before enabling it. E.g. currently this option allowed DPL on semiprotected pages (I've already fixed this on my copy - in DPLMain.php under 'Initialization' comment). Wassily Steik 08:10, 12 August 2010 (UTC)Reply

I should mention, this of course assumes you trust all your admins :P. Bawolff 08:12, 12 August 2010 (UTC)Reply

Well, I understand this :) Fortunately, on my small project that's not a problem. Wassily Steik 08:25, 12 August 2010 (UTC)Reply

Hello Bawolff, I saw that you are concerned about DPL regarding security (HTML injection). I plan to work on a major new DPL releasse in January 2011. Currently DPL switches silently to allow HTML for internal purpose and switches back once it has finished. A user knowing this might inject HTML code or even Javascript as cou clearly explained. I plan to restructure the code and to avoid such risks (at least in a default configuration setting). Would you be willing to review or maybe give some advice when I start working on the changes? Algorithmix 07:04, 29 October 2010 (UTC)Reply

I am by no means an expert on such issues, but I would of course be willing to review/give advice on any changes. I'm excited to see that you're planning to work on it again, as its quite a popular extension. Bawolff 11:22, 29 October 2010 (UTC)Reply

I'm not at all sure I understood your edit summary here. If you're saying what I think you're saying, I don't really see the difference between an empty table cell and a non-existent table cell, other than the non-existent one looks really ugly. RobinHood70 21:38, 4 November 2010 (UTC)Reply

responded on your talk. Bawolff 22:51, 4 November 2010 (UTC)Reply

Hi, could you please revisit the rev:66913 "javascript for maxlength of the edit summary" (the code is now in mediawiki.action.edit.js) since it does not work correctly in Opera 11.01 (and Opera 10.6)? The problem is, delete and backspace are not recognized as special keys, so user gets stuck with an overfilled summary (only after reading the JS code I realized that cutting the text with a mouse is a possible way out). I could also file this in bugzilla if you want. —AlexSm 18:02, 1 March 2011 (UTC)Reply

Yes of course, I'll look at it right away. Bawolff

Thanks. Fixed in rev:83067. Bawolff 03:59, 2 March 2011 (UTC)Reply

In the article Combating Spam (why does linking not work?) you reverted an edit i made. After testing it with my own wiki, the bannedips.php extension did not work untill i added the trailing ?> , hence i added it in the article. Code arguments aside, a ?> is not needed but adding it doesn't hurt either, hence i added it just to be safe. Besides, it's good code etiquette ;p — Preceding unsigned comment added by Reiisha (talk • contribs)

If you needed the trailing ?>s, you did something wrong. Closing tags are discouraged by our coding standards, please don't re-add. Max Semenik 13:54, 26 March 2011 (UTC)Reply

May have killed it. - Amgine 22:54, 8 June 2011 (UTC)Reply

Well you know - I enjoy pointing out flaws in wikinews techie articles, without actually fixing them my self. Bawolff 04:11, 9 June 2011 (UTC)Reply

<chuckle> Well played... - Amgine 14:41, 9 June 2011 (UTC)Reply

Thanks for giving me a note on that.

I was trying to contribute to the goals of Project:PD help. To allow the help to be used on a fresh wiki installation, it should not use extensions. Many of the templates however depend on extensions. In that particular case on Extension:ParserFunctions. This heavily limits the usefulness when copied to a fresh installation. --Nzara _why_we_wouldn't_want_to_use_those_templates" class="ext-discussiontools-init-timestamplink">11:48, 11 June 2011 (UTC)Reply

Hmm, you have a point, but it seems like a lot of effort to not use such templates. Bawolff 19:52, 11 June 2011 (UTC)Reply

Well, let's cut the effort in pieces and let's start, subst is a great help. However, I'm not clear how to handle Template:PD Help Page and Template:Languages. Here a plain subst appears misleading. --Nzara 10:40, 12 June 2011 (UTC)Reply

If we started including parserfuncs with the default tarball (which seems quite possible), this becomes much less of an issue (To be honest, has anyone ever actually imported the pd-help stuff to their wiki? I don't know of anyone who ever has). I don't just mean its effort to convert the pages to not use the template, its also effort if anyone ever wants to change what those templates look like, or more generally makes the wiki-source more complex to edit. Bawolff 20:44, 13 June 2011 (UTC)Reply

Well, at least I tried to import the pd-help stuff (that created the idea to improve it). Confronting my target users (definitly digtal non-natives) with a naked wiki created some confusion and a usage barrier. --- I agree, not using templates makes it harder to apply a common style. On the other side, with templates and especially with parser functions the source resembles some sort of programming, creating an barrier to non-programmers. These folks perfere WYSIWYG and cut-and-paste.--Nzara 17:10, 16 June 2011 (UTC)Reply

Hi Bawolff.

Do you remember this ?! I made an extension to help to do that. would you mind to check it out. because I am very beginner !
Thank you very much --أحمد ش الشيخ 20:17, 25 June 2011 (UTC)Reply

Hi. Interesting. Ideally I think MediaWiki should support i18n aliases for tag hooks in core, that way it could more cleanly hook into how the parser works. The extension probably wouldn't be enabled on Wikimedia (due to not quite being inline with manual:Coding conventions, and if its decided to support translating tag names, we'd want to put it in the part that deals with tags, instead of running a new regex over the page contents). However, for a non-Wikimedia Wiki, the extension would probably be good. Cheers. Bawolff 21:01, 25 June 2011 (UTC)Reply

Thank you !.--أحمد ش الشيخ 19:33, 1 July 2011 (UTC)Reply

You said here that it is now possible to add a current date function. Yet I have tried it here and I was not successful. Could you assist me with this troublesome problem? -- Phoenix (talk) 09:13, 30 June 2011 (UTC)Reply

The basic idea of how to do this is [1]. You pretty much just have to replace <timeline> with {{#tag:timeline| and </timeline> with }} and any instances of | with {{!}}. You might also have to escape {'s and }'s in your timeline source. Bawolff 18:28, 30 June 2011 (UTC)Reply

WOW! Fascinating. Is there a way for {{CURRENTDAY}} to be shown in a 2 day format? The code breaks down there. -- Phoenix (talk) 08:42, 2 July 2011 (UTC)Reply

I'm not sure what you mean? like have the day be 02 instead of just 2 (that can be done with {{CURRENTDAY2}}). For more complicated date stuff you can do almost anything with {{#date:...}} but the syntax is complicated. [note, I should mention, all this stuff is cached, so the current day won't be updated until next time the page is re-rendered. Normally it probably won't be more than a day off]. Bawolff 23:18, 2 July 2011 (UTC)Reply

YES thanks it had to be in mm/dd/yyyy format and the previous version gave it a mm/d/yyyy result causing it to crash. AMAZING. Thanks. PLEASE can you update the article to reflect this AMAZING addition? -- Phoenix (talk) 08:31, 6 July 2011 (UTC)Reply

Glad to hear that solved it. Which page did you want me to update? Bawolff 14:39, 6 July 2011 (UTC)Reply

Extension:EasyTimeline/syntax Should be updated to include this coding idea :) -- Phoenix (talk) 11:19, 7 July 2011 (UTC)Reply

Hi Bawolff, the contents of the page is not exactly outdated but it was incomplete and still is. The problem is that I cannot offer insights into this and had hoped that an expert may do it somehow "on the fly". Please do not take offence for having inserted the label. Cheers --[[kgh]] 09:21, 9 December 2011 (UTC)Reply

Hi Bawolff, I just answered on my talk page. Cheers --[[kgh]] 16:49, 9 December 2011 (UTC)Reply

Oops, there was some kind of edit conflict. I guess I am ready editing the page. Please have a look at it. Thank you and cheers --[[kgh]] 17:13, 9 December 2011 (UTC)Reply

Hi, I received your fixes through User:MarkAHershberger, thank you!--GrafZahl (talk) 13:50, 17 December 2011 (UTC)Reply

At the support desk, you noted that 'movestable' is required to move pages with stable revisions, however, that right appears to belong to all autoconfirmed users, so I'm confused as to why User:Igottheconch wasn't able to move the page. This is probably just a brain cramp on my end but if you could clarify this for me I'd appreciate it - is a bugzilla needed. I agree with you that this shouldn't be so hard for people to move.

Additionally, do you understand why the links provided by the e-mail notifications of changes to pages don't work for this? The e-mail notice gave me this link: http://www.mediawiki.org/w/index.php?title=Project:Support_desk&offset=20111229074439&lqt_mustshow=10213#moving_pages_10213 which doesn't even show the required thread. Is this a problem with LQT or with the e-mail notification system? Does this need a bugzilla? Thanks for your help.--Doug.^{(talk • contribs)} 14:59, 29 December 2011 (UTC)Reply

Whoops, it looks like I totally misread the page listing all the rights. Thanks for catching that. As for email notification, that does look like a bugzilla type bug. Bawolff 00:40, 30 December 2011 (UTC)Reply

Thanks for fixing the code in Manual:$wgTitle. I saw a glimmer of hope in the Title.php file, but it turned out to be false.. thanks again. --Gbruin 05:20, 7 January 2012 (UTC)Reply

Thank you for your interest in the MediaWiki Workshop, Preparing extensions for MediaWiki 1.19!

As a friendly reminder, the workshop is being held being held in about 12 hours - 13 January, 2012 at 19:00 UTC - in IRC (#wikimedia-dev).

This workshop will be an opportunity to share information about changes in MediaWiki 1.19 that may require revisions to extensions or skins. Also an opportunity for developers to ask questions regarding extension development.

Look forward to seeing you in IRC.  :) --Varnent 06:18, 13 January 2012 (UTC)Reply

Thank you for documenting how to move away from $wgArticle. I have it working now on my wiki! -- Tbleher 09:59, 12 February 2012 (UTC)Reply

As you can see from my contribs to this wiki, I have a lot of changes that are still pending. However, my first request was declined a while back.Jasper Deng 05:08, 14 February 2012 (UTC)Reply

File a new request at Project:Requests and request the Editor right again, The only reason the last one got closed (by myself) is that a question left unanswered for over a month. Peachey88 06:18, 14 February 2012 (UTC)Reply

Hhm, how would I handle the fact that I already made a request? I need help.Jasper Deng 06:33, 14 February 2012 (UTC)Reply

A new subpage, eg: Project:Requests/User_rights/Jasper_Deng (2). Peachey88 06:46, 14 February 2012 (UTC)Reply

Done; you think my rationale is sufficient?Jasper Deng 06:51, 14 February 2012 (UTC)Reply

that seems as good a reason for review rights as any. Bawolff 16:16, 14 February 2012 (UTC)Reply

I was going to revert my change this morning. Thanks for fixing it. My problem was using the help from mysql which reads:

 -p, --password[=name]
                     Password to use when connecting to server. If password is
                     not given it's asked from the tty.

I am still trying to get that extension to work... Schalice (talk) 17:00, 3 March 2012 (UTC)Reply

No worries, the mysql help on that is quite confusing. Cheers. Bawolff (talk) 19:21, 3 March 2012 (UTC)Reply

I'm not a developer, but I'm pretty active on this wiki.Jasper Deng (talk) 04:28, 21 March 2012 (UTC)Reply

Project:Requests is where you are looking for. Peachey88 (talk) 05:36, 21 March 2012 (UTC)Reply

I mean, do I stand a chance of passing that?Jasper Deng (talk) 05:45, 21 March 2012 (UTC)Reply

You have the same as every one else, But I should also point out, we are trying to limit giving out sysop these days to people that can show why they want/need it compared to "I want sysop". Peachey88 (talk) 05:54, 21 March 2012 (UTC)Reply

OK, my situation is that uncontroversial things like those speedy deletions I just did are made much easier, not to mention the creation of talk page archives. The ability to edit some certain protected pages with minor corrections is also something I'd like to be able to do.Jasper Deng (talk) 05:56, 21 March 2012 (UTC)Reply

You helped me with a hint to check other skins. However, nobody could help to solve the problem of the watchlist error yet. Could you have a look at this again or forward the question to someone who could help? Thanks a lot in advance, --ThT (talk) 15:19, 26 March 2012 (UTC)Reply

XExternalEditor Java program does not show preview suddenly and stops working to upload. It was working fine few days back. Please help --Yjenith (talk) 16:45, 26 March 2012 (UTC)Reply

You'll have to ask the maintainers of that piece of software. I know a little bit of MediaWiki's external editor support, but

XExternalEditor is a third party program I've never used and am not familiar with. Bawolff (talk) 13:18, 27 March 2012 (UTC)Reply

OK. I have asked support in Sourceforge's project page. --Yjenith (talk) 02:25, 29 March 2012 (UTC)Reply

Bug 20326 deals with removing EXIF data from images. My duplicate bug detailed why that is important. Some use cases require compulsory removal of all EXIF data, as a matter of safety for the uploaders. The quantity of images I need to deal with is not huge, and even when it is huge, the rate of incoming new data should be low enough to accommodate a simple workaround, at least until a better solution is available.

My proposed workaround is to manually remove EXIF data from all images locally, and then update MediaWiki image data using /maintenance/rebuildImages.php. That file dates back to 2009 - Before I break something, can you tell me if I can expect rebuildImages.php to work as promised, after I've stripped EXIF data?

Badon (talk) 23:10, 28 March 2012 (UTC)Reply

I'd recommend using refreshImageMetadata.php --force --quiet. I'm not 100% sure off the top of my head, but I think rebuildImages.php will only rebuild images that look broken in the MediaWiki db, so it won't catch your metadata changes (and then the sha1 would get out of sync, and that'd be bad as well). refreshImageMetadata.php --force --quiet will definitely refresh the metadata of all the images (and update the sha1) [I suppose it probably wouldn't update the archivedfiles and oldimages table. Note that info, including metadata can be gotten from both those tables from the api. archivedfiles is not so much of an issue as you need to be an admin, but info from oldimages can be read by anybody who knows the rather obscure api command needed] Bawolff (talk) 00:05, 29 March 2012 (UTC)Reply

Manual:Oldimage table says it only exists as a consequence of overwriting files. I've disabled file overwrites, so that should circumvent that data leak. Manual:deleteArchivedFiles.php seems to be the way to get rid of the problem altogether, if needed. Manual:$wgHashedUploadDirectory is something I'm concerned about, when set to true. If removing EXIF data changes the hash, does MediaWiki move the file? The docs say MD5 is use, but you mentioned SHA1 - are the docs outdated for that? Badon (talk) 01:36, 29 March 2012 (UTC)Reply

There's 2 different hashes mediawiki uses. The md5 one is the hash of the file name (not the contents). It won't change unless you re-name the file (It is used for the hashed directory thing). The sha1 hash is stored in the db, and is a hash of the actual file (used for finding duplicate files and some other stuff). It will change when you modify the file. However, its only stored in the db, and the maintenance script should update it when it updates the img_metadata field (?action=purge also updates the sha1 hash too).

Allowcachedresults=yes+warn is not working, no message is display, I've created a topic here, could you please help me?? - 186.218.184.219 22:17, 18 June 2012 (UTC)Reply

I'm not the maintainer of that extension, but if I know anything about your issue I'll post it to that page. Bawolff (talk) 12:00, 19 June 2012 (UTC)Reply

	The Civility Barnstar
	Thanks forthe job you're doing on the support desk. I really appreciated it! Joshua123 (talk) 11:58, 27 June 2012 (UTC)Reply

Thanks for the barnstar. Bawolff (talk) 12:03, 27 June 2012 (UTC)Reply

Did you read my reply?--Luca Ghio (talk) 15:20, 8 July 2012 (UTC)Reply

Are you at Wikimania? —Emufarmers^(T|C) 06:51, 14 July 2012 (UTC)Reply

Alas no. Maybe some other year. Bawolff (talk) 12:15, 16 July 2012 (UTC)Reply

Responded to your comment on my talk page.

She's just tried to deprecate 1.0 in favour of 2.0, which is fair enough. The template doesn't quite read properly, but it does the trick. Jarry1250 (talk) 15:47, 16 August 2012 (UTC)Reply

Yeah, it should be the canonical page, but it isn't yet :) Jarry1250 (talk) 16:48, 16 August 2012 (UTC)Reply