WordPress is managed by a centralized version control system called Subversion, and all development processes of the core developers are centralized.
The WordPress codebase can be accessed via numerous ways: using Subversion, through Trac (the bug tracker), and through a direct download:
- Subversion. The repository is located at https://core.svn.wordpress.org/. The main development branch, trunk, is https://core.svn.wordpress.org/trunk.
- Trac. The repository can be viewed through the browser at https://core.trac.wordpress.org/browser/. A log of changesets can be viewed at https://core.trac.wordpress.org/log/.
- Download. The latest stable version of WordPress can be downloaded at http://wordpress.org/latest.zip or http://wordpress.org/latest.tar.gz. The latest nightly build (2300 GMT) can be found at http://wordpress.org/nightly-builds/wordpress-latest.zip or wordpress-latest.tar.gz.
How Code in WordPress is organized #
The codebase consists of around 1000 files and directories. Primarily:
Initial bootstrap files, such as
wp-settings.php, appear in the root directory. Special handlers such as the XML-RPC, APP, trackback, and comment submission endpoints, are also in the root.
The remaining files are divided into three distinct directories:
wp-includes, and to some extent,
wp-content directory consists of user-defined and site-specific files, including themes, plugins, and uploads. The repository only contains a
wp-content directory for the bundled plugins and themes.
wp-includes directory consists of the primary core and third-party libraries for WordPress. Many of these files are loaded as the application is bootstrapped.
The files in
wp-includes go by a mostly standard set of prefixes and suffixes:
class-*.php— PHP classes. Some of these are external libraries.
ms-*.php— Code specific to WordPress multisite functionality.
default-*.php— Code that implements or defines default functionality, namely constants, widgets, and filters.
*deprecated.php— Functions which are deprecated.
*-template.php— Template functions for the relevant API.
The files in wp-admin/includes follow similar naming conventions.
wp-admin directory consists of the administration area for WordPress. The primary bootstrap is
wp-admin/admin.php. Other special files include
admin-footer.php, the AJAX handler
admin-ajax.php, and the generic POST handler
admin-post.php. Most of the files in the
wp-admin directory are pages in the WordPress admin.
wp-admin/includes directory consists of the primary core and third-party libraries available and used in the administration area. Some of these are loaded as the admin is bootstrapped — see
wp-admin/includes/admin.php for the primary list of files included.
wp-includes directories also have
css directories, for scripts and styles. Third-party scripts are packaged in a compressed and minified state, which are available at http://wordpress.org/download/source/. Both minified and development versions are included for core scripts and styles, with the minified versions receiving the suffixes
wp-includes directory has a number of third-party libraries in folders. The
wp-includes/js directory, in particular, has
tinymce directories, with the former holding jQuery, jQuery UI, and various plugins, and the latter holding TinyMCE and various TinyMCE core and WordPress extensions.
Searching and Browsing Code History #
To search the codebase, developers rely on either a project search tool in their code editor or IDE, or command-line utilities such as
grep. Browsing the codebase on Trac is manageable, but one particular feature is noteworthy: Trac includes an excellent user interface for the Subversion
To “blame” a line of code would be to determine who last edited that line, and when. To access this in Trac when browsing a file, click the “Annotate” link in the top right corner. Most consider the UI far more efficient than individual svn blame commands.
Core committers do not make changes to WordPress lightly, and commits should never occur without as complete understanding of the existing code as possible. If the code causes a bug, was that always the case? When was it introduced? Why? Is the code in question a fix for a different bug? These questions and more are very important. For more, consult the section on Researching Code History with Subversion Annotate.
When a WordPress install is initially run, if a
wp-config.php file cannot be located, the
wp-load.php file will suggest you visit
wp-admin/setup-config.php to create the configuration file.
Once this is done, you’ll be taken to
wp-admin/install.php. At this point, the database tables are created. The database schema is stored in
wp-admin/includes/schema.php, and the installation libraries are primarily located in
Database Upgrades #
upgrade.php also includes database upgrade instructions. Whenever something about the database needs to change with a new version of WordPress — whether that means altering the database structure, or updating some database content — an upgrade routine can be triggered. Indeed, you can safely update from WordPress 0.70 to the latest version with the database keeping up with the changes over the better part of a decade of progress.
Knowing when to upgrade is handled by a number in
wp-includes/version.php, the WordPress database version. This number corresponds to a revision number of the codebase, generally the revision that last introduced a database upgrade routine. When the number in the code differs from the number stored in the database, the routines in
wp-admin/includes/upgrade.php are run.
wp_upgrade() calls, among other functions,
upgrade_all(), which will run the appropriate routines in sequence. In order to trigger a new routine, a schema bump — changing the right numbers, including the WordPress database version in
version.php — needs to occur.
Changes to the database structure are handled by a function called
dbDelta(), which takes the table definitions, compares them to the existing schema, and makes any changes — adding new tables, altering fields, adding indexes — that are required. For
dbDelta() to run over the core table definitions, the DB version in
version.php simply needs to be bumped.
File Updates #
Core developers generally distinguish between database “upgrades” and version “updates.” Updating WordPress to the newest codebase (via the user interface) triggers a complex series of actions.
Prior to any update, WordPress has already polled
api.wordpress.org to determine whether it needs to update, and if so, where to find the new version. Once the update is triggered, WordPress will download the ZIP archive and unzip it to a temporary directory in
wp-content/upgrade. A single file,
wp-admin/includes/update-core.php, will be copied out of the temporary directory and over the existing
wp-admin/includes/update-core.php, at which point it will be executed. Thus, newly downloaded code then handles the main process of copying over the new files. This allows us to provide instructions specific to the new version, such as which files are old and can be removed.
Exploring The Code #
These tools may be useful in exploring the WordPress codebase: