Tag Archives: wordpress

Finish All Inline Documentation for WordPress 2.7

The focus should be on completing the remaining functions and correcting already current inline documentation. It would be nice to finish everything for WordPress 2.7, but there are a few projects that might in the way of that goal.

I’m currently doing the Google Summer of Code and the second part of the project is taking most of my time. There is a good reason for that, it is a lot more difficult than the first part and I need to focus a lot of effort into completing the project. There is a big incentive for completing the project, so you know, I’ll be working on that.

I’ve been mostly working on the Inline Documentation, while I’ve either need something else to work on to get my mind off of the GSOC project. Doing this in order to not get burned out and rest my mind to come back with a new perspective.

Possibly Related Posts:


Unit Tests Work! A Look at WordPress

Unit Testing works! The best part? It is fun. At least at the expense of someone else. I pick on WordPress because it is the system that I’m building unit tests for. I’m going to look at different bugs that were solved and may have been found because of unit testing.

add_filter() in plugins.php

Was Reported. Tested and solved by unit testing.

Problem

Usage with objects is broken, even with the current version (2.2.2) and trunk. The problem is from using serialize on classes, which when added, after the properties change, cannot be removed. This is because the class “state” has changed and will serialize to a different string than what was added.

Solutions

  1. The fix, that won’t affect all plugins that use classes, is to explicitly check for objects and add a new property to that class that can be later referenced. It works, but it is slow, almost 3x as slow as serialize. Wasn’t tested on PHP 4 systems, but in theory, if it works on PHP 5, it should work for PHP 4.
  2. All plugin authors, which choose to use classes to include __sleep() method in their class, which cache the state at the beginning and return that state. This would provide consistency, but would require work for all plugin authors and would force WordPress blog administrators to upgrade their plugins.
  3. Don’t use classes as plugins or use another class for storing properties.

apply_filters() in plugins.php

Was patched and was only confirmed by unit tests.

Problem

If you remove a filter that is part of the same tag inside the apply_filter loop, it will ignore the rest of the hooks. (from ticket).

Interestly, the problem was in there places, but only fixed in two. Also interesting is that the functionality was duplicated in three different places instead of creating a function and using that instead.

Solution

See ticket.

merge_filters() in plugins.php

Was reported.

Problem

Array_merge will append (the desired result) $wp_filter['all'] to $wp_filter[$tag] and completely destroy the priority that was set for $wp_filter[$tag] (most likely not the desired result).

From this I can gather that a person won’t be able to remove a hook that was added. I can also figure that nothing and no one uses $wp_filter['all'] because it would destroy the priority for every hook. Or it works and I’m crazy.

My tests prove that 1) array_merge destroys the priority, and 2) if I had tested for it, it would have proven that you wouldn’t be able to remove a previous hook afterwards (conjecture, will need to add it into the test).

Thanks to Sam Angove, from wp-hackers, there are several bugs in the formatting.php file, so at least it proves that Unit Testing is justified. If it is justified with only two Unit tests with over 50%, I think it also says a lot for other projects.

Unit Testing is awesome, PHPUnit and SimpleTest is awesome. What else more do you need?

Possibly Related Posts:


WordPress Core Updating Kind of Works

I gave the WordPress core upgrader a test and aside from the PHP time out it seemed to work okay. I would think that the PHP time out will need to be increased, since it isn’t only a few files that are being copied.

I still hope that the original WordPress will be zipped up for backup and easy restore. It would work even better if the core upgrader could sense that it didn’t finish and then finish the rest of the files or restore back to the original.

This should allow for testers to download beta versions and keep updated with the changes being made. It should give an incentive to plugin developers to test their plugins with the latest version.

Possibly Related Posts:


WordPress Plugins I Will Write When I Have Time

I’ve been thinking of several plugins I want to write, but don’t currently have time. My time should be focused on the Google Summer of Code project and bringing the rest of my sites up since they’ve been down.

What I have so far:

  1. Feed Statistics – A feed plugin that tracks the statistics of the feed. A hosted version of FeedBurner with minimal feature set.
  2. Automatic Post Queue – Tracks the current upcoming posts and sends the posts to the future, so that no more than a certain amount is posted per day without manually checking.

There are several plugins I have written so far that need to be revisited. The Swift Mailer needs to be looked at and fixed. The Swift Mailer needs to have localization added, as well as other enhancements to the attachment handling. The administration is still broken and needs to be fixed.

