User talk:Bawolff

Extension: write-whitelist namespace
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)
 * 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)
 * Thank you for your quick reply! Unfortunately it doesn't work for me, even an  doesn't.. :S so apparently it isn't enough setting that $result to TRUE.. whatever exactly happens afterwards. Mauro Bieg

Google Summer of Code 2010
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)
 * Thank you for the message. I will do that. Bawolff 19:43, 1 April 2010 (UTC)

Extension:DynamicPageList_(third-party)
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)
 * 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 Cross-site_scripting and 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)
 * 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)
 * 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)
 * 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)
 * Feel free to if you want. Bawolff 20:14, 20 July 2010 (UTC)


 * 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)
 * Cool. Although as a sidenote i think Algorithmix is the only semi-active maintainer of the extension. Bawolff 20:52, 23 July 2010 (UTC)

Maybe you know... would 'RunFromProtectedPagesOnly' setting (from here) be enough to make DPL usage safe? Wassily Steik 07:38, 12 August 2010 (UTC)
 * 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)
 * 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)
 * I should mention, this of course assumes you trust all your admins :P. Bawolff 08:12, 12 August 2010 (UTC)
 * Well, I understand this :) Fortunately, on my small project that's not a problem. Wassily Steik 08:25, 12 August 2010 (UTC)

DPL issues?
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)
 * 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)

Huh?
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)
 * responded on your talk. Bawolff 22:51, 4 November 2010 (UTC)

"javascript for maxlength of the edit summary" in Opera
Hi, could you please revisit the 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)
 * Yes of course, I'll look at it right away. Bawolff
 * Thanks. Fixed in 83067. Bawolff 03:59, 2 March 2011 (UTC)

Combating Spam
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
 * 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)

pedanticism!
May have killed it. - Amgine 22:54, 8 June 2011 (UTC)
 * 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)
 * Well played... - Amgine 14:41, 9 June 2011 (UTC)

Help:Formatting -> why we wouldn't want to use those templates
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 11:48, 11 June 2011 (UTC)
 * 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)


 * 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)
 * 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)


 * 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)

About Arabic XML tags.

 * 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)
 * 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)