Category Archives: Web Applications

WordPress Plugin and Theme Scope

Posted by Jacob Santos on June 27, 2009 Comments Off

If you are unaware, in many cases the files of your plugin and theme will be run in function scope. If you are expecting that your code is being included in the global scope and your code works that way, then you’ll be caught with a surprise when bug reports creep up about the plugin not working correctly. The problem will persist as the WordPress versions continue to “encapsulate” the plugin and theme code.

The best way to get around it is to always use functions and have all of your code loaded that way. This shouldn’t be a major problem with themes, since the WordPress environment is included in with the functions (not always for plugins when activating). Most themes shouldn’t rely on the non-WordPress globals. I fear that more WordPress theme frameworks will and the problem might be found in those so called frameworks as well.

Possibly Related Posts:


What I’ve Learned From WordPress

Posted by Jacob Santos on March 29, 2009 Comments Off

The experience with working with WordPress the past year and a half has been educating. While the solutions found in WordPress aren’t exactly perfect, I’m finding that verses others a lot of what WordPress does, is what I wish other web projects would do. I’m also finding that I develop more per the techniques that WordPress uses for themes.

Plugins

On the topic of plugins, if I had not worked with WordPress, then I would never have seen it as filters and actions. My solution would have been to use the Adapter Class Pattern for replacing functionality. The problem is how to handle allowing multiple implementations and the Adapter pattern does not handle those well. Could use the Observer pattern, which is more or less what WordPress uses.

The solution in WordPress is not tied to any one class, uses an unified API, and is extremely easy to work with. That I think is what allows WordPress to be as simple and easy as it is. Sometimes, adding content, replacing content, and extending, doesn’t or shouldn’t involve editing source code, but hooking into a filter or action. It is not required to know how it works, just that if you use this hook that you can manipulate the feature to your requirements.

With the Adapter Pattern, you have to know specifically what it is you are replacing, and how your replacement will work with the code. It works well the use cases where the implementation you are handling isn’t as simple as filtering content or specifying an action. The advantage is that, you can use the same API within the code to do something else. So a multiple step process would be great for the Adapter pattern.

Themes

For themes, what I’ve learned from WordPress is that it is not enough to provide data and handle it, but to also provide the API for handling that data. It is easier and a lot more faster for the developer who doesn’t think or realize that other non-developers may need to make changes to the theme to handle the data directly. The problem stems from those who do not know the PHP syntax and what problems arise when you screw up that syntax. I think that is why Smarty is used for some templating systems. If you screw up Smarty, you are not going to bring down that page, it just won’t display correctly.

I’m not saying that Smarty is better than straight PHP, just that Smarty has its purpose. You can make PHP just as fool-proof as Smarty, if it is done correctly. I suppose, the issue is still one of education. I create iterators with my data, and also methods for handling that data. The work flow is not simple for others and I have to supply documentation for how to use the iterators and methods. I believe that once people know what they can do with the iterators that they find it is easy to work with. Looking at the code, is another matter and you really need to know what you are doing in order to modify it.

Beautiful code is not in the implementation but the use, you are abstracting away difficultly from the user and sometimes the implementation is going to be seriously ugly and there is no way to make it beautiful. The best that can be done is making sure the user doesn’t have any problems in understanding how it can be used.

Developing Solutions

It is always my goal to strive to develop the best solution, no matter what, but given my limitations, I think the best I can give is one that is working. That I think is important regardless of the solution. I think developers get caught up on how well the solution functions verses that it is even working. It is not to say that improper or poorly developed solutions shouldn’t be criticized, because eventually, the solution is going to have to maintained.

The better the solution is developed, the easier the solution will be to maintain, extend, test, and refactor. That has always been my goal. The problem is that when you work with new patterns, data structures, and APIs, the solutions don’t always work out that way.

Roles and Capabilities

The point with WordPress is that, it has shown me solutions that don’t work that well. The Roles and Capabilities API and data structures work within the WordPress application, it is just not something you want to duplicate elsewhere. What is great about the Roles and Capabilities implementation, is how the API works and what data it contains. There are probably three or four core ways to develop Roles and Capabilities in web applications. Well, there are many more; anybody who developed any PHP application will have their own, it is just that they’ll fall in line with the general other solutions.

