WordPress Receive Updates For This Category
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
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
Some parts of the WordPress code structure for PHP markup are inconsistent in their style. WordPress is working to gradually improve this by helping users maintain a consistent style so the code can become clean and easy to read at a glance.
Keep the following points in mind when writing code for WordPress, whether for core programming code, Plugins, or WordPress Themes. The guidelines are similar to Pear standards in many ways, but differ in some key respects.
See also this post on the wp-hackers list. There is also a page on proposed Inline Documentation standards.
Single and Double Quotes
Use single and double quotes when appropriate. If you are not evaluating anything in the string, use single quotes. You should almost never have to escape quotes in a string, because you can just alternate your quoting style, like so:
An exception to this is JavaScript, which sometimes requires double or single quotes. Text that goes into attributes should be run through esc_attr() so that single or double quotes do not end the attribute value and invalidate the HTML and cause a security issue. See Data Validation for further details.
Indentation
Your indentation should always reflect logical structure. Use real tabs and not spaces, as this allows the most flexibility across clients.
include_once vs require_once
Learn the difference between include_once and require_once, and use each as appropriate. To quote the php manual page on include(): “The two constructs are identical in every way except how they handle failure. include() produces a Warning while require() results in a Fatal Error.” Fatal errors stop script execution.
Regular Expressions
Perl compatible regular expressions (PCRE, preg_ functions) should be used in preference to their POSIX counterparts. Never use the /e switch, use preg_replace_callback instead.
No Shorthand PHP tags
Important: Never use shorthand PHP start tags. Always use full PHP tags.
Remove Trailing Spaces
Important: Make sure you remove trailing whitespace after closing PHP tags.
Formatting SQL statements
When formatting SQL statements you may break it into several lines and indent if it is sufficiently complex to warrant it. Most statements work well as one line though. Always capitalize the SQL parts of the statement like UPDATE or WHERE.
Functions that update the database should expect their parameters to lack SQL slash escaping when passed. Escaping should be done as close to the time of the query as possible, preferably by using $wpdb->prepare()
$wpdb->prepare() is a method that handles escaping, quoting, and int-casting for SQL queries. It uses a subset of the sprintf() style of formatting. Example :
June 2, 2011 Developer Documentation 0 0
Deprecated Functions
There is a need to inform both theme and plugin developers and users of the usage of deprecated functions. In WordPress 2.4, a way to do that was added.
The following gives instructions on how to turn on the deprecated functions reporting, what hooks can be used for when deprecated functions are used, and code snippets demonstrating how all of this can be accomplished.
Normal Deprecated Function Reporting
When WP_DEBUG is enabled in wp-config.php, it will turn on the notices that deprecated functions were used. When WP_DEBUG is turned off or does not exist, then no reporting will be given.
This prevents the notices for everyday users who are uninterested in receiving these reports. As a consequence, only the users who actively enable WP_DEBUG will receive the information. Those users will not know to upgrade, unless they use a plugin which they download and activate.
The following code snippet enables WP_DEBUG and needs to be placed in wp-config.php.
Deprecated Function/File Action Hooks
When a deprecated function is used, the deprecated_function_run hook is called. Whenever a deprecated file is included, the deprecated_file_included hook is called. These hooks are actions and do not return anything. The deprecated_function_run is passed the function and the replacement. The deprecated_file_included is passed the file and which file replaced the deprecated one.
If the hooked function wishes to keep track of which deprecated function were run and how many times, the hooked function will have to do that itself.
Which function called the deprecated function or file is not known and is up to the plugin to preform a back trace to get that information.
Preventing the Notices From Displaying
When a plugin uses the above hooks, it could prevent notices from being displayed, even with WP_DEBUG enabled. It is then assumed that if a plugin hooked into both deprecated_function_run and deprecated_file_included that it would record and display the information in a more friendly matter.
To prevent the notices from displaying for functions, the deprecated_function_trigger_error filter hook should return false. To prevent notices from displaying for files, the deprecated_file_trigger_error filter hook should return false.
If a plugin does not have a way to display the deprecated function or file usage, then the plugin should not prevent the notices from appearing when WP_DEBUG is turned on. It should also make sure that the deprecated information is not displayed where any visitor can see it.