I recently had to work on a project where the previous developer modified the wp-admin directory. It seems like a bad idea to me, since WordPress is constantly updated. Am I just not at that level of expertise with modifying WordPress?
Is it necessary in any circumstance to modify WordPress other than writing plugins and themes?
Being open source, I think it’s a common thing for software like WordPress to be modified and extended at any point.
To modify or not to modify is a choice between trade-offs. New features can be encapsulated as modules, which may, perhaps, cause their functionality to be less integrated than desired. However, fully integrating changes may hinder easily updating the software as new versions are released.
It does require that someone be very familiar with the software to modify the software directly, but this isn’t necessarily a bad idea.
On a side note, I think modifying WordPress is almost a necessity, especially if you want it to have a decent architecture or to actually be secure (ok, that was a jab, sue me).
Well, it is a bad idea only in that it means you are now responsible for maintaining an internal defacto fork … every time WordPress releases an update, you have to do a three-way diff to merge your changes into the new “real” WordPress. (Three-way diff means you do a diff between your fork of the old version and the standard old version to build a patch set, then apply that patch set to the new version.) You should also be using a VCS yourself to keep yourself sane.
If you aren’t up to this then you aren’t up to it, there’s nothing wrong with following the KISS principle and not mucking up the application code.
If you can write a plugin that does the same thing and does it just as efficiently, then you should do that so you don’t have to maintain your own fork.
However, there are a lot of things WordPress is terrible at (efficiency, security) that you can ameliorate (sometimes without much work, just by disabling code you don’t need) only by hacking the application code. WordPress is dirty legacy spaghetti code originally written by people with virtually zero knowledge of software or database design, and it does a lot of tremendously stupid things like querying the database on every request to see what it’s own
siteurlis, when this never changes — there’s nothing wrong with taking 5 minutes to change 2 lines of code so it doesn’t do this any more.I worked as tech lead on a then-top-20 Technorati-ranked blog and did a lot of work to scale WordPress on a single server and then onto a cluster (with separate servers for admin vs. public access). We had upstream reverse proxies (i.e. Varnish or Squid) acting as HTTP accelerators and an internal object/page fragment cache system that plugged into memcached with failover to filesystem caching using PEAR::Cache_Lite. We had to modify WordPress to do things like send sane, cache-friendly HTTP headers, to disable a lot of unnecessary SQL and processing.
I modified WP to run using MySQL’s memory-only NDB cluster storage engine, which meant specifying indexes in a lot of queries (in the end we opted for a replicated cluster instead, however). In modifying it to run with separate servers for admin vs. public access, we locked down the public-side version so it ran with much reduced MySQL privileges allowing only reads (a third MySQL user got commenting privileges).
If you have a serious comment spam problem (i.e. 10K/hour), then you have to do something beyond plugins. Spam will DOS you because WordPress just initializing its core is something like half a second on a standalone P4 with no concurrency, and since WP is a code hairball there’s no way to do anything without initializing the core first.
“WP-Cron” is braindead and should be disabled if you have access to an actual crontab to perform these functions. Not hard to do.
In short, I could go on forever listing reasons why you might want to make modifications.
Throughout this it was of course a goal for maintainability reasons to keep these modifications to a minimum and document them as clearly as possible, and we implemented many as plugins when it made sense.
On one blog/forum combination, we hacked together the signup procedure so that people filled in one form to sign up to both WordPress and phpBB at the same time. I’m sure there’s a better way to do that with plugins, but it did have one unexpected benefit – it really confuses the spambots. Despite having several of them register each day, we’ve had about two spam posts in the life of the forum.
Not something I’d recommend, of course – it stops us from upgrading either software.
I tend to strongly advocate against modifying core code if at all possible, especially in a project that updates like WordPress does. If WordPress can’t be made to do what you need it to with plugins and the like, you’re probably better off with a more extensible/generic system like Drupal. Hacking a blogging-oriented CMS into something else might not be worth it.
In the older versions of WordPress (1.0 and even the early 2.0s), I wouldn’t bat an eye to modifying WordPress itself.
However, WordPress’ architecture has matured. Sidebars no longer need to be manually coded. Instead, you can port your theme to use widgets and just create widgets (what a godsend!). Don’t like how something is displayed – just modify the theme! Don’t like how WordPress handles something? Create a plug-in. I’m hard pressed to think of a reason to modify the WordPress code itself that cannot be handled via WordPress’ contemporary modular components (widgets, plug-ins, themes) instead.
I’m the type of person to always get “under the hood” in open source apps like WordPress. However, nowadays, there’s really no good reason to modify the core WordPress code.