How WordPress plugins began: from hooks in 1.2 to one-click installs and auto-updates
Every WordPress plugin, from a ten-line snippet to a full online shop, relies on a mechanism that arrived in May 2004. This is how the plugin system grew from a developer feature into the way most sites are built.
Before plugins: editing the code
WordPress was first released in 2003 as a fork of an earlier blogging script, b2/cafelog. In its first versions, changing how the software behaved generally meant editing its PHP files directly. Those modifications, shared on forums and personal blogs as "hacks", had an obvious problem: every upgrade overwrote them, and they had to be re-applied by hand, one file at a time.
WordPress 1.2: the hook architecture (2004)
WordPress 1.2, code-named Mingus, was released on 22 May 2004. Among its headline features, the release announcement listed a "new plugin architecture" and explained: "Plugins can now hook into nearly every action WordPress does."
That sentence describes a design still in use today. WordPress calls named hooks at defined points while it runs. There are two kinds, described in the Plugin Handbook:
- Actions let a plugin run code at a given moment, such as when a post is published or just before an email is sent (
add_action()). - Filters let a plugin receive a value, change it and hand it back, such as the text of a post or the sender address of an email (
add_filter()).
A plugin is simply a PHP file with a comment header that WordPress reads, starting with Plugin Name:; the header requirements list the other fields. Because plugins live in their own folder and attach to hooks rather than rewriting core files, upgrading WordPress no longer erased customisations. The same mechanism is what the code examples on this site use, such as the phpmailer_init action in sending WordPress email through SMTP.
Themes, pages and a growing ecosystem (2005 to 2007)
WordPress 1.5 (Strayhorn, February 2005) introduced Pages and theme templates, giving designers the same kind of separation that plugins had given developers. WordPress 2.0 followed on 31 December 2005. Over these years plugins multiplied: statistics counters, spam filters, contact forms, newsletter tools and mail fixes were among the commonest, because they filled gaps that core did not cover.
Installing one was a manual job. You downloaded a ZIP file from the author's site, unpacked it, uploaded the folder to wp-content/plugins/ by FTP and activated it. Finding out about updates meant revisiting the author's site or following their blog. Many small independent sites of the time, including the one that once used this domain, published plugins this way; the same culture of hobbyist add-ons had earlier grown around instant messengers, as told in the messenger add-on era.
WordPress.org gathered plugins in a central directory, and WordPress 2.3 (Dexter, September 2007) added update notifications, so the dashboard could tell administrators when a newer version of a plugin was available there.
WordPress 2.7: installing from the dashboard (2008)
WordPress 2.7 (Coltrane, 10 December 2008) changed everyday administration. Its feature list includes a plugin browser embedded in the dashboard, one-click plugin installs, core updating, and an uninstall mechanism that lets a plugin clean up after itself when it is deleted. For the first time, a site owner could search the directory, install a plugin and keep WordPress itself up to date without touching FTP.
Further steps followed quickly: one-click theme installs in WordPress 2.8 (June 2009) and batch plugin updates in 2.9 (December 2009). "Must-use" plugins, files in wp-content/mu-plugins/ that load automatically and cannot be deactivated from the dashboard, came from WordPress MultiUser; according to the Advanced Administration handbook, the code handling them was merged into the main WordPress code in March 2009, and WordPress 3.0 (June 2010) then merged MultiUser itself into core as Multisite. Must-use plugins remain a handy place for small site-specific snippets.
Rules for the directory
As the directory became the main distribution channel, its rules shaped the ecosystem. The detailed plugin guidelines require, among other things, that plugins be compatible with the GNU General Public License, that their code be mostly human-readable, that trialware is not permitted, and that plugins may not track users without their consent. Each new plugin is reviewed before it appears, and plugins can be closed for security problems or guideline breaches.
Safer updates (2013 to 2024)
The more plugins a site ran, the more updates it needed, and an out-of-date plugin with a known vulnerability became one of the commonest ways into a hacked site. WordPress responded in stages:
| Version | Released | What changed for plugins |
|---|---|---|
| 3.7 | October 2013 | Automatic background updates for maintenance and security releases of core. |
| 5.2 | May 2019 | Site Health, protection against PHP fatal errors (a recovery mode that pauses the faulty plugin) and plugin compatibility checks. |
| 5.5 | August 2020 | Auto-updates for plugins and themes, switchable one by one in the admin, and updating by uploading a ZIP file. |
| 5.6 | December 2020 | Application passwords for API access. |
| 6.5 | April 2024 | Plugin dependencies: a Requires Plugins header lists other plugins that must be installed and active first. |
| 6.6 | July 2024 | Rollbacks when a plugin auto-update fails. |
The dates and features come from the release list on WordPress.org's history page, which also records WordPress 7.0, released on 20 May 2026.
What the old plugins tell us
Looking back at the plugins of 2005 to 2008 shows what WordPress was missing at the time. Many of the most-wanted ones did jobs that core later took over, or that moved to dedicated services:
- Thumbnail sizes and image handling are now built in, with several sizes generated on every upload.
- Page ordering is part of the page editor and of navigation menus, which arrived in WordPress 3.0.
- Newsletters moved largely to specialised email services, for reasons explained in sending a newsletter from WordPress: deliverability, consent records and unsubscribe rules.
- SMTP mail is still a plugin job, because WordPress core deliberately leaves the mail transport to the host; the authentication rules that make it necessary have their own story, told in a short history of email authentication.
The hook system from 2004 is the thread running through all of it. A plugin written today registers actions and filters in much the same way as one written for WordPress 1.2, which is why the old idea of "hooking into nearly every action" still describes how WordPress is extended.
HistoryThe messenger add-on era
A short history of the third-party add-ons built for Yahoo! Messenger, AIM and MSN Messenger in the 2000s, why they existed, and what happened to the networks they extended.
Email & newslettersSending a newsletter
How to run an email newsletter from a WordPress site today: in-site plugins versus email services, double opt-in, unsubscribe rules, and sender authentication.
Email & newslettersWhy WordPress mail goes missing
Why WordPress emails disappear or land in spam, how wp_mail() works, and how to route site mail through an authenticated SMTP server or sending service.