Do not hack MediaWiki core/pt-br

Mesmo que hackear o núcleo do MediaWiki seja muitas vezes uma solução proposta em outros fóruns de suporte do MediaWiki, não é uma solução ideal. Geralmente, o procedimento irá causar mais problemas do que resolver e só tornarão futuros upgrades mais difíceis de instalar.

Para os propósitos deste ensaio, o "núcleo" pretende incluir todos os arquivos que pertencem à instalação original do MediaWiki. Isto é todos os arquivos, exceto os de sua pasta extensions, ou outras pastas que você adicionou desde a sua instalação.

Por que você não deve modificar os arquivos do núcleo?
Não importa que seja fácil modificar os arquivos do núcleo para fazer o MediaWiki fazer o que você quer que ele faça, resista à tentação.


 * Se o fizer, fará com que seja complicado, difícil ou quase impossível de aplicar atualizações do site, tais como correções de segurança e de bugs.
 * Você vai deixar as coisas mais difíceis para aqueles que vêm depois para manter o site.
 * Você poderá deixar o seu site vulnerável a ataques.
 * Outros desenvolvedores estão menos inclinados a ajudá-lo se você tiver hackeado o seu núcleo - se não por outra razão, é difícil para eles saber o que foi feito.

O núcleo do MediaWiki foi projetado para ser modular, então não deve haver nenhuma razão para hackea-lo. Se há uma característica que você quer e não pode ser realizado fora do núcleo modificado, considere desenvolver uma extensão ou enviar o seu hackeamento como uma correção. Envie um relatório de bug e diga à comunidade o recurso que você quer realizar. Ele então será testado e seu recurso pode tornar-se uma parte do núcleo do MediaWiki.

Problemas enfrentados pelos wikis que hackeiam seu núcleo

 * Os tempos de atualização do MediaWiki vão de 30 minutos a 6 horas ou até mesmo seis semanas, se o seu diff mostrar que 13.650 linhas foram alteradas.
 * Aumento de spam e outros ataques indesejados devido a falhas de segurança
 * Perda de novos recursos devido a ataques conflitantes a arquivos do núcleo
 * Incapacidade de usar documentação do MediaWiki.org - tudo o que foi escrito sob o pressuposto de que você não tenha hackeado seus arquivos de núcleo (a não ser, é claro, que você escreva a documentação especificamente sobre a forma de operar o MediaWiki quando esse hackeamento em particular está sendo usado)
 * 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
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.
 * 2) Develop an extension to accomplish what your hack was intended to do
 * 3) Submit a bug report
 * 4) Contribute your improvement to core to the code repository so others can benefit from your fix