There is also the WordPress Performance Testing Plugin, that needs to be extended in its feature set as well. I’m going to focus some more on this after the Google Summer of Code is over. I’m looking forward to using it in my own development.

I think that in September, I’m going to work on my plugins and develop the above plugins. I also want to create a theme for this site and buy several themes for absidongames.com and dragonu.net. I want to finish those sites up and hopefully get them going to where I don’t need to maintain them very often. Just add content.

Possibly Related Posts:


Why I’m not ready to leave the WordPress Community

This is in reply to Ozh’s comment from my contributors shouldn’t care about recognition. I have the tendency to write a great deal in comments, but 600+ words is kind of long for a comment.

Nah, I sort of can’t now. The reason I allude to leaving the community often is that I have a history of working on a project and then leaving after I become bored with it. My history with joining the WordPress Community is the exact opposite of Mark Ghosh, in that I entered the community after many years of programming and many failed projects, therefore thought I knew more than the members of the community. I was very wrong and I apologize for my arrogance.

It doesn’t help that the project I was working before WordPress had strict guidelines with Unit Tests (test cases actually run in the unit test environment), strict everything must have inline documentation, and must have DocBook manual explaining how to use the code. It is funny that I became very bored with it on that project very quickly, but I’ve been focused on it with WordPress since after several months of complaining about it when I joined the community.

WordPress is far to interesting to just leave and I can’t exactly leave until the inline documentation is complete, which it has taken almost a full year in order to do so. I’ve had help along the way, which is great.

With the WordPress PHP extension, I’m going to have something to focus on that will keep me within the community for a long time or at least until I get bored with that project, which as fascinating as it is, I doubt it will be soon.

I’ve decided to use WordPress as the base of all of my browser game projects, so I’ll be continuing to enhance and fix bugs that I find.

Also, since I’m going to have strict test case requirements, I’m going to need to focus some more on the WordPress test case code coverage and that will take up to a year or more to complete.

I know that eventually, WordPress will no longer have something to teach me and when that happens I’ll no longer have a purpose staying in the community. Right now, WordPress has too much that I can learn and people to learn from. I could learn from other projects, but there are enough masters in WordPress that I’ll do fine here. I think I can do more being in the WordPress community than I would be able to in other project communities.

Quality assurance is still lacking within WordPress and while there are people working on the field within Automattic and in the community, there needs to be even more people. I have a few projects that I want to work on in this field for WordPress that will be totally kick ass. Unit tests, functional testing, and acceptance testing test cases are a few.

Basically:

  • Inline Documentation
  • Codex Documentation (User and Developer manuals)
  • Unit test cases (running test cases separately from WordPress execution)
  • Functional test cases (running test cases with WordPress)
  • Acceptance test cases (Selenium + PHPUnit)

Along the way BackPress is going to be engineered into WordPress and while I don’t agree with the direction it is going, I don’t know enough to help. I think it would be a great experience to learn more about Class Design Patterns and put in practice what I’ve learned in that field. When BackPress is merged into WordPress, I’ll know enough to improve upon the code.

Along the way, it should prove to be a great learning experience for Object Oriented programming. Something that I’m lacking full knowledge and experience. Even though, I’ll be developing using objects for more than two years now.

Leave now? And miss all of the great opportunities that are going to come up with learning, development, and supporting others? I think not. I think there should be enough to keep me interested in this shiny object called “WordPress”!

Possibly Related Posts:


WordPress Contributors Shouldn’t Care About Recognition

Trying to think back to the previous contributors of WordPress core and plugins, it is difficult to remember any of them. I only remember Robin, because that core developer left after I joined the WordPress community. There are many other WordPress developers that contributed a lot that are probably forgotten by those who joined after they left.

It is interesting, not all of the work that went into WordPress were by the core developers, therefore that means that many of the bugs that has increased the stability of WordPress were made by those heros without names. I suppose we can give them our respect to whoever they are. Perhaps they only fixed one bug or fixed 100 or 500 or added a grand new feature, such as the Plugin API. Those unsung heros, who gave so much only to be forgotten with time.

Thinking back, it is hard to comprehend why some members of the WordPress community left to create Habari. It would make a good story, since hardly anyone really knows why they left. They probably have good reasons and there have been many times I thought it wasn’t worth the time and effort I put into WordPress. Thankfully, no one needs me to be in the WordPress community.

I went to the WordCamp Dallas and only a few people recognized my name from the WordPress mailing list. Although, back in those days I sort of bought up many heated arguments, unintentionally of course. It is difficult to know exactly what is going to push people in argument or action.

However, I seriously doubt that after I’ve left the WordPress community people will remember my name. Sure my name is in the WordPress core and on the WordPress codex, but the significance will be lost over time as better contributors join the WordPress community and fill the open slots in the community.

Doesn’t exactly mean that more people couldn’t help in several areas. There are almost a 1000 open tickets on the WordPress Trac that needs a developer to show it some love and care. There are many areas of WordPress, both user and developer that could be written about on the WordPress codex. There are probably many other areas that I don’t know about that needs someone out there to feel compelled enough to do something about it.

However, while it is fun for the short term to have your name out in the world, it is mostly just 15 minutes of fame. That is all you’re going to get, unless you stay in the community for the long haul. Not that you shouldn’t do it, there are many people in the community I respect and will continue to respect. The drive to join the community should be to fix a problem as you see fit. Fix enough problems and you’ll gain respect. Do it long enough and maybe one or two people remember your name.

Seems good enough for me! It is nice to know that even if I left others will join and be there to fix issues I can’t or won’t fix. It is humbling.

Possibly Related Posts:


WordPress 2.7 Plugin Uninstall Methods

The “uninstall” hook runs when the user deletes a plugin that is deactivated. The implementation is basic and doesn’t allow for much in the way of what the original implementation calls for, but hey at least it exists. The point now is that you can do what you want, but WordPress won’t hold your hand while you’re doing it. It isn’t the WordPress way to do so.

Would have been nice, but I’m glad it is in. It will make the uninstall process a lot easier. Not to mention that deleting a plugin isn’t going to be so bad, since you can always use the Plugin Installer to automatically download and activate the plugin again. That should allow for more plugins to support uninstall feature.

Registering the Plugin Uninstaller

There are two ways to register the uninstaller with WordPress.

  1. Create uninstall.php at the base of your plugin folder.
  2. Register your plugin’s uninstall hook.

Uninstall.php Uninstaller Method

This is the preferred uninstall method and if the file exists, then it will be run instead of the uninstall hook. You should do some checking for either the ABSPATH or the WP_UNINSTALL_PLUGIN constants. You would be more secure, if you choose the latter of the two. The WP_UNINSTALL_PLUGIN allows for you to be even more secure or paranoid by checking the path of your plugin. Most cases, all you will need to do is just check for the existence of the constant.

Your plugin will be deleted after the uninstaller is ran should you can clean up all database tables, options, extra files, and take the time to save or delete custom files that the user made. There is no way to stop the process once it is started or that is to say, that you shouldn’t try to stop the process once it is started.

The user wants to delete your plugin and it will be a bad user experience if that person finds their plugin still accessible. Come to think of it, it is probably possible and allow for the user to still delete your plugin, but there are no internal means to do so.

if( !defined( 'ABSPATH') && !defined('WP_UNINSTALL_PLUGIN') )
    exit();

delete_option('my_option');

Register Your Plugin’s Uninstall Hook

This doesn’t work like the other plugin register functions, like activate and deactivate. Your plugin will be deactivated, so it is not going to be possible for WordPress to check for your uninstall functions if it used the same method as the other two functions. Instead it creates an option that lists your plugin and its uninstall hook.

When the plugin is deleted and there is no uninstall.php file, but the uninstall hook exists, then the plugin will be ran one last time in order to run the hook. This is not the preferred method of your plugin runs code during the inclusion of the main plugin file, like some plugins do. If that is the case, then use the uninstall.php, which is the only file that will be called when you plugin is uninstalled.

Special care then should be taken when using this method to ensure that your plugin isn’t doing anything it shouldn’t when uninstalling. Your hook will be called and then your plugin will be deleted.

An example might be:

register_uninstall_hook(__FILE__, 'my_uninstall_hook');

function my_uninstall_hook()
{
    delete_option('my_option');
}

As opposed to the other method using a checkbox or just automatically uninstalling on deactivate, I think this is a far better way of knowing when to clean up after your plugin.

You can provide backwards compatibility, but using function_exists() function before calling register_uninstall_hook().

