Что ж, это плохая идея только в том смысле, что теперь вы несете ответственность за поддержание внутренней ветки defacto ... каждый раз, когда WordPress выпускает обновление, вы должны выполнить трехсторонний diff, чтобы объединить ваши изменения в новый "настоящий" WordPress. (Трехсторонняя разность означает, что вы делаете различие между форком старой версии и стандартной старой версии для создания набора исправлений, а затем применяете этот набор исправлений к новой версии.) Вы также должны сами использовать VCS, чтобы сохранить себя. вменяемый.
Если вы не до этого, значит, вы не до этого, нет ничего плохого в том, чтобы следовать принципу KISS и не портить код приложения.
Если вы можете написать плагин, который делает то же самое и делает это так же эффективно, то вы должны сделать это, чтобы вам не пришлось поддерживать свой собственный форк.
Тем не менее, WordPress обладает многими вещами (эффективностью, безопасностью), которые вы можете улучшить (иногда без особой работы, просто отключив ненужный код), только взломав код приложения. WordPress - это грязный унаследованный код спагетти, изначально написанный людьми с практически нулевым знанием программного обеспечения или дизайна базы данных, и он делает множество невероятно глупых вещей, таких как запросы к базе данных при каждом запросе , чтобы узнать, что у нее есть siteurl если это никогда не изменится - нет ничего плохого в том, что нужно 5 минут, чтобы изменить 2 строки кода, поэтому он больше этого не делает.
Я работал техническим руководителем в тогдашнем топ-20 технорейском блоге и проделал большую работу по масштабированию WordPress на одном сервере, а затем на кластере (с отдельными серверами для администрирования и общедоступного доступа). У нас были обратные прокси-серверы верхнего уровня (то есть Varnish или Squid), выполняющие функции ускорителей HTTP, и внутренняя система кеширования фрагментов объектов / страниц, которая подключалась к memcached с переключением на кеширование файловой системы с помощью PEAR :: Cache_Lite. Нам пришлось изменить WordPress, чтобы он делал такие вещи, как отправка вменяемых, удобных для кэша заголовков HTTP, чтобы отключить много ненужного SQL и обработки.
Я изменил WP для работы с использованием механизма хранения кластера NDB только для памяти MySQL, что означало указание индексов во многих запросах (однако в итоге мы выбрали реплицированный кластер, однако). Изменяя его для работы с отдельными серверами для доступа администратора и общедоступного доступа, мы заблокировали общедоступную версию, чтобы она работала с сильно уменьшенными привилегиями MySQL, разрешающими только чтение (третий пользователь MySQL получил права комментирования).
Если у вас есть серьезная проблема со спамом в комментариях (например, 10K / час), то у вас есть , чтобы сделать что-то помимо плагинов. Спам поднимет вас, потому что WordPress просто инициализирует свое ядро - это что-то вроде полсекунды на автономном P4 без параллелизма, и, поскольку WP - это шарик кода, нет способа ничего сделать без предварительной инициализации ядра.
«WP-Cron» - это braindead, и его следует отключить, если у вас есть доступ к реальному crontab для выполнения этих функций. Не сложно сделать.
Короче, я мог бы продолжать перечислять причины, по которым вы можете захотеть внести изменения.
На протяжении всего этого, конечно же, по причинам ремонтопригодности была цель свести эти изменения к минимуму и документировать их как можно более четко, и мы реализовали множество плагинов, когда это имело смысл.