Tag Archives: wordpress 2.7

WordPress 2.7 Changes Class for Plugins

Posted by Jacob Santos on November 20, 2008 Comments Off

Plugins that use the “wide” class for their plugins will find that some of their tables will not be shown. The fix is pretty simple. Change to using “widefat” instead and the change will make the table look really cool looking.

To note, the WordPress Trac ticket for Removed horizontal bar killed plugins under small resolutions describes the problem further. And yes, I am an asshole.

Possibly Related Posts:


WordPress Theme Modifications should be made in Child Themes

Posted by Jacob Santos on September 29, 2008 4 comments

In WordPress 2.7, you will be able to update themes from in WordPress, as well as plugins. This is going to complicate those who have made modifications to the theme. Any modifications, currently, are going to be overwritten. That is to say that changes may be made in the future that will allow you to keep those changes. My point is only that if you are going to be modifying a theme, you should create a child theme instead and create the change there.

All you need is the style.css with the Template: Parent-Theme-Name at the top in the CSS comment. You then can create files with the same name as the parent theme. Some custom files created for inclusion will not work this way, unless the parent theme specifically coded to work with child themes as well. Regardless, you can copy over from the parent theme and create the changes there. If you are only changes a file or two, then it will work out great.

You will be able to upgrade the parent theme, gain the fixes and changes there and still contain your changes. Eventually, the DIFF support will find its way into the upgrade process of themes, but I still think the heavy lifting would be better placed on child themes than depending on the diff support.

Possibly Related Posts:


Don’t Use WordPress 2.7 Trunk on a Live Blog

Posted by Jacob Santos on August 31, 2008 4 comments

There are reports of a few people who are running the latest trunk of WordPress on a live blog and that is a really bad idea. The merge of Crazyhorse is still being stabilized and there are quite a few areas that I’ve tested, on a dev site, that are currently broken.

I believe that the level of stability of the Crazyhorse merge is increasing and I expect I’ll be able to SVN Up to the latest revision. I’ve been keeping a watch on the trouble areas, but haven’t been reporting issues until it is stable.

I think one of the issues is that the new “Inbox” includes test data, that I really don’t want to have on my blog. Yeah, I can delete it, but I don’t know what it is for currently, and I don’t want test data on my live blog. Hopefully, for those who have updated, it will be removed, but I suspect that including that in the upgrade process might not make much sense.

That said, from what I’ve seen, it is looking better. I’m impressed with the features and increased usability of the new version. When everything works and it should before WordPress 2.7 is released, I think many people will be happy. If not a little bit upset with yet another major interface change, since WordPress 2.5. People will eventually find that the new interface is a lot easier and better.

You can already change the Administration Panels, if you don’t like the changes.

Who am I to suggest this? Well, you can do what you want. Just be sure you don’t get mad when it hits the fan and I strongly suggest you test WordPress locally. When I say, “Test” I don’t mean you just write a single post and see if that works. I mean you go through every page, hit every button, input every field (that you want to know working), everything! to see that it works. If it does, then let me know.

Possibly Related Posts:


More Inline Documentation Completed

Posted by Jacob Santos on August 30, 2008 Comments Off

A lot of inline documentation has gone into WordPress 2.7 today. The file script-loader.php has been completed and is one of the more easy files to complete. The file formatting.php is also completed, but is awaiting commit to the WordPress Trunk. Thanks to Scott Houston for helping with the formatting.php file, documenting over 90% of the file.

Now that post.php, functions.php, and now formatting.php are finished, that remains are only 14 files. There are 5 files that deal with “template tags” that have mostly short function bodies that will really easy and quick to document. There are still three “easy” files that need to be documented. There are at least two files that I’m not even going to touch until the end.

I hope to complete more of the template files, so that theme developers can reference that documentation. Hopefully, the idea for adding phpDocumentor or PHPXref site to wordpress.org subdomain will go through before WordPress 2.7 is out, so that people can reference it. It would be better to reference a wordpress.org site for on the Codex and other sites, because you can be sure that it will be up.

It looks like my personal goal of having the inline documentation finished might just come to pass. There should be enough time to complete the inline documentation by October / November release date (historically, WordPress developers try to release a month early).

Possibly Related Posts:


Finish All Inline Documentation for WordPress 2.7

Posted by Jacob Santos on August 27, 2008 Comments Off

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:


WordPress Core Updating Kind of Works

Posted by Jacob Santos on August 24, 2008 Comments Off

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 2.7 Plugin Uninstall Methods

Posted by Jacob Santos on August 7, 2008 10 comments

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

Posted by Jacob Santos on August 3, 2008 Comments Off

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:


Translate Plugin Headers in WordPress 2.7

Posted by Jacob Santos on July 17, 2008 2 comments

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:


WordPress 2.6 and Personal Projects

Posted by Jacob Santos on April 7, 2008 Comments Off

It is nice that WordPress 2.6 is not due until August. I was thinking that I would only have a single month for my pet projects, but I’ll have more than two and a half months to finish what I need. I believe with that amount of time, I can polish the patches I made in January and provide better arguments for inclusion into core.

Inline Documentation

Also, the biggest project will be finishing up the inline documentation for WordPress wp-includes folder and the wp-admin/includes folder. There might be functions in other places, as well as adding file level phpdoc documentation to files, but those won’t take very much time. Going forward, I believe it will make sense to document everything else that remains in 2.6, so that developers understand that each new function needs to be documented before it is committed.

Already several core commit team members are adding phpdoc inline documentation to new functions. However, not every core team member is doing so. I believe it will be easier for the community to provide patches for these mistakes, but not everyone is going to care and if care is not taken then a similar problem in earlier versions will appear in later versions.