if ( function_exists('register_uninstall_hook') )
    register_uninstall_hook(__FILE__, 'my_uninstall_hook');

function my_uninstall_hook()
{
    delete_option('my_option');
}

Possibly Related Posts:


Experimental HTTP API

The HTTP API was written so that problems with fsockopen being disabled or fopen not working wouldn’t hinder fetching URI resources. It is also an attempt to replace Snoopy and standardize the internal HTTP requests.

There are currently five methods implemented for retrieving URI resources using the http or https (if available) protocols. The fsockopen is not used, except for the last fallback, if all of the others don’t work. The fopen() PHP function is used with two methods, one uses streams if PHP5+ is used and the other does not. That counts as two, in case you were not wondering or something. The other use the cURL and HTTP extensions, if they are available.

Basically, if you don’t have either the HTTP or cURL extensions installed and allow_url_fopen is disabled and fsockopen is part of disabled functions, then you are pretty screwed and WordPress can’t help you. You should probably try to find a better host.

Hopefully, the support questions about fsockopen being disabled and not being able to connect to the cron should go down. Well, that is when the HTTP API is stable in the next few months when it is fully tested and all of the minor issues are corrected.

Possibly Related Posts:


WordPress Trac Versions

The current WordPress Trac has versions 2.7, 2.8, and 2.9 milestones. Version 2.7 is the current trunk or current version. Version 2.8 will hold the tickets for what will be completed for 2.8. The 2.9 milestone currently holds all of the tickets that will try to be completed in a later date.

The plan at least is to move tickets from 2.9, when 2.7 is released, to 2.8 that the core team wants to release in that version. I’m guessing that next year will see the release of 2.9, 2.10, and probably 2.11. It will be somewhat difficult to get past that 2.9 doesn’t mean 2.9, but 2.09, so that is kind of messed up, but have to wait until next year to find out if that will be the case.

Who knows work might start on Version 3.0 with emphasis on BackPress.

Possibly Related Posts:


Translate Plugin Headers in WordPress 2.7

Improvements that just hit the trunk today allow you to add the plugin headers to the .POT file. There are a few ways of getting the plugin headers into the .pot file, where if it is translated will be displayed in the plugin administration in that language. There are two online tools that will pull the plugin header data out and put it into the .pot file.

The first one is part of Automattic i18n Tools and the second is either part of or will be part of the new Plugin Extend Administration interface online translate tool for your plugins to create a .POT file.

New Plugin Headers

The two new plugin headers for allowing translating the plugin header is “Text Domain” and “Domain Path”. The only one that is required is the “Text Domain”, which is the same as text domain that you have in your plugin.

  1. Text Domain – Unique name to identify your plugin from others.

    < ?php
    /*
    Text Domain: mydomain
    */
    
  2. Domain Path – Optional and only needed if the .mo files are stored in a separate file relative to your base plugin directory. If the directory is located relative to wp-content at plugins/my-plugin/lang_folder, then the “Domain Path” would just be lang_folder.

    < ?php
    /*
    Domain Path: lang_folder
    */
    

PHP Hack to Get Plugin Headers in the .POT File

There is a more hackish way that doesn’t rely on the above two to get the plugin headers in to the .POT file.

/*
Plugin Name: Name Of The Plugin
Plugin URI: http://URI_Of_Page_Describing_Plugin_and_Updates
Description: A brief description of the plugin.
Version: The plugin's Version Number, e.g.: 1.0
Author: Name Of The Plugin Author
Author URI: http://URI_Of_The_Plugin_Author
Text Domain: mydomain
Domain Path: lang_folder
 */

$plugin_header_translate = array(
    __('A brief description of the plugin.', 'mydomain'),
    __('Name Of The Plugin Author', 'mydomain'),
    __('http://URI_Of_The_Plugin_Author', 'mydomain'),
    __('Name Of The Plugin', 'mydomain')
);

A warning about offering the plugin name to be translated, if you do so, then it is possible that the automatic plugin updater will not recognize your plugin and therefore will probably not check for updates.

Translating the name and other parts will have no negative effects on the plugin updater. This was fixed in revision r8368. No word yet on if this will be in 2.6.1, but I’m crossing my fingers. Well, WordPress 2.7 should be out September-ish and 2.6.1 should be out towards the beginning of next month.

Possibly Related Posts: