Reading a WordPress plugin’s SVN commit history
Every plugin in the directory has a public repository. Most people never open one. It answers questions the directory page cannot.
WordPress.org hosts every directory plugin in Subversion, publicly readable, no account required. The URL is predictable:
https://plugins.svn.wordpress.org/<slug>/
You can open that in a browser. You do not need an SVN client for anything in this article.
The layout
Three directories, and the convention is strict:
trunk/- current development. For most plugins this is what the next release will be built from.tags/- one directory per released version.tags/2.4.1/is exactly what shipped as 2.4.1, frozen.assets/- the banner, icon and screenshots for the directory listing. Not shipped to sites.
The Stable tag line in a plugin's readme.txt decides which of those tags directories is actually served to users. This is the single most misunderstood mechanism in the directory: the version people install is whatever Stable tag points at, not the highest number in tags/ and not trunk.
Reading the log
The easiest route is the directory page's Development tab, which renders the recent history with revision numbers, usernames and dates.
Revision numbers are global across the whole plugin repository, not per plugin. A commit at r3318812 tells you when it happened relative to every other plugin, which is occasionally useful and often confusing the first time you see it.
What you are reading for:
- Which usernames appear, and when each first appears.
- The gap between commits. Eighteen quiet months followed by sudden activity is worth a look, particularly if the committer is new.
- What actually changed. A version bump and a readme edit is not the same as a new file in
includes/.
Spotting a first-time committer
This is the signal worth the effort, and the log gives it to you directly: a username whose earliest revision in this plugin is recent.
Be careful about one thing - the person may be well known elsewhere. A committer with ten years of history across core and forty plugins, appearing in this one for the first time, is a different proposition from an account created six weeks ago. Open https://profiles.wordpress.org/<username>/ before drawing a conclusion.
The question is never "is this person trustworthy". It is "did the set of people who can ship code to my site change, and do I know why".
Reading an actual change
Browsing to a file in trunk/ shows its current content. To see what a specific revision changed, an SVN client is genuinely easier:
svn log -v -r 3318812 https://plugins.svn.wordpress.org/<slug>/
svn diff -c 3318812 https://plugins.svn.wordpress.org/<slug>/
The first lists the paths touched; the second shows the change. On a plugin you are worried about, the paths alone usually answer the question.
What the log will not tell you
Three things, and they matter:
- Who authorised the commit. SVN records the account that committed, not whether that account was in the right hands at the time.
- Anything about premium plugins. Code distributed from a vendor's own site is not here at all.
- Whether the code is malicious. You are reading provenance, not behaviour. A backdoor committed by the legitimate owner looks exactly like any other commit - which is the whole difficulty.
Doing it in practice
For one plugin you are suspicious about, this takes five minutes and is worth doing properly. For forty plugins across a dozen client sites, repeated weekly, it is not a realistic manual task - and a check you do once is close to worthless, because it establishes a baseline and then never compares against it.