I don’t want to see, two years from now, many functions which aren’t documented.

I’m thinking I can finish the inline documentation before June, but I would have to work every day, plus weekends to complete everything. It usually takes about 16 hours to document the bigger files, like functions.php, etc, and 8 hours for some of the smaller files. I’m not sure how much time I’ll devote or when I’ll start, but it is something that only has 20 more files to complete in the wp-includes folder, which is the most important to complete. So it would take around 10 days, if I worked 24 hours nonstop, which I’m not going to do. Well, I’m going to have to try for the second week of June for completion. For the wp-admin/includes folder, I’ll have to add another two or three weeks.

I probably won’t be finished with this project until July.

Writing Test Cases

This isn’t part of the WordPress repository, but it does go with it. I’ve stated before that my intentions were always to complete the inline documentation for WordPress and then move on to help write the test cases for WordPress.

The neat thing about writing test cases is that eventually, you’ll come across a bug and will have to write a patch for that bug, or at least seek out bugs that currently exist and write test cases which test whether or not that defect is accurate or not and provide a patch for it.

The goal of this mission, is to clear out most of the defects in Trac and try to make either WordPress 2.6 the most stable it can be, or at least WordPress 2.7 the most stable. It just depends on how long writing the inline documentation will take. Most likely, I’ll only have less than a month to start writing test cases and get patches in, which will put the WordPress 2.6 release somewhere in the beta and RC release stages. Not a good time to start, so at least WordPress 2.7 will get the most patches from the work.

The goal is to write as many test cases as needed for as many functions as possible and writing patches when needed.

Another possible goal is to write test cases for the enhancements, as to whether my patches actually succeed in adding the enhancement. The goal then, will be to get the Trac tickets to less than a hundred with it primarily consisting of enhancements and tasks. However, this is optimist, but really the community as a whole will provide the majority of patches.

The secondary goal is to reduce the overall amount of Trac tickets.

Google Summer of Code

You know, I would really like to be accepted into this program, but I’ll have to finish as many files with inline documentation before I start and it will probably throw off my above timeline. If I’m accepted, I’m going to spend the majority of my time working on whichever project I’m accepted for.

This really means that I’m probably only going to work on the phpdoc on the weekends, but for only a few hours, so it will slow down my timeline for inline documentation, but I still hope to have all of the files in wp-includes finished before WordPress 2.6 is completed. If I’m accepted it will also look like I won’t even get started with writing test cases until the Fall, which will give me a lot of time to devote to writing test cases for both WordPress 2.7 and up towards 2.8.

OTC Spring Semester 2009

If I’m graduating this Spring, then I’ll be going back to school next Spring to start my Internet Application Development degree. I do not plan to be active in the WordPress community at that point. I might come back to write test cases and inline documentation when needed, but if my above projects are completed, then I don’t think there will be a need me any longer.

Therefore, I’m thinking ahead to creating a photo gallery application or joining Zen Gallery project. I also look forward to fixing Mecha Asylum and rejoining the Asylum Futura project and releasing Mecha Asylum as a branch to that project. There are a couple of other game projects that I hope to work on during the school year (which really shouldn’t be difficult, since I’ll already have my core classes finished and would only need to complete the degree classes.

I’m probably looking at three semesters, depending on whether I go for full time or part time. However, I’ll be paying for everything, so I’m pretty sure I’ll only be taking a few classes at a time to not break the bank.

Regardless, I do think I’ll join the WordPress community again in the future, but it probably won’t be until I have gained progress on my other projects, like DragonU.net, AbsidonGames.com (which I want to be able to have repositories for, with Trac and eventually continuous integration), SantosJ.name (not just a blog anymore), and the browser game projects. Well, besides the browser game projects, which take about a three months to develop, the other projects could be worked on and completed throughout the 2008 year.

2008/2009 Plans for Sites

Mostly with DragonU.net and AbsidonGames.com, I want to switch them over to WordPress as the CMS and use it for the pages and designs. That way, I don’t have to write a custom administration panel for the sites and will have everything I need to allow other people to manage the site along side with me. I’ll also be able to write plugins for the rest of the authors and modify the themes. I’m probably going to use my current theme that I bought a few years ago for several months. After that, I’m going to buy a new theme or try to get a new custom theme for both sites.

AbsidonGames.com is a bigger project in that it will require adding Trac support and probably a plugin which allows for adding members of the blog to the Trac and Game Repository System. So everything will be managed by WordPress and who has access to what. It can be done in stages, which it probably will anyway, but I want all of the game sites on my hosting server to use Subversion and not FTP. However, to do so, I need to be able to allow new users to sign in and register automatically.

AbsidonGames.com will provide the news network, so that someone would only need to go to AbsidonGames.com to see what is being developed. Also, the games will grab the RSS feeds for their news section, completely replacing the need to have a news administration panel in the games. There will probably be one anyway, but probably not for adding news, but managing which feeds are added, as well as which news items are shown.

SantosJ.name just needs a photo gallery, my resume (probably just link to linkin along with a printable site version), as well as a picture of myself. I’ll probably also go through all of the articles I’ve written and either expand upon them to create something bigger or tag them. I’ll probably want to extend the Browser Game Development articles I started to write, since they get a lot of traffic.

I keep saying that I’m going to improve these sites, but never seem to get around to doing so. I think also for Absidon Games and DragonU, that the biggest time waster, was the custom CMS that I built. I think going to WordPress will save a lot of time and allow me to focus on just the content and additional features, instead of working from the ground up.

Possibly Related Posts: