||exdi | kghblngit | fab | Core: Git Diffusion | Extensions: Gerrit / Git / GitHub / SVN | Wikia WikiaWiki | WikiHow | OD | Misc: grok.se - NSA
My Highest contribution rank on this wiki: #3 on 2014-08-31
Some stroopwafels for you!
|Thank you for help and encouragement on various MW.org tweaks. :) Varnent 20:26, 16 December 2011 (UTC)|
A barnstar for you!
|The Tireless Contributor Barnstar|
|For your truly awesome work on many wikis, in particular the Semantic MediaWiki one :) Jeroen De Dauw (talk) 15:02, 18 March 2012 (UTC)|
A beer for you!
|Thank you for your help though the program does confuse me quite a bit I appreciate you kindness in helping me if only you participated in adopting people then I would want you as a mentor have a beer in my kind offering to you. Kiki-kk (talk) 21:26, 16 July 2012 (UTC)|
A kitten for you!
Thank you for cool edit on Extension:SpecialDeleteOldRevisions2 ! It is late and my head is of... It's good that you are on guard!
|Thread title||Replies||Last modified|
|Review request Extension:Math||4||16:51, 12 January 2015|
|Extension:ConfirmEdit||3||19:45, 6 October 2014|
|Extension:ConfirmEdit||1||18:31, 6 October 2014|
|No aliases||3||08:09, 3 October 2014|
|If you get a second||6||21:10, 29 June 2014|
|A barnstar for you!||1||16:16, 23 June 2014|
|Thanks||6||16:07, 16 June 2014|
|Manual:Pre-commit checklist||1||06:54, 7 May 2014|
|Struggling to add the entire core to Git for the MediaInclu fork||3||08:28, 5 May 2014|
|User Mediass4u||3||12:59, 11 April 2014|
|Vandalism||1||16:31, 18 March 2014|
|Display Languages Sidebar (Interwiki)||1||16:53, 17 March 2014|
|iSC Dev BP Wiki - problem: picture||2||15:27, 13 March 2014|
|Extension:MobileFrontend||2||16:55, 27 February 2014|
|Thank you for your help with Extension:Surl||1||14:42, 15 February 2014|
|Help to resolve dispute please||3||12:34, 1 February 2014|
|Comments extension||1||09:37, 10 January 2014|
|Template:Extension||1||18:00, 9 January 2014|
|Extension:ROT13||10||11:06, 29 December 2013|
|Composer on Wikipedia||3||21:09, 28 November 2013|
Hi there. I reverted your edit as the edit summary led me to believe it was vandalism. Given that you are just reverting everyone else, it's hard to understand why you made the edit in question. Maybe a more thought out edit summary would be appropriate? Thanks,
I am trying to reinstate the reverts of Nemo bis which I believe are vandal edits.
Asirra is unsupported so I removed the documentation about how to install Asirra for ConfirmEdit. Nemo bis believes that this is vandalism as long as the dead code is still in the repo. I fail to subscribe to this. Instead of using the talk page he reverted twice. So this seems to be best practice now.
Yeah, I'm running into the same problem you describe here with my older extensions too (and the new ones I'm creating with code borrowed from those). I guess when the solution is found, we can add it to Manual:Error messages.
Heiya, actually I found the solution to it. Since I was able to fix it I assume it is a easy one. :) The issue is that the extension defines a special page but does not provide a php-file containing the localised aliases for it. So this is basically a I18n issue. I think that I e-mailed a fix to Nad, however he has not moved it into the code afaik. Currently I am not home, so next week earliest I will be able to show how this may be avoided. Stay tuned... Cheers
Sorry to ask, I know I keep putting on you, but I don't have anyone else to ask :(
Have just create a new contact form extension that runs through a specialpage, is still in the developement process at the moment so excuse the look, still a few bits to tidy up as yet. The reason I ask if you can have a look is that I'm concerned there might be a security isue with it? Not sure how mediawiki works in that respect or hackers for that matter, you'll find the page here.
no worries and you should not be sorry for asking. As much as I would like to help you with this one: I simply cannot since I am not a developer and basically have not clue what PHP is all about. Even small changes I try to do usually end up in disaster. :( I just take the position of an sysadmin here.
Probably the best is to ask for you own WMF repo (see here) and invite other developers for a review of the code you submitted. Usually you get great responses and heaps of tipps.
|The Editor's Barnstar|
|Many thanks always appreciate your help and speedy revisions :) SwiftSys (talk) 16:08, 23 June 2014 (UTC)|
Last edit: 16:07, 16 June 2014
Thank you for modifying my extension page, was a bit unsure how to add the content as this is my first extension, looks much better now :)
(talk) 06:43, 1 May 2014 (UTC)
Your welcome! Well, it is not easy to know about this when starting out on this wiki. Apart from that: It's a wiki, so you cannot do anything wrong. :) It is great that you are sharing your extension with others. Cheers
thank you for kind words and support :)
Sorry for asking but I was wondering, the extension has been downloaded a few times, but users aren't commenting, so I can't be certain if there are any problems. How long should I wait until making the extension stable? Or does someone else decide that?
there are no problems with your questions. :) It is entirely up to you to assess if the extension is e.g. beta or stable. If you believe that it is up to its job and you received no error reports, then you may very well change the status. Usually one only gets feedback in case of problems, so hearing nothing it a good thing. :)
Special:Diff/997083: Wait, why? I just checked my copy of mediawiki/core and there is no file or folder called "maintenance/languages/messages.inc". There is only /core/languages which has the MessagesEn.php/MessagesQqq.php files or maintenance/language/messages.inc.
Hey Karsten, I've been trying to add the latest development version of the entire MediaWiki core to Git for the MediaInclu fork. However, it doesn't want to add the entire thing. I clone MediaWiki, then clone MediaInclu, then recursively copy the MediaWiki
core folder into MediaInclu, then do
git add ., or
git add --all, or
git add *, and then
git commit --all, and it only commits the empty
core folder. I tried changing directory to
core, and got:
nathan@nathan-Inspiron-518:~/MediaInclu/core$ git add . git: pathspec.c:317: prefix_pathspec: Assertion `item->nowildcard_len <= item->len && item->prefix <= item->len' failed. Aborted (core dumped)
Google wasn't a very good friend to me when I asked him about that error message; he pretty much blew me off without giving me a very helpful answer. Then again, sometimes it's best for a friend to honestly say "I don't know" if that's the truth. What do you think is going on? Thanks.
Heiya Nathan, well I am not really an expert on Git frankly written a novice. By what you are writing I think that Git is not able to identify the changes you made just by copying new files over old ones. Perhaps it is better to run an patch from MediaInclu over the cloned MediaWiki rather than recursively copying over the whole lot. However, this is just a guess. Apart from that I am stuck at a "I do not know" either. :( Cheers
Actually, I hadn't even tried to commit any changes to the codebase; I was still stuck on the initial step of trying to commit the original codebase (see Hack_MediaWiki_core#Methods). But I got it now; I needed to get rid of .git and the other hidden files (.gitignore, etc.)
Heiya, well this user is not quite ready for editing I guess. If is is as bad as on this wiki. Yeah, let the admins decide on this. Cheers
Have you ever dealt with people whose interest was not just to spam but to vandalize? I've decided, maybe the best thing is to just put in place a really annoying CAPTCHA like Asirra that everyone has to deal with for every edit, till I manually put them in the Editor group. I used to only require the CAPTCHA for edits that add external links, but the vandals don't care about that; they're fine with just deleting or adding a bunch of text. Plus of course it's important to deprive all but trusted users of the reupload right, I found out the hard way. I'm working on blocking the open proxies too, although I have mixed feelings about that because I think some good users, especially of controversial wikis whose content borders on illegal, use proxies to avoid government surveillance.
I might create some sort of automated mass revert tool; I started work on it but it's hard to stay motivated. If you have other ideas, you can put them at countervandalism development. Thanks.
Yes, vandalism is quite common and it is very time consuming to clean up the mess vandals made. So tools to speed up and improve this process should be very welcome by site and wiki administrators.
I also think that requireing CAPTCHAs all the time until a user has been put into a trusworthy group is the best approach. This is what I ususally recommend doing. It is not as dismissive as the ConfirmAccount and surely the reason why this extension is not spreading.
You are right about proxy blocking, so in cases of valid proxies a whitelist may be the better approach.
I have commented and brainstormed on the countervandalism talk page.
I have a problem with showing pictures in my new wiki: iSC Dev BP Wiki. It is looking like this.
Ouch, never had this before. That's strange since there seems to be read and write access to the "image" directory but not to the subdirectory "thumb". It is a problem with the read and write access anyway. Perhaps $wgThumbnailScriptPath is a way out. You could always give it a shot at Manual:Errors and symptoms and the support desk.
It's our 1st extension and we don't know how to add it correctly! Edlira is installing and configuring GIT now so we can add a link to it. We might have a few more questions! The extensions helps a lot to run WikiTranslate, so someone else might benefit from it too!
No problem at all. Nobody is an expert from start. An easier way might be to use GitHub like many more projects here. This would also allow for easier code changes by others. I will have a look at the extensions page in a couple of days and do some edits if necessary. Great wiki by the way. :) Cheers
Please could you help resolve a dispute at Manual:Upgrading? I've included the path to the logo image that people change on their own Mediawiki installs. After unpacking the tar ball they will need to replace the image file again. An anonymous editor keeps removing this info, saying "Is already in the linked page. You should not change stuff inside the folders that come with the tarball. Changes will be reverted by an upgrade making things unnecessarily complicated. Advising to do". Even after I made a separate section Manual:Upgrading#Other_files about what to do after extracting the tarball.
Heiya Rob, well I have had this page on the sighting list a couple of times recently. I did not dig into this deeper though. Admittedly I do tend to opt for the IP, however I can also live with the path being shown on Manual:Upgrading, too. Actually this particular sentence should be rephrased a bit. Cheers
This edit on the Comments extension page changed the included file from "comment.php" to "comments.php" in the installation instructions. The name of the file in the extension actually is "comment.php".
Truth is, the name of that file should probably be changed to "comments.php" to comply with convention, in a way that maintains backward compatibility. What do you think?
Ouch, this was indeed a bad change I made. The naming of the file is however a bit unexpected since it appears that comments is used in nearly all the other context of the extension. I am guessing that this is an old inheritance from the early days of this extension which was never changed along the way. Changing from "Comment.php" to "Comments.php" is a good idea but not imperative. Perhaps "Comment.php" could just include a call like
include 'Comments.php';. Still I will revert this change to make the page correspond with reality again. Thanks for the pointer!
Don't worry, it seems to take everyone (including me) at least a dozen or half-dozen attempts to get that template to do what they want. I was about to say, "blame it on the people who didn't install Extension:TemplateSandbox" and then I saw that it is installed. Hmm, is that tool useful for this type of situation? Unfortunately, it looks like a lot of work to operate; I think I would be tempted to just edit the live template. We have test.wikipedia.org; where's test.mediawiki.org when we need it?!
Still, I don't like the feeling of being under time pressure once I start editing those high-usage templates and something goes awry. I feel like I need to fix it really quickly to get it working again, but I'm in such a hurry that I find myself frantically saving one edit after another, trying to make it work but merely breaking it in a slightly different way each time. A sense of desperation begins to mount. I don't want to revert it completely back, though, because that would not only admit temporary defeat but also add yet another edit to the history. Yet I end up making a bunch of edits anyway.
Heiya Nathan, thank you for the cheer up. Yeah, actually I only had a couple of minutes to do it yesterday and then I got lost while counting brackets. And then this happens it gets even worse with me. I know myself quite well. Not longer a situation in which you can do productive work. Besides, this template it just a dino that grew over time. It will be nice if this wiki goes semantic but that's another story.
I totally forgot about the TemplatSandbox extension. I never used it though I wanted to. Still have to learn the mechanics here but it should be worth a try instead of wildly going berserk.
So, I committed Extension:ROT13 to GitHub. It wasn't so bad. As mentioned earlier, I went in expecting some serious punishment; however, I came away feeling as though I'd been only mildly disciplined by a moderately-skilled and halfhearted dominatrix. It left me unsatiated and yearning for more. Therefore, I'm going to work on what is apparently one of the less-documented areas of the MediaWiki codebase, external storage! Surely I will come away from that experience bruised and whimpering, brutally chastized but having secretly and perversely loved every moment of it. If it were otherwise, I would have spoken the safeword (or safe phrase), "I'm switching to a different open-source project."
I knew I wouldn't be too bad and I am happy that it did not mistreat you too much. :) Yeah, there are unfortunately a lot of only thinly documented areas. Nice that you want to tackle it!
As it turned out, I was able to use Revision::newFromArchiveRow(), ContentHandler::getContentText(), and Revision::getContent() to avoid needing to write my own code for handling external storage. I was shuddering at the thought of needing to set up my own external storage system for testing; but fortunately the programming was already done by others and I needed only make use of it. Whew, that was a close one! (It's always unpleasant to find out you just unnecessarily reinvented the wheel with an inferior design to what was already out there. That's basically what happened with Extension:EmailDeletedPages.)
By the way, you definitely deserve that Tireless Contributor Barnstar. Thanks for cleaning up some of those extension pages; I'm learning to just copy and paste some of your work into new extension pages. The only problem is, now that the new stuff will be in Github, how will you internationalize? Hmm...
Lucky you this time. To reinvent the wheel is a tedious task one should really avoid. Sometimes it still happens but this should really be an exception. Probably asking in IRC is a good shot for finding out certain information in a lot of instances. I find the people out there pretty helpful.
Before I forget: Thanks for the compliment. It is always good it people value one's work. :)
Someone just pointed out to me that there is no article on Composer on Wikipedia. Given that SMW and whatnot will soon be using it as standard installation mechanism, it'd be cool if someone could write that. Hint hint :D
Yeah, it's missing somehow. Did you think of someone specific to do this? :D Well I do not see problems on enwiki, but on dewiki composer will not have any chance, I guess.