A recent article How to Turn a Normal WordPress Installation into a Working Online-Shop discusses how to turn a normal WordPress installation into a working online shop. Although the article is very thorough and well written, it is not the easiest method to turn your WordPress installation into a working online shop. The easiest way to achieve this is by downloading and installing the WP e-Commerce plugin.
- e-Commerce Install
- e-Commerce setup
- PayPal Setup
- Google Checkout Setup
- Business Blogging
Why stop there? Business blogging is really starting to take off. More and more people are starting to use WordPress to power their websites 8211; especially now that there are so many powerful plugins. Lets take a quick glance at some of the plugins we use to turn your average WordPress install into a business blogging solution.
- Static Front Page. You might not want the front page of your web site to be your blog. See Creating a Static Front Page.
- Forums. Use bbPress or WP Forum depending on the requirements. Both are easy to install and both have a range of useful features.
- Email Newsletters. Use WP Campaign Monitor because it is simple to install and easy to get the hang of. It also integrates with WP e-Commerce lite.
- Surveys. Information is power. Use the Survey Fly plugin because it is powerful and easy to use. Administrators can download .csv reports that they can manipulate internally using proper spreadsheet software.
- Statistics. Use WP SlimStat because it is so easy to install.
- Google Analytics. Google Analytics tells you everything you want to know about how your visitors found you and how they interact with your site. Google Analytics for WordPress automatically tracks and segments all outbound links from within posts, comment author links, links within comments, blogroll links and downloads. It also allows you to track AdSense clicks, add extra search engines, track image search queries and it will even work together with Urchin. The WordPress Plugin repository has other Google Analytics plugin listed under the analytics tag.
- Search Engine Optimization. Search Everything enables the searching of Pages, Comments and more. No Hacking or modifications necessary, just install, activate the plugin and configure it under Options > Search Everything
- Ecommerce 038; Shopping Cart. Turn your WordPress Installation into a fully functional Ecommerce Platform. See the available Ecommerce Plugins 038; Ecommerce Themes for WordPress.
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 8220;unit-tested8221; 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.
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.)
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.
Although WordPress displays in U.S. English by default, the software has the built-in capability to be used in any language. The WordPress community has already translated WordPress into many languages, and there are Themes, translation files, and support available in many other languages (see WordPress in Your Language).
To install an international version of WordPress, you have two choices.
Manually Installing Language Files
Here are the steps you will need to follow to install an international version of WordPress.
- Download the .mo language file for your language (see WordPress in Your Language for hints on how to find one). The naming convention of the .mo files is based on the ISO-639 language code (e.g. pt for Portuguese) followed by the ISO-3166 country code (e.g. _PT for Portugal or _BR for Brazil). So, the Brazilian Portuguese file would be called pt_BR.mo, and a non-specific Portuges file would be called pt.mo. Complete lists of codes can be found at (country codes) and (language codes). You can use this plugin to automatically download language files stored in the wordpress svn repository wp-native-dashboard.
- Open your wp-config.php file in a text editor and search for
- Edit this line according to the .mo file you have just downloaded, e.g. for the Portuguese spoken in Brazil you must add:
- Note that if the .mo and .po files do not exist for a language code called for in wp-config.php then there is no error message, but the code is still used in language_attributes(). This is useful for those of us whose language is similar enough to en-US not to require translation, but who do not want en-US as the language tag in the blog, instead wanting some other variant of English. For example:
- Once you have added your language code, save the file.
- On your site server, create a new folder in your /wp-content OR /wp-includes directory called /languages.
- You may also need to translate a few other files
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).
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 8220;Edit8221; on the right.
- Scroll down to the 8220;Mailing Lists8221; section.
- Check (to subscribe) or Uncheck (to unsubscribe) the appropriate checkbox.
- Click the 8220;Update Profile8221; 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).
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 8211; a Subversion plugin for the Eclipse development environment
- Tortoise SVN 8211; a popular Windows Subversion client
- The Subversion Book 8211; available free online
Note that if you choose to use Tortoise, Subclipse, or another graphical client, the commands below will be menu selections 8212; 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 8220;tagged8221; 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/
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.
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 8220;Foobar 18243; and 8220;Foobar 28243;:
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 8220;Right Sidebar8221; and 8220;Left Sidebar8221;, 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 8220;h28243; 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.
What is this?
If you are a plugin developer, you know how difficult it can be to figure out which hooks are available. This WordPress hooks database automatically scans each WP build for apply_filters(), do_action(), and do_action_ref_array to figure out exactly which hooks are available in each version and where the hooks occur.
If you do not know what WordPress hooks are for, read the Plugin API
What is this good for?
- See what new hooks are available with each new version of WordPress>
- See which hooks have been deprecated or renamed (use the 8220;view all hooks8221; option)
- Easily learn exactly which WP file(s) use each hook. That way, if the hook is poorly documented, you can just look in the source and figure out what it does.
- For 397 of the most-used hooks, you can read a brief description of the hook. These are scraped from the official WordPress documentation action reference and filter reference
How to help?
Update and improve the official action and filter references. Next time we scrape those, your contributions will show up here. (And preserve the formatting of those references so that my code can parse them.)