What I like about the WordPress solution is that you aren’t using levels, which if you’ve ever developed a solution using them, you’ll soon find that it is very limiting. You aren’t using the sort of CRUD permissions that phpBB and Zend Framework uses. I’m not saying that the solution found in phpBB and Zend Framework are bad, it is just that for most simple applications, you are more concern with simply if they have the capability to do something and not whether they can browse, but not delete, or read, but not browse.

That is not to say that certain aspects of the WordPress roles and capabilities doesn’t fall into that model, because certainly parts do. It is that not enough of it does and that you can still implement the CRUD way using the WordPress implementation. The difference is that instead of having one row, you will have, at most, four or five. Not that it makes any difference, because your concern will be for one or at most two of them and not all of them.

Also, it is difficult for me at least to visualize how every capability would even need most of the permissions. If I just need the capability for reading, why am I needing to tell whether they can delete, there is nothing to delete anyway. I believe those work that way, because in administration, you are going to be implementing the majority of the permissions anyway. Administration, yes, normal web applications you don’t, where you still need to be able to tell someone can to do something, but not whether they can delete, read, browse, edit, etc. In this instance, the way WordPress does it works very well.

You can work both ways into any application, it is just that the way WordPress does it, is easier to visualize, easier to implement, and a lot easier to check against. It is the way the roles and capabilities are stored in WordPress that I don’t agree with and well, it is something else in developing a table structure, because there are many ways to implement that as well.

If I had not seen the way WordPress developed their solution for roles and capabilities, I would probably continue to either use levels (where I needed a simple, quick hack). If I needed something more complex the way Zend Framework and phpBB solves it.

Interfaces

I’m used to torturing myself when developing user interfaces. What I’ve learned from WordPress is that it isn’t a good idea to do so for your users. They want simple, easy and less steps. What we are fine with doing as developers of our own work, users only concern is just getting stuff done.

I think I’m taking that more to heart as I use more JavaScript (jQuery, etc) to develop user interfaces. I’ve found that you can go overboard and interfaces should still be developed for those who don’t have JavaScript enabled. It is easier to work with JavaScript to give the interactivity of Flash for web sites, but all the features of HTML with regards to search engine support and mobile browsers.

Well, the study of User Interfaces is a whole another topic on to itself. There are jobs out there just for those who develop user interfaces and research and develop them. For me as a developer, it will continue to be something I research and study, but will never be my primary focus. I’m hoping to meet someone who can do that for me, eventually, or if the projects I work on start making a profit, I can hire someone to do it for me.

Installing

I used to take installing for granted. I’m not saying that I included them in all of my projects, because I don’t. It is just that I was used to modifying configurations manually and setting up the tables and what not manually as well. Most of the projects I’ve used have always had a manual installation process.

I don’t think that is as useful any more, because the best web applications out there, have automatic installation process for which you can configure when you setup and it will do everything to get the web application functioning for you.

For me, after seeing the many installation processes that exist, I don’t think I’ll ever develop an open source project that forced you into running SQL to create the table structures yourself. It isn’t too difficult to implement something that does it for the user. Well, to be honest, the previous projects I’ve developed, the installation has always taken a backseat, because I didn’t need it and given the time I had to work on the project, it just never got to the point where I could devote time to it.

I’m going to change that. It doesn’t have to be difficult, nor does it have to hold your hand completely. Therefore, I’ve done it easily before. It was just a page you went to, that would do a few things to setup the application so that it was ready to run. It didn’t take that long and while it isn’t the best implementation, it works.

Conclusion

I think this is mainly why I’m not going to be developing patches for WordPress any more. I need to spread my wings and take flight and make my own mistakes. Working and fixing the problems within WordPress has been fun and a learning experience. I need to make my own mistakes and hopefully someone will come along and show me a better solution.

That is not to say that I won’t go back to WordPress in the future, because I plan on it. I plan on taking what I’ve learned in my future open source projects and applying them back to WordPress. Hell, given the time it is going to take to finish the PBBG projects I have in store for myself, I think by the time I go back to writing WordPress patches, other problems and solutions will have found their way into WordPress.

So I’ll like to thank the WordPress community for helping me and not kicking my ass when I was too harsh.

Possibly Related Posts:


Why Do I Feel Like an Asshole When Criticizing WordPress?

Posted by Jacob Santos on February 26, 2009 4 comments

