The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
WordPress is managed by a centralized version controlversion controlA version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. system called Subversion. A mirror of this repository is also available via Git, a distributed VCS.
The WordPress codebase can be accessed in a number of ways: using Subversion, using GitGitGit is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/., through TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (the bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. tracker), and via direct download:
Subversion: The repository is located at https://develop.svn.wordpress.org/. The main development branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". – called trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.– is https://develop.svn.wordpress.org/trunk.
Git: The repository is located at git://develop.git.wordpress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//. There is also a mirror of the WordPress repository on Github. Pull requests are welcomed on GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ but please follow the GitHub for code review guide to ensure pull requests are seen by other contributors.
If you are using either of the Git or Subversion repositories mentioned above, the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. codebase is in the src directory. A downloaded package serves a “built” version of this directory, thus placing these files in the root. The codebase consists of around 1000 files and directories.
Initial bootstrap files, such as index.php, wp-load.php, wp-blog-header.php, and wp-settings.php, appear in this src directory. Special handlers such as the XML-RPC, trackback, and comment submission endpoints, are also in the root.
The remaining files are divided into three distinct directories: wp-adminadmin(and super admin), wp-includes, and, to some extent, wp-content.
The 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 (e.g. Hello Dolly) and themes (e.g. Twenty Fifteen).
The 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 – PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher classes. Some of these are external libraries.
ms-*.php – Code specific to WordPress multisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site 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 APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..
The files in wp-admin/includes follow similar naming conventions.
The wp-admin directory contains the code powering the administration area of WordPress. The primary bootstrap is wp-admin/admin.php. Other special files include admin-header.php and 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 interface.
The 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.
The wp-admin and wp-includes directories also have js and css directories, for scripts and styles, respectively. Third-party scripts are packaged in a compressed and minified state, which are available at https://wordpress.org/download/source/. Both minified and development versions are included for core scripts and styles, with the minified versions receiving the suffixes .min.js and .min.css.
The wp-includes directory has a number of third-party libraries in folders. The wp-includes/js directory, in particular, has jquery and tinymce directories, with the former holding jQuery, jQuery UIUIUser interface, and various plugins, and the latter holding TinyMCE and various TinyMCE core and WordPress-specific extensions.
To search the codebase, developers rely on either a project search tool in their code editor or IDEIDEIntegrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality., or command-line utilities such as ack or grep. Browsing the codebase on Trac is manageable, but one particular feature is noteworthy: Trac includes an excellent user interface for the Subversion blame command.
To blame a line of code means 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 are very important.
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 wp-admin/includes/upgrade.php(where else are they located? we should be specific here).
Database upgrade instructions are included in wp-admin/includes/upgrade.php. Whenever a database change is needed 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 and the database will keep up with the more than a decade of changes.
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.
The function wp_upgrade() calls upgrade_all() (among other functions), 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 that are required – for example, adding new tables, altering fields, adding indexes. For dbDelta() to run over the core table definitions, the DB version in version.php simply needs to be bumped.
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 into 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, the newly downloaded code 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.