Sarah who does a great job sharing her WordPress knowledge for BloggingTips.com published a simple guide on how to add theme options to your theme. The guide goes over the code needed, explains what the code does, and provides a good base to start from if you’re planning on adding options to your theme. In today’s world of WordPress themes, theme options are a necessity to making it easy on end users to change various aspects of a theme. Just be careful you don’t go overboard adding every option imaginable.
Simple Guide To Adding Theme Options
24 Hour Has-Patch Marathon Underway
Jane Wells has announced on the WordPress.org development blog that the 24 hour has-patch marathon is now underway. The reason it’s called has-patch is because in trac, when someone submits a patch, the tags ‘has-patch‘ is added to the keyword field making it easier to sort through those tickets which actually have a patch.
During the next 24 hours, the core developers will be evaluating patches that have been tested and committing those that are up to par.
Grab yourself a copy of the nightly build to make sure you’re using the right version, then head over to Trac and start looking at the has-patch* tickets. Pick a ticket, download the diff, test it out on the browsers/platforms you have available, and write a comment about the results in the ticket’s comment thread. Move on to the next ticket. Do as many as you can over the next 24 hours.
Next Monday, Jane will publish the results of the marathon and in her message to the testers mailing list, she upped the incentive on contributing to this event:
When I put up the results of the marathon on the dev blog on Monday, I’ll also link to the top 5 testers from the 24-hour marathon period (measured by number of patches tested/commented in trac treads).
Hopefully, all goes well and if I can find the time, I’ll see if I can do a bit of testing on a patch or two. Last but not least, WordPress 2.8 is now feature frozen.
Social Bookmarking With WordPress Plugin
In this article by Vladimir Prelovac, we will learn to create our first functional WordPress plugin and learn how to interact with the WordPress API (this is the WordPress interface to PHP) on the way. The knowledge you will gain in this article alone will allow you to write a lot of similar plugins.
Let’s get moving! This article is extracted from the “WordPress Plugin Development ” book. In this article, you will learn:
- Creating a new plugin and having it displayed in the plugins admin panel
- Checking the WordPress version and control activation of the plugin
- Accessing API features—for example the title and permalink URL of each post
- Using WordPress hooks to execute your plugin code when it’s needed
- Using conditional tags to control the flow of your plugins
You will learn these by creating a Social Bookmarking type of plugin that adds a Digg button to each post on your blog
As you probably know, Digg is a very popular service for promoting interesting content on the Internet. The purpose of a Digg button on your blog is to make it easier for Digg users to vote for your article and also to bring in more visitors to your blog.
The plugin we’ll create in this article will automatically insert the necessary code to each of your posts. So let’s get started with WordPress plugin development!
Plugging in your first plugin
Usually, the first step in plugin creation is coming up with a plugin name. We usually want to use a name that is associated with what the plugin does, so we will call this plugin, WP Digg This. WP is a common prefix used to name WordPress plugins.
To introduce the plugin to WordPress, we need to create a standard plugin header. This will always be the first piece of code in the plugin file and it is used to identify the plugin to WordPress.
Time for action – Create your first plugin
In this example, we’re going to write the code to register the plugin with WordPress, describe what the plugin does for the user, check whether it works on the currently installed version of WordPress, and to activate it.
- Create a file called wp-digg-this.php in your favorite text editor. It is common practice to use the plugin name as the name for the plugin file, with dashes ‘-’ instead of spaces.
- Next, add a plugin information header. The format of the header is always the same and you only need to change the relevant information for every plugin:
<?php/*Plugin Name: WP Digg ThisVersion: 0.1Description: Automatically adds Digg This button to your posts.Author: Vladimir PrelovacAuthor URI: http://www.prelovac.com/vladimirPlugin URI: http://www.prelovac.com/vladimir/wordpress-plugins/wp-digg-this*/?>
- Now add the code to check the WordPress version:
/* Version check */global $wp_version;$exit_msg='WP Digg This requires WordPress 2.5 or newer.<a href="http://codex.wordpress.org/Upgrading_WordPress">Pleaseupdate!</a>';if (version_compare($wp_version,"2.5","<")){exit ($exit_msg);}?> - Upload your plugin file to the wp-content/plugins folder on your server using your FTP client.
- Go to your WordPress Plugins admin panel. You should now see your plugin listed among other plugins:
- This means we have just completed the necessary steps to display our plugin in WordPress. Our plugin can be even activated now—although it does not do anything useful (yet).
What just happened?
We created a working plugin template by using a plugin information header and the version check code. The plugin header allows the plugin to be identified and displayed properly in the plugins admin panel. The version check code will warn users of our plugin who have older WordPress versions to upgrade their WordPress installation and prevent compatibility problems.
The plugin information header
To identify the plugin to WordPress, we need to include a plugin information header with each plugin.
The header is written as a PHP comment and contains several fields with important information.
This code alone is enough for the plugin to be registered, displayed in the admin panel and readied for activation.
If your future plugin has more than one PHP file, the plugin information should be placed only in your main file, the one which will include() or require() the other plugin PHP files.
Checking WordPress versions
To ensure that our plugin is not activated on incompatible WordPress versions, we will perform a simple WordPress version check at the very beginning of our code.
WordPress provides the global variable $wp_version that provides the current WordPress version in standard format. We can then use PHP function version_compare() to compare this and our required version for the plugin, using the following code:
if (version_compare($wp_version,"2.6","<")){// do something if WordPress version is lower then 2.6}
If we want to stop the execution of the plugin upon activation, we can use the exit() function with the error message we want to show.
In our case, we want to show the required version information and display the link to the WordPress upgrade site.
$exit_msg='WP Digg This requires WordPress 2.6 or newer. <ahref="http://codex.wordpress.org/Upgrading_WordPress">Pleaseupdate!</a>';if (version_compare($wp_version,"2.6","<")){exit ($exit_msg);}
While being simple, this piece of code is also very effective. With the constant development of WordPress, and newer versions evolving relatively often, you can use version checking to prevent potential incompatibility problems.
The version number of your current WordPress installation can be found in the footer text of the admin menu. To begin with, you can use that version in your plugin version check (for example, 2.6).
Later, when you learn about WordPress versions and their differences, you’ll be able to lower the version requirement to the minimal your plugin will be compatible with. This will allow your plugin to be used on more blogs, as not all blogs always use the latest version of WordPress.
Checking the plugin
You can go ahead and activate the plugin. The plugin will be activated but will do nothing at this moment.
Time for Action – Testing the version check
- Deactivate the plugin and change the version check code to a higher version. For example, replace 2.6 with 5.0.
if (version_compare($wp_version,"5.0","<"))
- Re-upload the plugin and try to activate it again. You will see a WordPress error and a message from the plugin:
What just happened?
The version check fails and the plugin exits with our predefined error message. The same thing will happen to a user trying to use your plugin with outdated WordPress installation, requiring them to update to a newer version.
Have a go Hero
We created a basic plugin that you can now customize.
- Change the plugin description to include HTML formatting (add bold or links to the description).
- Test your plugin to see what happens if you have two plugins with the same name (upload a copy of the file under a different name).
WordPress Plugin Development (Beginner’s Guide)
 |
|
Vladimir’s Plugin Developer Tips
Vladimir Prelovac who has been seen all over this site recently has published a pretty cool guide of 10 tips for WordPress plugin developers on Mashable.com The tips range from how to get an idea for a plugin to, using the WordPress plugin directory. Vladimir wrote an entire book dedicated to developing WordPress plugins so I take it, he knows what he’s talking about.
Small Preview Of WordPress 2.8
With the release of WordPress 2.8 pushed back now to April 1st, (dates are always tentative) I decided to download the nightly build for March 7th and wanted to take a look to see what sort of progress has been made. At this point, no widget management features have been added to the core that I am aware of. I do know that Andrew Ozz has been assigned the task to revamp the Widget Management area. I wish him the best of luck! However, syntax highlighting along with function lookups have been added to both the plugin and theme editor. Here is what they look like.
One thing I noticed already in the 2.8 bleeding edge version is that just like plugins, you can browse the theme repository and install themes without leaving your blogs backend. You can search, preview, and upload themes as well. Check it out.
Although work is ongoing, I did want to mention the fact that MagPie RSS will no longer be the default parsing engine that WordPress uses. Instead, it will be SimplePie RSS. Simple Pie will be used in WordPress 2.8 for widget and dashboard feeds. Also at some point, plugins which used MagPie RSS that was built into WordPress will at some point no longer work. So if you have a plugin that does this such as the KB Advanced RSS Widget plugin, make sure to update your code to use the new parsing engine. No need to rush it though as backwards compatibility will be in WordPress for a little while before it is completely removed.
Last but not least, you’ll be able to select between 1-4 columns for your dashboard widgets.
For a look at what will most likely come down the pike in WordPress 2.8, please see this Codex article dedicated to the version.
New WordPress Book For Plugin Development
Vladimir Prelovac who I consider to be a WordPress Rockstar in his own right has is very own book called WordPress Plug-In Development. Beginner’s guide. Vladimir is not only a plugin developer but also a good theme developer as well if you take Blue Grace or Amazing Grace as examples.
Approach
This is a Packt Beginners Guide, which means it focuses on practical examples and has a fast-paced but friendly approach, with the opportunity to learn by experiment and play. Each chapter builds a practical plug-in from the ground up using step-by-step instructions. Individual sections show you how to code some functionality into your plug-in and follow up with a discussion of concepts.
Who this book is written for
This book is for programmers working with WordPress, who want to develop custom plug-ins and to hack the code base. You need to be familiar with the basics of WordPress and PHP programming and believe that code is poetry; this book will handle the rest.
Vladimir has worked on the book for the past year where version 2.5, 2.6, and 2.7 were released respectively. The book goes into detail regarding the underpinnings of the software, plugin security, development, hooks, and much more. It’s currently available in either Paperback form or online via PDF.
I’ve asked Vladimir if he would like to appear on a future episode of WordPress Weekly and he has agreed to do so despite the recording time being 2 AM at his location. What a trooper! As it stands, I have him scheduled to appear on WordPress Weekly on Friday, March 27th. We’ll be talking about his book, plugins, themes, and all sorts of WordPress Goodness.
If you’re new to development such as myself, I recommend giving WordPress For Dummies a read before this book. That way, you’ll gain knowledge of certain terminology used in development such as hooks, filters, actions, etc.
An Idea For WordPress Ideas
Just wondering if it’s time to wipe the slate clean on the WordPress Ideas site to start over? The reason being is that the top five most popular ideas are ideas which were submitted over two years ago. If you ask me, this looks bad as it tends to lean towards the WordPress project not really implementing ideas that are obviously wanted by quite a few people using the software. On the flip side, many of the ideas that are still labeled as UNDER CONSIDERATION have since made it to the core in one version or another. Am I wrong or is this simply a case of someone or a group of people not supplying patches to address those issues? Another reason to wipe the slate clean is that all ideas from that day forward should be relevant with how the software is today and not how it was two years ago. So even though the public’s desire for a specific feature two years ago was high, that might not be the case currently and we have no way of knowing.
If the Ideas site is not going to be wiped clean, then there needs to at least be a user driven way to flag a particular idea as IMPLEMENTED with a small explanation of when and how that idea has been implemented into the core of WordPress. This would definitely give the sense that the peoples voices/ideas are heard. As a side benefit, you could probably take a look at all of the implemented ideas and get a good handle on where the project is headed in the near future.
The Ideas part of the WordPress project is another example of something I’ve been noticing as of late and that is, the core WordPress project getting most of the attention which it should, but various branches of the project are dying because of the lack of attention to them. From what I know, Matt is the guy in charge of the ideas section and if this is true, I hope he plans on having a few people in the wings to help him out. WordPress is far more popular today than it was a few years ago and perhaps the Ideas part of the project has lost its precedence. While I would like for all branches of the WordPress tree to be tended too on the same pace as the trunk, I’m guessing that the scope of the project as well as the low amount of Core Developers prevents this from happening. That is why I believe implementing a few different methods to allow the average joe community members to help out would be beneficial to the overall project.
Of course, you’d still need someone taking care of the administration/validation work, but at least the initial load would be taken off their back.
You know, I could have just published this post as an idea to the WordPress Ideas site but why? From the outside looking in, I see ideas that have been voted upon for over two years which to a new person, would seem as though WordPress has not yet added them to the core. However, since I have experience with the software since version 2.3, I know a few ideas which have been implemented that are still labeled as Under Consideration. So why then would I submit an idea if all of the other ideas seemingly have not been addressed or at least, modified to represent the software in its current state?
To top things off, I don’t even know who to contact with regards to the Ideas Section of the WordPress.org site. Do I bring this issue up on the WordPress.org forum? Do I submit this to the WP-Hackers mailing list in fear of publishing something that doesn’t belong their? Do I email Matt and hope that my particular email does not fall victim to the amount of noise his inbox already experiences? One thing that I’ve become increasingly frustrated with regarding the entire WordPress Project is the lack of a WordPress Whitepages. I have no idea on who to contact for what part of the project. If I can’t figure out who to contact, I fall back on just contacting Matt but that isn’t the way it should work. I wish there were some sort of central directory of contact information, most likely a page on the Codex with relatively updated information so that end users knew who to contact and for what purpose.
I started with an idea but ended with a rant. I suppose if I really want a solution to some of these problems, I should get off my ass and do something about it myself. So with that in mind, look forward to a WordPress Contact directory that I’ll publish first on this blog, and then get it implemented onto the Codex where I hope others will contribute.
What Is WordPress Bloat?
Keeping an eye on the WordPress Hackers mailing list of late, I noticed a discussion where the word bloat was used numerous times. Out of my own curiosity, I decided to ask those on the list what the definition of bloat was. The answers were not surprising. Everything from items that are added to core but are barely used to, anything could be considered bloat.
Andrew Rickmann published a response which is more in line with my thoughts on bloat.
In the case of the former, as long as it doesn’t add a significant amount to the download or slow down WordPress almost no feature will be bloat, in the case of the latter almost any feature could be bloat.
Finally, of course, it is so individual that it is impossible to reach agreement. I think the links / blogroll / whatever it is called now, functionality is pointless bloat, but loads of people use it, like it, and would fight me to the death to keep it. We would both be right, and wrong.
I thought this was a great response by Andrew and it’s true. Bloat in WordPress is defined on an individual level meaning hundreds of interpretations around a single feature could take place if an argument was brought up about it bloating WordPress. Therefore, does something in WordPress become labeled as bloat only if the majority of people believe or think it to be or is there some other process or set of circumstances that have to be met for something to fall into the bloat category? Keeping in mind Andrew’s response, can anything in WordPress actually be labeled as bloat if it’s useful to at least a few people?
I believe we could argue all day about what is and is not bloated material in WordPress but I guess the final say always comes down to those with commit access to the core as well as Matt’s guidance.
WordPress 2.7.1 RC 1 Released
Ryan Boren announced on the WordPress Testers mailing list today that WordPress 2.7.1 RC1 has been released. So far, looks like a couple of bugs have been squashed with the potential for a few more before this version hits the public. Here is a short list composed by Ryan announcing the bugs fixed thus far.
- URL column in Edit Links removes www. from domains that end in www
- Theme preview fails when theme in subdirectory
- Draft Saved’ current_time not reflecting timezone setting in the edit area
- Revisions do not respect time zone offset
- Canonical redirect of feed URLs with suffixes is wrong
- index.php file in the plugins folder makes the Dashboard fail
You can grab WordPress 2.7.1 RC1 here. By the way, according to my last 2.7.1 post, I’m in line to take the bet that 2.7.1 will be released on Monday February 9th, but I guess we’ll see.
WordPress Needs To Revise Post Revisions
When WordPress 2.6 was released on July 15, 2008 one of the new features to hit the core was something called Post Revisions. Post revisions keep track of changes made to a post or page and stores a copy of that page or post before the revision so in case you make a huge mistake or want to see the progression of your content, the post revisions will be right there for you to choose. While having post revisions is all fine and dandy, providing no way for the end user to actually control this feature is not.
With the recently installed version of WordPress for WPTavern, I noticed that post revisions were starting to rack up. Upon doing a Google search, I discovered that I could easily disable post revisions from occurring if I added the following code to my WP-Config.php file:
define('WP_POST_REVISIONS', 0);
For some reason, this code didn’t work. Also as part of my Google search, I came across a forum thread on the WordPress.org forums from six months ago specifically about the topic of post revisions as others didn’t like the feature as well and wanted to turn it off. In the forum thread, there was an argument against adding more checkboxes and features into the backend of WordPress and how there was no negative impact with simply leaving Post Revisions turned on. Well, I can attest to the fact that when I deleted the post revisions that were made on another blog of mine from the database, the size of the database shrank considerably. While the revisions may be made up of only text, hundreds of them eventually add up. No need to convince me of compression and how well the revisions are written, I simply don’t want my database filling up with that kind of stuff.
So while reading the thread, I read about a ticket that was filed in the WordPress Trac system to address some of the issues pertaining to the feature but the ticket was closed with a resolution of Won’t Fix while the milestone was deleted. The ticket also contained a response from DD32 with a link to a post-revision plugin he had created. Instead of using his plugin, I came across another one called Revision Control which has enabled me to not only keep post revisions turned on, but I can also limit the maximum number of revisions a post/page should have. This is good enough for me to keep the post revision feature turned on.
Here is the part that I find concerning. WordPress has options for just about every feature an end user would interact with on a daily basis. Post revisions has no configuration options. Why not just add a revision section within the WRITING settings which contained options to limit the maximum amount of revisions, enable or disable post revisions, choose between post revisions for posts and pages, and that’s it. For me to install a plugin to provide the type of functionality that should have originally came bundled with that feature is concerning to say the least. One could argue that the way in which post revisions has been added could be equated to having that feature rammed down their throats. Granted, adding one line of code to the Config file of WordPress is not hard, it is not something that should have to be done.
I would open a Trac ticket to request that the features provided by the plugin I mentioned above be added to the core for the Post Revision feature, seeing the previous Trac ticket filed as WON’T FIX is a bit of a downer but thanks to the community around the project and its open source nature along with its popularity, when there is a problem, plugin developers do a great job solving them.
Feedback:
So what do you think of the post revisions feature? Do you use it? How do you feel about not having any way to control how the feature works from the Administration panel?