I always feel like I’m somehow betraying the WordPress community every time I speak the truth. The issue is that, when Matt speaks or any of the core developers, it is all happy joy, no problems here. It limits my credibility greatly to come back and say, “Well, no, it has this problem and this problem.” Who are people going to believe? The guy(s) who actually has access to the source code or some guy no one knows or cares about?

I’ll give you a second or two to guess.

EDIT: In summary, I’ll be happy if this was on the front page of trac, albeit without the sarcasm and cursing, of course: “Warning: If your patch for a ticket has not been addressed after a week, then join IRC and talk to Peter (westi) or Ryan (rboren). Then like, shit, it will be committed within a day or two (psst, if you catch them at the right time, within several minutes). So not fret, because WordPress developers do care, they just need to know that your patch exists. No guarantee they won’t reject your patch.”

I think for me, my biggest problem is that the issues aren’t being addressed that I talk about and I’m thinking more and more about developing a new alternative. Not just a library which WordPress can use, but an whole another application that works off of WordPress tables. The issue is again, not that the library wouldn’t be developed in any short amount of time, but developing of a whole application, oh god, I can’t imagine that.

It won’t fix the issues I have with Trac and writing patches for the core of WordPress. You see, I don’t write many plugins (nor do I really maintain the plugins I have written) or themes, so I have no visible presence in the community. Therefore, the question I have to ask myself is who am I speaking to? If I’m speaking to the other contributors, then they already know the pains and hurdles, because they’ve lived it. If I’m speaking to the entire community, then they really don’t care, nor do they know who I am exactly.

Who am I, a nobody, to question the Great One and point out the flaws. I think I’m shouting into the wind. The problems I’ve put forward are being ignored by those capable of doing anything about it.

The main problem I have always had was that I don’t think I should have to complain to the core developers that I have a patch which needs to be committed. Then again, I’m happy when they get around to committing the patch. So on one hand, I don’t want to alienate the core developers and have them ignore my patches intentional (which would be a WTF?) and on the other hand I don’t want others who don’t want to deal with bullshit when submitting patches and won’t go the extra mile to get their patch committed.

I still remember my first patch, which was a huge WTF? one for TDWTF. I don’t think it should take three weeks to get a patch into the core. Actually, the only real reason it did get into core was by working with a few other community members and testing the patch and jumping on the core developers back to get it committed. I totally expected that I would submit the patch, some guy would test it and then it would be committed. Nope. You have to jump through hoops to get patches for a lot of the lesser known or lesser issues committed.

I think that is one of my main concerns. Even 18 months and coming on to 2 years, I’m still facing a lot of the same problems. I’ve learned that, if you want to get patches committed, you have to keep on it. However, how many are really going to do that. I don’t want to be an activist for patches. It is hard enough to keep track of all of the patches I’ve created and complain to have them reviewed and committed. Having to go through and find other patches that should be committed. Hell, that shouldn’t be my job.

It is also hard work. Doing something like that would be a full time job. Now, it is that way, because not only do I have to apply the patch, test it, and then fix any issues with the patch, but then the core developer has to look at it, apply the patch, test it, and then commit the patch. It is not an easy process. One of the reasons Trunk is relatively stable 99% of the time. The process is repeated.

I’ve called Matt Mullenweg to task to get more core developers to just do this. That is all they will do, test and commit patches by developers. I think that it is probably a temporary position, it would take a few months tops to finish all of the tickets that have patches that weren’t committed and clean up patches that aren’t worthy of being committed so that they can be.

I don’t think contributing to a project should be one big WTF? after WTF? and I think as my work moves past WordPress as a platform, my involvement will decline to the point where it will disappear altogether. Then again, I use WordPress and it works fine for me.

I’m starting to think past WordPress to Yii and how I can use it. My project task list is being fragmented with browser game projects on one hand and wish list projects on the other. The browser game projects are what I would call, higher priority. I do think I’ll attempt the Yii Blog platform based on the WordPress table structure and code base.

I like the fact that using Yii will decrease the amount of the code base that will need to be maintained. I will most likely be contributing to the Yii code base to patch issues and add additional features as I see them. I think that I’ll be out of the WordPress scene for the next few months, the question is whether I’ll come back. If I can create the Yii clone of WordPress, I don’t think I will because I’ll be spending most of my time working and improving that code base as well as the browser game projects.

