Talk:How to become a MediaWiki hacker

Archives:
 * 2002–2010

SELinux :(
Just a note that we need to put somewhere more useful sometime: SELinux makes it difficult to install MediaWiki, and so "do you have SELinux installed?" is a useful question to ask if someone's having a very hard time installing MediaWiki. Sumanah 08:03, 20 November 2011 (UTC)
 * This looks like a topic that should be included in a FAQ section of Manual:Installing MediaWiki or Manual:Errors and Symptoms. Actually, it's already at Manual:Errors and Symptoms. guillom 18:39, 12 January 2012 (UTC)

Good basic HTML & JavaScript tutorials/resources

 * Crockford's JavaScript videos
 * basic HTML & CSS tutorials
 * Google's HTML/CSS/JS videos

Good examples of code to learn from
I talked with Aaron Schulz today and he mentioned that he'd prefer new developers only look at good code when seeking examples to admire and copy.
 * Message.php (well-structured, uses chaining)
 * FileBackend (less great, but good)

Testing
We also need more testers/debuggers. There are very few test wikis (basically only translatewiki.net serves as such!) and the beta cluster is unused. See Project:Test reports. Nemo 09:46, 12 July 2012 (UTC)

Thanks will look into them for sure, Johnsonleecameron (talk) 09:44, 4 July 2016 (UTC)

On learning PHP
Some recommendations I've heard:

One of the classics is the "Luke and Laura" book http://www.amazon.com/PHP-MySQL-Development-Luke-Welling/dp/0672317842 by Laura Thomson & WMF's Luke Welling. It's huge, pricey, but accessible and thorough. If you are a beginner, try one of the O'Reilly learning books, "Learning PHP" or "Learning PHP & MySQL". There's also zend's dev site, with some good articles: http://devzone.zend.com/

There is also a Head First book (from O'Reilly press) about PHP & MySQL.

Lastly, this includes resources and a free quiz: http://www.w3schools.com/php/default.asp Sharihareswara (WMF) (talk) 13:24, 10 February 2013 (UTC)
 * Please do not promote W3Schools; they are perhaps the worst place in the world to learn PHP, as they provide tutorials and example code with significant security vulnerabilities, among many other issues. See, e.g., this example. Note that W3Schools is not affiliated with the W3C, it is a Norwegian company dedicated mostly to selling "certificates" of dubious veracity.
 * The official PHP manual is located here, and the current MySQL APIs are PDO (generally preferred, as it also supports other DBs) and MySQLi. Beware any tutorials or books that still promote the deprecated  functions; these are very old (PHP 2.0, released around 1998 or so), and don't support modern features like parameterized statements, thus many have the same security flaws as W3Schools.--CoJaBo (talk) 16:17, 26 May 2013 (UTC)

MediaWiki-Vagrant
Should we just link directly to MediaWiki-Vagrant, rather than the first three at How to become a MediaWiki hacker? If not that, we may at least want to make a separate Manual:Installing a development environment. A good guide to installing a dev wiki and a good guide to installing a prod wiki would be pretty different. Superm401 - Talk 20:27, 29 October 2013 (UTC)

There are some strange &lt;translate> tags visible.
I think there are some strange &lt;translate> tags visible which start near the "Documention" sub-section until "Appendix" section. Is it normal ? Manta Ray DeeJay (talk) 21:52, 3 June 2016 (UTC)
 * As the page uses, I wonder if https://www.mediawiki.org/w/index.php?title=Annoying_little_bugs&type=revision&diff=2145491&oldid=2145419 triggered this? Could you try reverting and check? --AKlapper (WMF) (talk) 10:57, 7 June 2016 (UTC)
 * In order to transclude the /en subpage to get rid of these tags, Annoying little bugs needs to be marked for translation first. Are you going to do that? --AKlapper (WMF) (talk) 11:16, 7 June 2016 (UTC)
 * I'm not sure all understand what you mean. "Annoying little bugs" is a page that I would like begin to translate. But I don't have admin privileges to do that. Nemo has helped me by leaving some informations on my talk page. But I don't know how to contact a page translation administrator. what is the relationship with "Annoying little bugs" page and the &lt;translate> tags in this page ? Manta Ray DeeJay (talk) 15:41, 13 June 2016 (UTC)
 * ✅ by marking Annoying little bugs for translation and adding #ifexist: Special:Diff/2162778 --Shirayuki (talk) 22:49, 13 June 2016 (UTC)
 * Thanks for your help guys. I think there is a mistake, a translate tag  is below a section instead above (please see  ). The problem is that there is not only the   which is not translatable but also all the following  ) although their associate translate tag is well placed (above). Is it a bug ? Could you correct it ? Manta Ray DeeJay (talk) 21:49, 14 June 2016 (UTC)
 * Should Pywikibot be translatable? See https://www.mediawiki.org/w/index.php?title=Special:Translations&message=Translations%3AManual%3APywikibot%2FPage_display_title --Shirayuki (talk) 10:41, 14 June 2016 (UTC)

Promoting the Wikimedia Developer Support forum
I have been following the edit discussion between and  about adding a link to https://discourse-mediawiki.wmflabs.org/

A proposal:


 * If you have general questions which are not tied to the specific task that you want to work on, use generic channels like Wikimedia Developer Support,  or ml>Special:MyLanguage/Mailing lists|mailing lists but not the specific task.

If you want to avoid increasing the number of links, what about removing this bullet point that again sends newcomers to a page with plenty of more vague links:


 * Learn more at Communication.

--Qgil-WMF (talk) 17:48, 16 January 2018 (UTC)
 * Yeah, that sounds like a good idea to me when it comes to not losing new contributors on their way to go through a jungle of pages linking to each other. --AKlapper (WMF) (talk) 18:12, 16 January 2018 (UTC)
 * I'd more comfortable with it if we disabled password-based authentication first. (That would also disable the sending of invites, but oh well.) Promoting something so prominently and then expecting that everyone notice the warning about not reusing passwords is not reasonable, IMO. --Tgr (talk) 07:02, 21 January 2018 (UTC)
 * that warning is there because asked for it. I believe it responds to good practices, not to a security flaw in the pilot setup? We have HTTPS in place and local passwords are encrypted. So far the pilot is being useful to the developers asking questions in it, which is the main point this pilot has to prove. Is this warning really a reason not to announce pilot in more places? --Qgil-WMF (talk) 10:58, 22 January 2018 (UTC)

Shared directory performance issues?
@Func86 The article says: "You may also experience shared directory performance issues if you are using VirtualBox."

And you stated: "For me, it's very slow on Virtual Box, maybe can work better on VMware, but that's not the default option."

VirtualBox is the only documented way to run MediaWiki-Vagrant at MediaWiki-Vagrant. Using VMware is not documented. I don't think we should confuse users by inferring that there are faster ways to run MediaWiki-Vagrant when there are no other documented ways to do so other than VirtualBox. Lectrician1 (talk) 16:10, 28 December 2022 (UTC)


 * @Lectrician1 Then I am curious about how Vagrant can run faster for you. Are you not using NTFS? It would cost me more than half a minute to open a single page, just struggling to read php files from the shared directory.
 * Reference: https://mitchellh.com/writing/comparing-filesystem-performance-in-virtual-machines, https://github.com/docker/for-win/issues/10476, https://github.com/microsoft/WSL/issues/4197
 * And I think you at least should not remove the fact that docker's config file comes with the MediaWiki repository. Func86 (talk) 17:50, 28 December 2022 (UTC)
 * @Func86
 * "Then I am curious about how Vagrant can run faster for you."


 * Than Docker? If Docker than I don't know why. Page loads for me on Docker take 90-120 seconds. On Vagrant they only take me 10 seconds. I installed Docker Desktop and followed the instructions in DEVELOPERS.md and that is what I got.
 * "Are you not using NTFS?"


 * In Docker? If in Docker I don't know.
 * "It would cost me more than half a minute to open a single page, just struggling to read php files from the shared directory."


 * In Vagrant?
 * "And I think you at least should not remove the fact that docker's config file comes with the MediaWiki repository."


 * When you go to MediaWiki-Docker it says for you to go to DEVELOPERS.md. I don't think it being part of the MediaWiki repository is critical to what platform users choose to run MediaWiki with. Lectrician1 (talk) 18:19, 28 December 2022 (UTC)
 * @Lectrician1 Ok, I see your edits history on MediaWiki-Vagrant's page, you are using some optimizations, but still take 10s. You should try Docker with Hyper-V backend, you will love it. But unfortunately, docker/Hyper-V and vagrant/virtualbox are incompatible with each other, and WSL2 is the default engine of docker desktop. My suggestion is, recommand docker with Hyper-V backend for devs who don't need WSL2 or virtualbox. You said no recommendations on the article, then I only post here. Func86 (talk) 18:41, 28 December 2022 (UTC)
 * @Func86 Could you submit a change then to DEVELOPERS.md explaining that Windows users should use Hyper-V? That's currently not described. Lectrician1 (talk) 19:50, 28 December 2022 (UTC)

"recommended code editors"?
@Lectrician1: do you have citations for the section you added which recommends two particular code editors? You seem to have added quite a bit of highly opinionated content there. -- BDavis (WMF) (talk) 19:17, 21 February 2023 (UTC)


 * @BDavis (WMF) I just listed them as "recommended" since those two are likely the most-used by the community and have the best documentation here on Mediawiki.org. I was thinking about not including the "recommended" part in the first place, but than I was like, "why should we have beginners question what they're doing". Feel free to add other editors you'd recommend or reword it. It's fine with me. Lectrician1 (talk) 21:57, 21 February 2023 (UTC)
 * I agree that "why should we have beginners question what they're doing" is a good concept to actively consider while writing tutorial/how to content. I'm hung up on the entire "Open a code editor" section providing unsourced opinion which also implies that there is some kind of special consideration for two particular editors and that one is "better" than the other in some sense.
 * Any text editor that can deal with unix newlines and UTF-8 encoding is perfectly fine for MediaWiki development. I use vim. I know of people who use emacs, Notepad++, Atom, PhpStorm, and VSCode to do their development work. I actually think that the whole section should go in the spirit of not complicating the set of things that a new contributor has to deal with. -- BDavis (WMF) (talk) 23:17, 21 February 2023 (UTC)
 * @BDavis (WMF)
 * "I'm hung up on the entire "Open a code editor" section providing unsourced opinion which also implies that there is some kind of special consideration for two particular editors and that one is "better" than the other in some sense."


 * Yeah, it is opinionated, but for good reason (read below). And yes, one is better than the other (read below).
 * "Any text editor that can deal with unix newlines and UTF-8 encoding is perfectly fine for MediaWiki development."


 * Features I find critical code editors should have are intellisense, object reference navigation, and navigating between subclasses and superclasses. Some parts of MediaWiki and extensions are extremely object-oriented and it is critical that you can quickly find and move between superclasses and subclasses. Editors like emacs, Notepad++, and Vim do not come with these features out-of-the-box and require installing plugins. Maybe NeoVim might be packaged with them, but using it requires knowing vi, something which some beginners might not know, or know well.
 * If we don't recommend any code editors for users to use, users might end up using something like Notepad++ and not have a plugin for intellisense. If I were that contributor, I'd be pissed to learn that I was wasting time looking at documentation, fixing failed tests, and browsing the repository, and could have instead been using PhpStorm which has that feature and a 1000 others out-of-the-box requiring no configuration.
 * In fact, a similar situation happened to me when I started coding in MediaWiki. I was originally only using VSCode, however, my friend (who doesn't even develop MediaWiki) strongly recommended using PhpStorm as it has a lot more features out-of-the-box. I was really happy after they recommended it as after I tried it out I realized it was a much better experience. Some favorite features of mine in PhpStorm are the ability to easily navigate between inherited and parent classes as well as the ability to connect to a MySQL database so you can see how your database is changing in real time. I couldn't imagine working without them.
 * For these reasons, I think it's important that we recommend editors with strong features so that editors are aware what's available and why they should use them. We could even include the features I mentioned above that these code editors uniquely provide as substantiation for these recommendations. Lectrician1 (talk) 21:52, 22 February 2023 (UTC)