Не зламуйте ядро MediaWiki

Хоча злом ядра MediaWiki часто є рішенням, запропонованим на інших форумах підтримки MediaWiki, це не' ідеальне рішення. Як правило, це спричинить більше проблем, ніж вирішує, і лише ускладнить встановлення майбутніх оновлень.

Для цілей цього есе «ядро» означає всі файли, які належать до оригінальної інсталяції MediaWiki. Тобто всі файли, крім LocalSettings.php, docker-compose.override.yml, файли у вашій папці «extensions» або «skins» або інших папок, які ви додали після встановлення.

Чому вам не слід змінювати основні файли

Незалежно від того, наскільки легко змінити основні файли, щоб змусити MediaWiki робити те, що ви хочете, утримайтеся від спокуси.

• 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

• 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 far 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

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

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

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.

1. Develop an extension to accomplish what your hack was intended to do, or simply use one of the existing hooks

1. Submit a bug report

1. Contribute your improvement to core to the code repository so others can benefit from your fix

See also

• {{Extension by patch warning }} — template to add to the pages of extensions that require modifications to MediaWiki core.