If I do leave the WordPress community, then I think the run was an highly educational one, better than I could have received at any school. I learned a lot that I couldn’t exactly focus on while developing code bases and always wanted to. I’ll appreciate the education in documentation and writing test cases. However, I’ve learned what I needed to where I now focus completely on inline documentation and writing test cases while I’m writing code. I no longer have the mind set, “I should do this, but it can be done later.” I now think, “Okay, now for inline documentation and writing the test cases to ensure that the code works.”

I’m writing test cases and inline documentation as I write code and not after. I would be doing so more for WordPress, if the process wasn’t such a WTF? to get test cases committed in the Automattic WordPress Tests repository.

I fear, I will not remember WordPress fondly. I just hope the next generation that join the community will have better experiences than I had. Well, there are those who work on higher priority tickets that have no problem getting patches committed. Then again, those have issues too. (Not to mention the whole WTF? in 2005 and 2006 when Matt and other core developers mentioned that there would be no way in hell inline documentations would be part of core. Good thing their minds were changed on that.)

I make this pledge, if I have a project that has as much support as WordPress, I’ll be damn sure to commit as many patches as I can. If it is impossible for me to do so in any given day or week, then I’ll try to get more people working on the project and give commit access to those who are contributing. Another thing I’ve learned from WordPress is that bullshit should not be uttered when talking about contributing to a project.

Possibly Related Posts:


PHP5 Straw Man Argument

Posted by Jacob Santos on January 19, 2009 Comments Off

Perhaps I’m wrong with this, I don’t want to have my foot in my mouth, so I’m not going to mention very many people by name. Except for Matt Mullenweg, just wanted to plug his new domain for reasons I’m not entirely sure of. Well, or it could have been that I started this off, in an attempt so that you’ll be baited to believe my lies, sort of how Al Franken works with his books.

The argument basically with why WordPress doesn’t transition over to PHP5 has two parts, or two main parts. The first is that users won’t benefit by any way from the transition. The second is that PHP5 offers nothing that can’t already be done in PHP4. These two are true, but I’ll counter them anyway.

The point with programming standards and languages is never about users, only the end result is. End users don’t give a rat’s ass what language the product is as long as it fulfills their needs. Quite selfish of them really, wonder why they matter in the first place. Ah yes, they pay the bills, so I suppose it is a good idea to kiss the ground they walk on then. If users don’t care about what programming language is used, then who does? I wonder.

Could it be programmers? Nah, if that was the case, then the argument wouldn’t have any relevance. It is funny, because the people shouting and arguing about transitioning over to PHP5 are not users, but developers using WordPress.

See the issue with the statement is that the argument actually is relevant, because users and their needs runs the direction of the project. If the users wanted WordPress to wash your feet, while giving you head, then by damn it will be done! It might take forever and cost an exorbitant amount of money for the end product. As I said before, users of WordPress don’t care about the language, if it was written in Python, then people will be looking for hosting that offered Python in order to use WordPress.

To say the least, the reason, which bears the most importance in the discussion is that there is still a large minority of users still using PHP4. With most hosts, they’ll be able to upgrade with either a click of a button or at least a directive in their configuration. No, they won’t benefit at all, but that leads to the second part to emphasis the straw man more.

“There is nothing that PHP5 offers that can’t be done in PHP4.”

This is true. It is completely possible to offer WXR support in WordPress, however the regular expressions does amount for a fair quality of bugs and WTF?s when other people don’t follow the format set by WordPress correctly. If something like SimpleXML and, or DOM was, were used, then there wouldn’t be an issue and the iteration might even be faster. The point still stands that a great deal of XML features would be tricky or require a whole lot of additional work to support both PHP4 XMLDOM and PHP5 DOM extensions.

The other problem is providing automatic Daylight Savings transitions, where you don’t have to set the time manually. This is easily solved with PHP5 DateTime classes and functions, but not everyone has the non-standard PECL extension to allow it in PHP4. Actually, shared hosts don’t have it at all. Well, at least one feature that could be provided, if WordPress required PHP5 and dropped PHP4 support.

Well, besides the XML stuff, the DateTime seems to be the only known issue that can’t be easily solved without moving to PHP5. That is, I’m writing a library, which is for WordPress, that is completely OOP, so we’ll see just how well it holds up with the ease of use of the current WordPress API.

I believe that as developers push the limits with WordPress, more and more reports will come in that basically say, “Well, if WordPress supported PHP5, this would be incredibility easy.” Well, I think that is sort of the issue with the statement. Sure, the daylight savings issue could be solved in PHP4, you could connect to the timeserver for the timezone and get the time based on that server and update the time for the user. That is quite convoluted solution. I think using regex to parse XML is also convoluted. Better solutions exist in PHP5 and as the development of PHP4 has stopped, continuing support for it becomes an issue.

No new code should be written for PHP4

Truth is, no new code should be written for PHP4, because that version has reached the end-of-life and no new versions will be made for it. That said, projects like plugins, themes, and independent projects using WordPress should all be written using PHP5. It has almost been a year since PHP4 has end-of-life, and 6 months since they’ve released any patches.

I think that version 3.0 of WordPress will be PHP5 only. Why? Matt Mullenweg has recanted what he said in his PHP5 post made quite a while ago. PHP5 is faster, more stable, and quite frankly better than PHP4, so it makes sense that he would do so. As project dictator, it is really up to him when the project moves over to PHP5+ only and drops support for PHP4.

Possibly Related Posts:


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:


Web Application Versioning Alpha Release

Posted by Jacob Santos on October 4, 2008 Comments Off

I released version 0.1 of the PHP web application versioning web application. The first release is rough around the edges and needs to be modified in a few places. I do think it has always been a good start and also has been very useful for what I needed it to do. However, as I move forward I want to position it for other projects besides WordPress and it needs to be polished. Also, since it is open to the world, it needs some better quality controls attached to it, so I don’t cringe whenever my name is associated with it.

What it is Lacking?

It is lacking inline documentation, test cases, solid installation script, decoupling of WordPress, support for more than uploading zip files, and a bunch of other requests. I’m going to work on the quality assurance parts first while decoupling support for WordPress.

The issue currently is that I really only support SQLite, but I’m going to finish support for MySQL also. This should hopefully ease up on the time it takes to search and load the pages.

Version 0.2 Features

I think these central features need to be addressed for the version 0.2 tag and release.

  1. AJAX searching.

    Version 0.2 will work on AJAX searching instead of displaying all of the functions. I’ve found that it takes an long time to load pages and what I really need is to just search for the elements I want the version info for.

  2. Better installation script.

    The current installation script is extremely basic and doesn’t allow for any configurations. The goal for supporting both SQLite and MySQL is to allow for creating the needed components for getting them to work. SQLite needs its own directory to hold the database file and this directory needs protection against people downloading the file. Well, it isn’t that important to protect, but no one should be accessing the directory anyway.

  3. Extensible library architecture.

    I want to use some patterns, which will hopefully enable extending the functionality later in the development. This also includes reworking the directory structure. The web application shouldn’t be that difficult or that much to it, but it should allow for ease of extending later also. It probably will change later when everything is worked out and better packaging of the script needs to be done.

  4. MySQL support.

    I know MySQL better and can optimize the code for it. I’ve found that I’ve learned how to optimize the table structures for SQLite better to where they aren’t as slow. However, I believe that MySQL support should probably give some users a boost over SQLite for some large databases. It may extend the period for which development and testing is needed to complete this feature. If I can’t finish it, then really I’m going to focus on the other features first.

  5. Versioning look up support.

    In version 0.1, there is only one way to look up the versioning information for the web application and that is uploading a zip file. You have to do it every time and it does get to be a pain after some time. I want to extend support to accessing the already uploaded files instead of having to reupload them every time. I also want to support traversing directories and getting the versioning information from those files.

  6. Quality Assurance

    There isn’t currently any quality assurance in the web application and I really need to change that. Right now the script isn’t that complicated or large, but going forward, I don’t want to be hypocritical with writing a script meant for finding the information for the @since phpdoc tags. It looks bad to write a script for helping those that write inline documentation and neglect inline documentation. I’m also going to work on unit tests for various parts of the library. It will help in reducing the amount of bugs. I doubt I’ll finish the test cases in this version, but over the course, I’m going to work on it more. I’m not going to release the final version until all of the unit tests are written.

Purpose

The web application versioning purpose is to record the various elements in PHP that can be documented. Mainly functions, classes, class attributes, methods, constants, and limited global variable support (must be declared in a function as global). For web applications that neglect @since tag information, this web application will be helpful in finding that information. Since it was built for WordPress, it also supports filter and action API version information.

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:


Unit Tests Work! A Look at WordPress

Posted by santosj on August 25, 2008 Comments Off

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

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: