Do not hack MediaWiki core

From MediaWiki.org
Jump to: navigation, search

Other languages:
Deutsch • ‎English • ‎español • ‎suomi • ‎français • ‎italiano • ‎日本語 • ‎polski • ‎português • ‎português do Brasil • ‎русский

While hacking MediaWiki core is often a solution proposed on other MediaWiki support forums, it is not an ideal solution. Generally, it will cause you more problems than it solves and will only make future upgrades more difficult to install.

For the purposes of this essay, "core" is meant to include all files that belong to the original MediaWiki installation. That is to say all files except LocalSettings.php, the ones in your "extensions" folder, or other folders which you have added since your installation.

Why you should not modify core files[edit]

No matter how easy it is to modify core files to make MediaWiki do what you want it to do, resist the temptation.

  • Doing so will make it complicated, difficult or near impossible to apply site updates such as security and bug fixes.
  • You will make it difficult for those that come after to maintain the site.
  • You could possibly leave your site vulnerable to exploits.
  • Other developers are less inclined to help you if you have hacked your core - if for no other reason than it is difficult for them to know what has been done.

The MediaWiki core has been designed to be modular, so there should be no reason to hack it. If there is a feature you want and it cannot be accomplished outside of modifying core, consider developing an extension or submitting your hack as a patch. Submit a bug report and tell the community the feature you want to accomplish. It will then be tested and your feature may become a part of the MediaWiki core.

Problems faced by wikis which hack their core[edit]

  • MediaWiki upgrade times go from 30 minutes to 6 hours or even 6 weeks if your diff shows 13650 lines have been changed.
  • Increase in spam and other unwanted attacks due to security holes
  • Missing out on new features due to conflicting hacks to core files
  • Inability to use MediaWiki.org documentation - all of which has been written under the assumption that you have not hacked your core files (unless of course you write documentation specifically for how to operate MediaWiki when that particular hack is being used)
  • Repetition of the original problem - as a bug report is a for more reliable way to solve a problem than a core hack - if for no other reason than a group of developers will be looking into the problem and may discover necessary code changes you missed
  • Complaining to developers about your core files not working - and not finding much sympathy - if you hack core files - effective technical support is all but impossible

Exceptions[edit]

Are there exceptions to this rule?

Nope.

Okay, very very rarely. But this is generally for specific wikis or implementations by people who are extremely familiar with the MediaWiki code base, development practices and security model. Those who properly document their changes and practice proper revision control with their code. If you have to ask, chances are you shouldn't.

Extensions[edit]

Note that most of this page also applies to important extensions. It's a bad idea to directly start hacking the Semantic MediaWiki extensions, or any of the extensions used on Wikipedia and other Wikimedia sites.

An exception could be if an extension is mainly installed by copying its code from this wiki (instead of getting it from a software repository). It means it's not very seriously maintained.

What to do instead[edit]

Rather than hacking MediaWiki core, there are several alternative solutions to consider, more or less in this order:

  1. MediaWiki is a powerful beast out of the box, you can do a lot with MediaWiki's interface messages such as MediaWiki:Sidebar and many many others, see also other pages on this wiki for e.g. JavaScript and CSS additions and changes.
  2. Develop an extension to accomplish what your hack was intended to do, or simply use one of the existing hooks
  3. Submit a bug report
  4. Contribute your improvement to core to the code repository so others can benefit from your fix