||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!
Hello. I'm sending this to you, because you've been one of the top 50 users of LQT on mediawiki.org over the last 360 days, and I wanted to make sure that you'd seen the announcement at Starting conversion of LiquidThreads to Flow at mediawiki.org. There are links in the topic-summary at the top, for other discussions (wikitech-l and Project:Current_issues), and a link to the planned process and timeline (scheduled to begin April 6, with smaller conversions at first). Please do test Flow out at Talk:Sandbox if you haven't tried it recently, and give any feedback/suggestions/requests at that main discussion location. Much thanks.
Thank you Quiddity for notifying me about this. Much appreciated. Wow, I would not have guessed that I ended up in third place in this. Obviously I very much like LQT but I am also happy about the prospect of having a new way of talking about things. I already added infos about two of the three issues I currently have with Flow.
You reverted my addition of Extension:Cumulus to this category. Am I using that category wrong?
No, basically you did not. However my follow up edit to the revert not only provides an informative info box but also the mentioned category via transclusion.
In September 2013, you removed one of my wikis, NSindex, because it "should not be publicised according to the webmaster". It was actually true back then because it was unfinished, but since then it is now workable because it has its own domain name. How do I make it publicisable now, while keeping out the bad robots (e.g. SEO)? Thanks in advance. :-)
Well, never seen a finished wiki yet. Perhaps this one will be the first but I doubt it. An own domain is a good starting point though. To my experience it takes a some time to get visible in the internet. Good content is the best one can do. To additionally help this you will probably like to have a look at this category (you will need to dig into meta tags for this) if you want to improve things on wiki. This setting $wgAllowMicrodataAttributes (you will need to dig into microdata for this) may be of interest too as well as this script GenerateSitemap.php (then you can register your sitemap e.g. with Google. A good robots.txt is a must too though the bad thing about bad bots is that they do not care about this. :( Still it's worth the effort for good bots. I wish you the best of success. Cheers
Hi, can you review the changes in the page Extension:Math? Thanks.
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!