Developer Documentation Receive Updates For This Category
June 2, 2011 Developer Documentation 0 0
This article lists common questions for WordPress core developers, as well as developers of WordPress plugins and themes, and refers you to articles that contain the answers. There is also a list of resources at Developer Documentation, which might be of help.
How To Contribute to WordPress
Where do I sign up?
Check out Contributing to WordPress to find out what you can do and how to get involved.
How do I submit a bug report?
See Reporting Bugs.
How does code make it into WordPress?
See How does code make it into WordPress.
Are there standards for the code in WordPress?
Yes. WordPress Coding Standards has a list of coding standards used by WordPress core developers, plugin developers, and theme authors.
Can I help by translating WordPress?
Definitely! See WordPress in Your Language for information on existing translations, and Translating WordPress to find out how you can help if your language translation is missing or needs improvement.
What is Subversion?
Subversion is the online program used to track changes and upgrades to WordPress for developers. See Using Subversion for more information. There is also an online browser for the WordPress Subversion repository.
How do I report a bug in a plugin?
Problems with plugins are best reported to the plugin author (visit the plugin home page to find out how to contact the author). For plugins that are included in the wp-plugins.org Plugin Repository, you can also report bugs in the wp-plugins.org TrackTickets site.
Is there a list of plugins?
Yes, there are several. Plugins has the most comprehensive list of plugin repositories.
How do I write a plugin?
Basic instructions on how to write a plugin for WordPress can be found in Writing a Plugin. The API of “Hooks” for plugins is described in Plugin API. There is also a comprehensive list of other plugin resources in Plugin Resources.
June 2, 2011 Developer Documentation 0 0
The files of WordPress define many useful PHP functions. Some of the functions, known as Template Tags, are defined especially for use in WordPress Themes. There are also some functions related to actions and filters (the Plugin API), which are therefore used primarily for developing Plugins. The rest are used to create the core WordPress functionality.
Many of the core WordPress functions are useful to Plugin and Theme developers. So, this article lists most of the core functions, excluding Template Tags. At the bottom of the page, there is a section listing other resources for finding information about WordPress functions. In addition to this information, the WordPress phpdoc site details all the WordPress functions by version since 2.6.1.
You can help make this page more complete!
Here are some things you can do to help:
- Add documentation to un-documented functions, by creating sub-pages or at least by adding short comments in the lists below. If you create a subpage for a function, please include information and examples of usage of that function, if possible, per the examples found in Template Tags.
- List more functions here, following the category structure.
- Correct errors by moving functions to better categories where appropriate, and of course fixing typos.
Note: that it is OK for a function to appear in more than one category.
Functions by category
Post, Page, Attachment and Bookmarks Functions
- get_adjacent_post
- get_boundary_post
- get_children
- get_extended
- get_next_post
- get_permalink
- get_post
- get_post_ancestors
- get_post_mime_type
- get_post_status
- get_post_type
- get_previous_post
- get_posts
- is_post (deprecated)
- is_single
- is_sticky
- register_post_type
- wp_get_recent_posts
- wp_get_single_post
- wp_delete_post
- wp_insert_post
- wp_publish_post
- wp_update_post
- add_post_meta
- delete_post_meta
- get_post_custom
- get_post_custom_keys
- get_post_custom_values
- get_post_meta
- update_post_meta
- get_attached_file
- is_attachment
- is_local_attachment
- update_attached_file
- wp_attachment_is_image
- wp_insert_attachment
- wp_delete_attachment
- wp_get_attachment_image
- wp_get_attachment_image_src
- wp_get_attachment_metadata
- wp_get_attachment_thumb_file
- wp_get_attachment_thumb_url
- wp_get_attachment_url
- wp_check_for_changed_slugs
- wp_count_posts
- wp_mime_type_icon
- wp_update_attachment_metadata
June 2, 2011 Developer Documentation 0 0
WordPress Theme Directory – Official showcase and hosting for WordPress Themes.
Theme Development
This article is about developing WordPress Themes. If you wish to learn more about how to install and use Themes, review Using Themes. This topic differs from Using Themes because it discusses the technical aspects of writing code to build your own Themes rather than how to activate Themes or where to obtain new Themes
Why WordPress Themes
WordPress Themes are files that work together to create the design and functionality of a WordPress site. Each Theme may be different, offering many choices for site owners to take advantage of in order to instantly change their website look.
You may wish to develop WordPress Themes for your own use, for a client project or to submit to the WordPress Theme Directory. Why else should you build a WordPress Theme?
- To create a unique look for your WordPress site.
- To take advantage of templates, template tags, and the WordPress Loop to generate different website results and looks.
- To provide alternative templates for specific site features, such as category pages and search result pages.
- To quickly switch between two site layouts, or to take advantage of a Theme or style switcher to allow site owners to change the look of your site.
A WordPress Theme has many benefits, too.
- t separates the presentation styles and template files from the system files so the site will upgrade without drastic changes
to the visual presentation of the site. - It allows for customization of the site functionality unique to that Theme.
- It allows for quick changes of the visual design and layout of a WordPress site.
- It removes the need for a typical WordPress site owner to have to learn CSS, HTML, and PHP in order to have a great-looking website.
Why should you build your own WordPress Theme? That the real question.
- It’s an opportunity to learn more about CSS, HTML, and PHP.
- It’s an opportunity to put your expertise with CSS, HTML, and PHP to work.
- It’s creative.
- It’s fun (most of the time).
- If you release it to the public, you can feel good that you shared and gave something back to the WordPress Community (okay, bragging rights)
June 2, 2011 Developer Documentation 0 0
Guidelines
- Code Quality:
Themes are required not to generate any WordPress deprecated-function notices, PHP errors, warnings, or notices,
HTML/CSS validation errors, or JavaScript errors. - Functionality:
Whether implementing required, recommended, or optional functionality, Themes are required to
support proper WordPress core implementation of all included functionality. - Template Tags and Hooks:
Themes are required to implement WordPress template tags and hooks properly. - WordPress-Generated CSS Classes:
Themes are required to support WordPress-generated CSS classes. - Theme Template Files:
Themes are required to utilize Theme template files properly. - Licensing:
Themes are required to be licensed fully under a GPL-compatible license. - Theme Name:
Themes are required to use appropriate Theme Names. - Credit Links:
Themes are recommended to use credit links. If used, credit links are required to be appropriate. - Theme Documentation:
Themes are required to provide sufficient documentation to explain the use of any custom features or options. - Theme Unit Tests:
Themes are required to meet all requirements in the Theme Unit Tests - Theme Obsolescence:
Themes are required to be kept current once accepted into the Theme Repository
Functionality
- Automatic Feed Links
- Widgets
- Comments
- Navigation Menus
- Post Thumbnails
- Custom Header
- Custom Background
- Visual Editor CSS
- Translation/Internationalization
June 2, 2011 Developer Documentation 0 0
Automated testing is running test cases where manual intervention is not required to run each one. This is usually in the form of writing test suites which have multiple test cases and an xUnit library and command line tool that runs the test suite or suites.
The test suite execution is usually manual, from the developer choosing which suites on the command line to run, but this is not required. The process could be automated and looked over from time to time to ensure that when the code changed, no problems were introduced.
Everything outside of writing test cases and test suites for the Automattic WordPress Tests repository and running them is outside of the scope of this page. The Automattic WordPress Tests is the formal and authoritative automated testing suite for WordPress. The only way to download is by checking out with Subversion.
The process to add your test suite and test cases to existing suites is to add them to the WordPress Core Trac ticket that has the bug that the test case or suite tests. After you have done this, add “unit-tested” to the keywords of the ticket to inform the lead developers that it has been added.
You must not run the Automattic WordPress Tests on a web site you do not want to be deleted. The Automattic WordPress Tests will remove all WordPress table data before and after it runs the tests, so use a test database for the Automattic WordPress Tests.
The Automattic WordPress Tests environment is WordPress executed as if you were integrating it into another web application. You can not simulate clicks like in a browser, but you can test code as it would be executing in the normal environment.
The current WordPress Tests repository does use Mock Classes, so they are allowed to be used, but not required. At this point the distinction between unit testing and functional testing is pretty blurred, so it is more hybrid testing environment.
Downloading
You will need to download Subversion before you can continue, if you do not have it already. You should also have an empty MySQL database available. Create a new one if you have to, but you do not want anything in there.
Check out the latest testing suite from http://svn.automattic.com/wordpress-tests/
(The wordpress-tests files themselves can be checked out anonymously, but halfway though the checkout you may be asked for your wordpress.org username/password. That because the wordpress-tests project includes the source code for WordPress itself, via an external reference, and that requires read-access authentication.)
Configuration
1. In the root folder of the checkout copy wp-config-sample.php to wp-config.php.
2. Edit it to include your database name/user/password.
You might find it easier to just go to that WordPress installation and run the install, so that it creates the wp-config for you. After, you can copy that to the directory below and run the tests. The Automattic WordPress Tests will be looking for wp-config.php in the same directory as wp-test.php. This will also prevent an error in which wp-cron.php will fail, because it can not find wp-config.php in that directory.
Running The Tests
The wp-test.php will initiate the automated test suite run. There are some options for which to control what tests are run and other options which trigger how the automated test suite works. Without any arguments, all tests will be run with default options.
The average time for running all of the tests can range between 2 minutes and 7 minutes. This is with the current 399 test cases. When the amount increases, so will the time it will fully take to execute all of the tests.
Note for Windows Users: The wp-test.php makes use of certain color codes that are not interpreted by the windows shell and displayed as symbol characters. A Patch is available.
Run the tests by typing: php wp-test.php in the command line.
June 2, 2011 Developer Documentation 0 0
Thank you for contributing to the project we all love! Your participation is vital to the WordPress project.
WordPress is a user-driven project, and all developments and enhancements depend on users like you! Please consider contributing to the project and the WordPress Community in one or more of the ways outlined below. Contributions from users like you keep the project vibrant, alive and on the path of progress.
What can you do to keep WordPress going? Read on…
Documentation
All of the documentation at the Codex has been produced by users like you and me! The many different ways in which you can volunteer your time and effort to improve the quality and scope of documentation are outlined in Contributing to the Codex.
The wp-docs mailing list is the forum for discussing all issues related to developing WordPress documentation. The goals of the documentation project are described in About the Codex.
You can also help by translating the Codex (see the section just below).
Translation
Translating WordPress describes the process of translating the WordPress software, so that people can use WordPress for blogs in languages other than English. This article and its companion, WordPress in Your Language, also tell you how to find and join the teams that are translating WordPress and the Codex (see the above Documentation section for information about the Codex).
The WP Polyglots blog is for questions, suggestions and discussions related to translating WordPress; please feel free to join in.
WordPress Support Forum
Another valuable contribution you can make is donating some of your time to help other users of WordPress. All WordPress related support at the WordPress Support Forum is provided free of cost, and the involvement of users is essential to maintain this.
If you like to help, read Support Forum Volunteers to find out how, and join the wp-forums mailing list.
WordPress IRC Live Chat
Another support mechanism for WordPress users is IRC. There is an IRC channel for discussions on WordPress topics on the IRC FreeNode Server at #wordpress, and you can help by answering questions there. For more information on this see IRC and WordPress IRC Live Help.
There is a weekly meetup of core developers in #wordpress-dev on Freenode. Agendas, minutes, and discussion between meetups all take place on the WordPress Development Blog.
WordPress Development
You can help with the development of the WordPress software, whether or not you are a software developer.
WordPress Development
You can help with the development of the WordPress software, whether or not you are a software developer.
Development Planning
One way to participate in WordPress development is to suggest features and participate in the development planning process. Even if you are a developer, you can help build consensus and formalize proposals, boiling down long email threads and IRC logs to their essence, so that developers can quickly ascertain what the community is hoping to achieve with a particular feature.
Testing WordPress
Another valuable contribution a non-developer (or developer) can make to WordPress development is to test WordPress. Before every stable release of WordPress, pre-release versions are made to enable testing. You can download the pre-releases and test them, so that the WordPress developers can fix problems before the new version is made available to the public. If you would like to get involved in this effort, join the wp-testers mailing list, where new releases are announced and discussed.
If you want to be on the bleeding edge of development, even before pre-release versions are put together, you can also check out the latest software from the WordPress Subversion (SVN) repository, as outlined in Using Subversion. Or, you can get the “nightly build” (which is created from the Subversion repository, and available as a zip file) at http://wordpress.org/nightly-builds/wordpress-latest.zip — almost as up-to-date as the instantaneous Subversion repository.
If you find bugs while testing pre-release or already-released versions of WordPress, see the section just below.
Reporting Bugs
Another way you can contribute to WordPress development is by reporting any problems you find with the WordPress software. The process of reporting bugs is described in Reporting Bugs — please start by reading that article. Once you have understood the bug reporting process, you can search the WordPress Trac database to see if your issue has already been reported, and if not, file a new report. Your help with reporting bugs will be highly appreciated.
Fixing Bugs and Other Programming
If you are a software developer, you can also help the development of WordPress by fixing problems that have been reported by you or another person in the WordPress Trac database. This process is also known as “patching”, and is described in Reporting Bugs. That article also has some suggestions on how to find bugs to fix.
You can also subscribe to the wp-hackers mailing list to participate in discussions regarding WordPress development. All contributions, ideas and suggestions are welcome at the mailing list. Sometimes, requests are also made on the list asking for the help of volunteers to assist in the improvement and development of specific functionality.
Occasionally there are also bug days on the #wordpress-bugs IRC channel. You can read about what happens in a bug day in WordPress Bug Hunts, and subscribe to either the wp-hackers or wp-testers mailing list to find out when they happen.
You may also be interested to read this page on How does code make it into WordPress. It details how bug fixes, code and new features are included into the next releases of WordPress.
June 2, 2011 Developer Documentation 0 0
The WordPress project has a number of email lists focused on different facets of development. Note that none of these lists is appropriate for user support. The best place for user support is the Support Forums. For some other support options, see Other Community Sites.
Announcement Mailing Lists
These announcement lists are one-way only and are low traffic (a few emails per year).
WordPress Announcements
This list is meant for major announcements regarding the WordPress project, like new releases.
WordPress Development News
Information about new APIs, API changes and other news for developers is sent out to this list.
This list is only open to developers who have a plugin in the WordPress Plugins Directory or a theme in the WordPress Themes Directory.
Subscribe / Unsubscribe
You can subscribe to or unsubscribe from any of the Announcement Mailing Lists by editing your WordPress.org forums profile.
- 1. Go to http://wordpress.org/support/profile/
- Log in (if you are not already logged in).
- Click “Edit” on the right.
- Scroll down to the “Mailing Lists” section.
- Check (to subscribe) or Uncheck (to unsubscribe) the appropriate checkbox.
- Click the “Update Profile” button at the bottom of the page.
Community Mailing Lists
These discussion lists are two-way and can be very high traffic (easily dozens of emails per day).
June 2, 2011 Developer Documentation 0 0
When a new major version of WordPress is released, such as WordPress 2.1 or 2.2, you may find that your Themes and Plugins no longer work the way you are used to. It could be that they are completely broken, because something in WordPress that was fundamental to them changed, but it also possible that you can get them working again by updating some settings, or maybe just a small edit.
This article is a list of other Codex articles that cover how to upgrade your plugins and themes from one WordPress version to the next.
- Upgrade 1.2 to 1.5 – Covers how to convert a really old Theme to the current theming system.
- Migrating Plugins and Themes to 2.1 – Covers changes between WordPress 2.0 and WordPress 2.1
- Migrating Plugins and Themes to 2.2 – Covers changes between WordPress 2.1 and WordPress 2.2
- Migrating Plugins and Themes to 2.3 – Covers changes between WordPress 2.2 and WordPress 2.3
- Migrating Plugins and Themes to 2.5 – Covers changes between WordPress 2.3 and WordPress 2.5 (there was no version 2.4)
- Migrating Plugins and Themes to 2.6 – Covers changes between WordPress 2.5 and WordPress 2.6
- Migrating Plugins and Themes to 2.7 – Covers changes between WordPress 2.6 and WordPress 2.7
- Migrating Multiple Blogs into WordPress 3.0 Multisite – Covers changes between WordPress blogs into WordPress 3.0 Multisite
June 2, 2011 Developer Documentation 0 0
This page only applies to developers, so if it all Greek to you, do not worry!
Most software projects, including WordPress, use a version-control system to keep track of their source code and its revisions behind the scenes, and periodically release versions of the software for public use. Prior to the WordPress 1.5 release, the WordPress source code was stored in the CVS version-control system at Sourceforge. Since WordPress 1.5, WordPress has been using its own installation of Subversion for version control. Most WordPress users will never want to use Subversion, because they will only install the released versions of WordPress. However, developers of plugins and themes may want to test their software against the latest development version of WordPress, and people interested in Contributing to WordPress by testing or fixing bugs will also need to have access to the code that is in development.
This development code is available via Subversion. In this article, we all cover the basics of connecting to the WordPress Subversion repository and running the commands that are available to most WordPress users.
There is also a section on Not Using Subversion, that explains how to download versions of the software without installing Subversion. You all also want to read the section on Repository, Branches, Trunk, and Tags.
Aside from the one section on Not Using Subversion, this article assumes that you have Subversion (or at least a Subversion client) installed already, and it only covers the most basic commands. For installation instructions, alternative clients, and more detailed information, check out these resources:
- Subversion web site
- Subversion FAQ
- Subclipse – a Subversion plugin for the Eclipse development environment
- Tortoise SVN – a popular Windows Subversion client
- The Subversion Book – available free online
Note that if you choose to use Tortoise, Subclipse, or another graphical client, the commands below will be menu selections — however, the same principles apply. Check the help files for your client to figure out how to connect to the repository and execute the equivalent commands.
Repository, Branches, Trunk, and Tags
The basic idea of Subversion is that the source code and revisions are kept in a repository on a server. Users connect to the repository by using a client program, which allows the user to check out, view, edit, patch, and commit changes to the source code files (depending on the client permission level; in the WordPress project, only a couple of people have permission to commit changes to the repository).
The WordPress repository is at http://core.svn.wordpress.org/. Within the repository, there are three sections:
- trunk: http://core.svn.wordpress.org/trunk/always contains the latest development code
- tags: When a version is released to the public, the source code is “tagged” with the version number. So for instance, WordPress 2.7.1 can be found at http://core.svn.wordpress.org/tags/2.7.1/
- branches: Sometimes when major new versions of WordPress are created, the WordPress development team makes a commitment to maintain the previous release with bug fixes (usually limited to major bugs and security issues). So, for instance, the latest development code on the 2.8 branch of WordPress can be found at http://core.svn.wordpress.org/branches/2.8/
June 2, 2011 Developer Documentation 0 0
This page contains the technical documentation of the WordPress Widgets API (Application Programming Interface). The intended audience for this information includes WordPress theme authors, plug-in authors and anyone who would like to write a stand-alone widget. This document assumes a basic understanding of PHP scripting.
A widget is a PHP function that echoes string data to STDOUT when called. To turn such a PHP function into a WordPress Widget it must be registered as such. This is done using a PHP callback (a Pseudo-Type in PHP documentation) that is registered by a WordPress Widget API function.
The WordPress Widget API is located in wp-includes/widgets.php.
Define Sidebars
The functions listed below are used to add functioning sidebars to a theme.
Register Several Sidebars
Registers one or more sidebars to be used in the current theme. Many themes have only one sidebar. For this reason, the count parameter is optional and defaults to one.
The $args parameter will be passed to register_sidebar() and follows its format, with the exception of the name, which is treated with sprintf() to insert or append a unique number to each sidebar if count is plural.
For example, the following line will create sidebars name “Foobar 1″ and “Foobar 2″:
register_sidebars(2, array(‘name’=>‘Foobar %d’));
Register Single Sidebar
register_sidebar( $args );
The optional $args parameter is an associative array that will be passed as a first argument to every active widget callback. (If a string is passed instead of an array, it will be passed through parse_str() to generate an associative array.) The basic use for these arguments is to pass theme-specific HTML tags to wrap the widget and its title. Here are the default values:
There are times you might need to call this function instead of register_sidebars. An example of this would be when you want to give unique names to the sidebars, such as “Right Sidebar” and “Left Sidebar”, or when they should be marked up differently. The names appear in the admin interface and are used as an index for saving sidebar arrangement. Please note: sidebar arrangements can be reused and overwritten when another theme is chosen that uses the same sidebar names.
The default before/after values are intended for themes that generate a sidebar marked up as a list with “h2″ titles. This is the recommended convention for themes. Themes built using this structure can simply register sidebars without issues in regard to the before/after tags. If a theme cannot be marked up in this way, these tags must be specified when registering sidebars. It is recommended to copy the id and class attributes verbatim so that an internal sprintf call can work and CSS styles can be applied to individual widgets.