我最近不得不处理一个项目，以前的开发人员修改了wp-admin目录。这对我来说似乎是个坏主意，因为Wordpress是不断更新的。我只是不具备修改Wordpress的专业水平吗？
作为开源软件，我认为像WordPress这样的软件在任何时候都可以进行修改和扩展。
修改还是不修改是在权衡之间做出的选择。新功能可以封装为模块，这可能会导致它们的功能集成度低于预期。然而，随着新版本的发布，完全集成更改可能会阻碍软件的轻松更新。
直接修改软件确实需要非常熟悉软件的人，但这并不一定是个坏主意。
顺便说一句，我认为修改WordPress几乎是必要的，尤其是如果你想让它有一个像样的架构或真正安全的话（好吧，那是一个刺针，起诉我）。
好吧，这是一个坏主意，只是因为它意味着你现在要负责维护一个内部的defacto fork。。。每次WordPress发布更新时，你都必须进行三方差异处理，将你的更改合并到新的"真实"WordPress中。（三向差异意味着你在旧版本和标准旧版本的分叉之间进行差异，以构建一个补丁集，然后将该补丁集应用于新版本。）你自己也应该使用VCS来保持理智。
如果你不能做到这一点，那么你就不能做到，遵循KISS原则而不破坏应用程序代码没有错。
如果你能写一个插件做同样的事情，并且同样有效，那么你应该这样做，这样你就不必维护自己的fork
然而，WordPress在（效率、安全性）方面有很多糟糕的地方，你可以通过破解应用程序代码来改进（有时不需要太多工作，只需要禁用你不需要的代码）。WordPress是一种肮脏的遗留意大利面条代码，最初由几乎对软件或数据库设计一无所知的人编写，它会做很多非常愚蠢的事情，比如在每次请求时查询数据库，看看它自己的siteurl是什么，而这一点从未改变——花5分钟更改2行代码，这样它就不会再这样做了。
我在当时排名为20的Technorati博客上担任技术负责人，并做了大量工作，将WordPress扩展到一台服务器上，然后扩展到一个集群上（使用单独的服务器进行管理和公共访问）。我们有充当HTTP加速器的上游反向代理（即Varnish或Squid）和一个内部对象/页面片段缓存系统，该系统插入memcached，并使用PEAR:：cache_Lite故障切换到文件系统缓存。我们不得不修改WordPress来做一些事情，比如发送正常的、缓存友好的HTTP头，禁用许多不必要的SQL和处理。
我修改了WP，使其使用MySQL的仅限内存的NDB集群存储引擎运行，这意味着在许多查询中指定索引（然而，最终我们选择了复制集群）。在将其修改为使用单独的服务器运行以进行管理和公共访问时，我们锁定了公共端版本，因此它的MySQL权限大大减少，只允许读取（第三个MySQL用户获得了评论权限）。
如果你有严重的评论垃圾邮件问题（即10K/小时），那么你必须做一些插件之外的事情。垃圾邮件会让你DOS，因为WordPress只是在没有并发的独立P4上初始化它的核心就像半秒钟，而且由于WP是一个代码发球，如果不首先初始化核心，就没有办法做任何事情。
"WP Cron"是无脑的，如果您有权访问实际的crontab来执行这些功能，则应禁用它。不难做到。
简而言之，我可以永远列出你可能想要修改的原因。
当然，在整个过程中，出于可维护性的原因，我们的目标是将这些修改保持在最低限度，并尽可能清楚地记录它们，当有意义时，我们将许多插件实现为插件。
在一个博客/论坛组合中，我们将注册过程拼凑在一起，这样人们就可以填写一张表格，同时注册WordPress和phpBB。我相信插件有更好的方法可以做到这一点，但它确实有一个意想不到的好处——它真的让垃圾邮件机器人感到困惑。尽管每天都有几个人注册，但在论坛的生活中，我们已经收到了大约两条垃圾邮件。
当然，我不建议这样做——它会阻止我们升级任何一个软件。
如果可能的话，我倾向于强烈反对修改核心代码，尤其是在像WordPress这样更新的项目中。如果WordPress不能用插件之类的东西来做你需要的事情，那么你可能会更好地使用Drupal这样的可扩展/通用系统。把一个以博客为导向的CMS破解成其他东西可能不值得。
在旧版本的WordPress（1.0甚至2.0早期）中，我不会去修改WordPress本身。
然而，WordPress的架构已经成熟。边栏不再需要手动编码。相反，您可以移植您的主题以使用小部件，只需创建小部件（真是天赐良机！）。不喜欢某些内容的显示方式——只需修改主题即可！不喜欢WordPress处理某些事情的方式？创建一个插件。我很难想出修改WordPress代码本身的理由，因为它不能通过WordPress的现代模块化组件（小部件、插件、主题）来处理。
我是那种在WordPress这样的开源应用程序中总是"躲在幕后"的人。然而，如今，真的没有充分的理由修改WordPress的核心代码。