Posts Tagged ‘wordpress’

« Older Entries
Newer Entries »

CorePress Repository on Google Code

Wednesday, January 14th, 2009

The New-BSD WordPress Library I’m writing is now on Google Code, and I have a name for it, called CorePress. The name is tentative, because it matches too closely with the other -Presses, I want a new name for it, but that will probably come later. Right now the code name for it is CorePress. If I get enough completed to where I can release 0.5 version, then I’ll think about changing the name again.

I’ve been working pretty much about four hours a day on the library, unit tests, and documentation. I think the good news is that if I do the inline documentation correctly, then I can output the phpdoc docblocks in DocBook format and then edit the XML from there. The goal is to provide a detailed guide on how to use the library. I suppose I can also use the unit tests as examples as well, depending on how involved the examples are. I’ll also need to write a working plugin and theme for the developer guide on how to use the library.

I don’t suppose I’ll be finished for another month or two. The DB portions are coming along nicely. However, they are hardly complete. That said, I don’t suppose I’ll have everything working in version 0.1. There will be a lot of missing pieces and a lot of patch work as I find what the best way to design the library is. I envision rewriting sections that were poorly thought out. I think it would be good. Something that couldn’t be done with the official library shouldn’t really hinder me with the development of the library. The reason is that, for one, the library is alpha, so nothing is tied down as of yet, and two, not that many people use it, well at this point, no one uses it, so I don’t have to worry about an user base getting upset about API changes.

I have plans for each alpha version leading up to the stable release. This isn’t an exact milestone per say and subject to change. I think I’m going to continue develop as much as possible until the end of this month. I may not release 0.1 (I will tag it when I get to that point), but not create a release. Creating a release to me is providing a PHP 5.2 version. The more classes and code I write the longer it will take for each release to backport the library to PHP 5.2.x. It will be good practice at this the end of this month to do so.

It is actually a lot of fun, because I get to play with PHP 5.3, which is still in alpha. I also get to do a lot of experimental classes and put together a fluid interface pattern library. I also get to look at the adapter pattern some more. I’m going to explore the controller pattern in the library, because there are already so many libraries which do that already.

Possibly Related Posts:


Tags: ,
Posted in Programming, Projects | 1 Comment »

Writing WordPress New-BSD Library

Sunday, January 11th, 2009

I think after all of the complaining about how WordPress is GPL and all themes and plugins that use the WordPress library is GPL, I think a solution would be to write a library that everyone can use GPL free. The library will have a clause, which will say that all commercial entities using the library will be required to pay me a sum of money in order to use the library in their projects. So actually, it will be dual-licensed, or tri-licensed.

The first license will of course be the New BSD license, which basically gives everyone the right to use the Library with almost no exceptions for anything. That license will be for those using the project for free projects or for commercial projects that won’t be distributed. The second license will be for distributed commercial projects, like premium themes and plugins that wish to have an End User Agreement prohibiting the user from redistributing the theme or plugin. The third will be LGPLv2 and up, if WordPress ever wanted to use the library and distribute it, but I doubt that possibility. However, it could apply to any GPLv2 or GPLv3 project.

I think part of the issue is that library is under the same license as the application WordPress. Therefore all code that links to it, has to also be compatible to GPL. This means that it doesn’t restrict the user that isn’t in the GPL. The clause to restrict Commercial entities shouldn’t really apply since their license will not be GPL anyway. The licenses that work with GPL, namely the New-BSD and LGPL can be used without restriction. So if the project was GPL, then it would have to use one of the two, and it couldn’t be the one with the commercial clause. It also means that the user will be able to take full advantage of the GPL, which means redistribution and selling it. If a commercial project wants to protects their rights, they’ll use the library, or write their own.

Regardless, I think there are a lot of code in WordPress, which is done right and is almost impossible to reproduce without copying the code. Personally, I’m not going to rewrite the entire WordPress library. I’m just going to focus on the parts that Plugins and Themes use the most. I’m also going to focus on other components to experiment on how they could be improved for optimization.

Oh yeah, I’m also writing the library to where it will be fully unit tested, where applicable and with documentation. The progress is pretty slow with that, but it is worth it. It allows me to see in real time how far I need to go and how much I’ve accomplished.

The project is new, and right the repository is local to my machine. I’m going to put it up on the Google Code, when I get to the point where it can be reasonably be used in applications. Oh yeah, I’m writing the library for PHP 5.3, I’m going to backport it to PHP 5.2.x, but it won’t be available on PHP4. Right now, there aren’t any hosts that are using PHP5.3, because it hasn’t been released. I want to see what it would look like using the top of the line PHP code.

I’m going to be posting more about the library. Well, I suppose I should have a disclaimer, I might not complete the library depending on what happens. It is going to be a lot of work, so I might not have the motivation to complete it. However, I’m going to spend as much time as I can get to it where it needs to be. At that point either someone else can take it on or I can work with some one on it.

Possibly Related Posts:


Tags:
Posted in Projects | 2 Comments »

WordPress 2.7 Changes Class for Plugins

Thursday, November 20th, 2008

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:


Tags: ,
Posted in Web Applications | Comments Off

10 WordPress Features You’ll Never Care About

Saturday, November 15th, 2008

A lot of the WordPress lists are going to point out the features you can see or will eventually see. However, that does little for those of us who care about what is under the hood. Here are my personal favorite 10 WordPress 2.7 features that I’m going to enjoy.

1. Inline Documentation

WordPress 2.7 will have complete library documentation and file documentation in the form of phpdoc style comments. There is also a phpDocumentor official documentation site. Although, some would probably wish for a PHPXRef site, maybe for WordPress 2.8.

The administration library for WordPress is missing inline documentation in many places, but all of the files that plugin authors will use is documented. Of course, to say that the documentation is complete does not mean that it can stop. The inline documentation needs to be continued by the continue and eventually the administration library portion needs to be documented as well for completeness.

2. HTTP API

People have complained in the past about the fact that they can’t access normal features, because their host is crap and disabled PHP functions for some reason or another. Well, all PHP methods for HTTP requests is implemented, so if you still can’t access those features, then you are totally shit-out-of-luck. That isn’t to say that the aren’t bugs with the new API, and those will be fixed when they come up.

The API is also available for plugin developers. It also handles chunked decoding for those that like to send HTTP 1.1 responses to HTTP 1.0 requests. If you send HTTP 1.1 requests, then you are taken care of. It does a pretty nice job of holding your hand through the process, so there shouldn’t be anything you need to do.

3. Plugin Uninstaller

Plugins now have a built-in way for when their plugin is uninstalled. Plugins are uninstalled when they are deleted.

4. XMLRPC Comment API

You’ll only care about this, if you 1) have an iPhone and 2) use the WordPress App for managing your blog. Most others probably will care less. Pretty hot though. XMLRPC is pretty good stuff, in general.

5. Amount of closed tickets

There are currently 450+ with the potential to have over 500 tickets closed. Doesn’t mean that WordPress is stable, but it does mean that WordPress is more stable than before. There are currently almost a 1000 Trac tickets for WordPress. Any milestone that puts a huge dent in that total is pretty awesome in my book.

The goal should be to reduce that number to near zero, but that would take far more community contribution than is current. Every new feature that is added will increase the number of defects, which is probably 2/3 of the rest of the 1000 tickets.

6. Theme API

The theme API will currently upgrade your theme, if an update is available. It doesn’t do everything the plugins have, but that will come in 2.8. Also, the theme has to be part of the theme repository on WordPress.org. It won’t work on external sites. Well, there are hooks you might be able to plug into in order to supply your users the same functionality, but probably not going to done.

7. Removed erroneous message from wp-config.php

The message “99% chance you won’t need to change this” has been removed from wp-config.php, but still remains in the wp-config.php creator. Ironically, after I pushed to have this put in, I am in fact using localhost more often. Still, it was worth it… maybe. At the time it was.

8. Optimizations

Some of functions were improved with optimized code. You probably won’t notice it.

9. Less Notices

If you turn on the ‘WP_DEBUG’ constant, you won’t see many notices as you would in 2.6 and before. This will improve the debugging for plugin authors as they won’t see WordPress notices and warnings.

10. Nothing

Well, I couldn’t think of a tenth feature that no one will care about, but perhaps you can inform me of a worthless feature that I may or may not care about. I can also neither confirm nor deny the validity of the claim that no one cares about these features (because I care about all of them… oops) nor the claim that these features are worthless (because they are worth something to someone or they wouldn’t have been in the version).

Possibly Related Posts:


Tags:
Posted in General | 11 Comments »

Web Application Versioning Alpha Release

Saturday, October 4th, 2008

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:


Tags:
Posted in Web Applications | Comments Off

WordPress Theme Modifications should be made in Child Themes

Monday, September 29th, 2008

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:


Tags: ,
Posted in Web Applications | 4 Comments »

One More Week of Inline Documentation

Monday, September 15th, 2008

I’m giving this inline documentation project one more week, before I set it on hiatus for a month. I still want to get as much completed before 2.7 is released. I just think that giving the rest of this week should be enough to at least finish the wp-includes directory files. I probably won’t get to the rest of the wp-admin files that have functions. I definitely not going to be able to finish up the wp-admin/includes files with inline documentation.

I’ll be lucky to complete the rest of the files in wp-includes. What I’m doing now is complete the files I know no one else is going to want to complete and then leave the rest to those who want to complete them. There are a couple I think that might be willing to do so.

Next week, I plan on working on plugins and finally complete a few projects that have been on my mind. It will be nice to have those out of my mind as I enter into my year long project.

Well, it might be motivation for the rest of the WordPress community to finish it. I think after working a month on plugins and getting the year long project started, I’ll be fresh to complete the rest of the inline documentation that remains.

It is hard to believe that, after an entire year of starting the inline documentation, with merely two files fully documented or 12% (Ohloh.net), that it is now at 27.7% (Ohloh.net). Well, it is more than that. With the entire WordPress codebase documented, that number should be well within or more than 30%.

It will also mean that WordPress will be at the level of Habari when it comes to inline documentation and beyond Habari when it comes to codex documentation. Well, I could have just worked with Habari and saved myself the trouble and time, but it was worth it. Or at least that is what I tell myself in order to sleep at night.

I think that I’m lucky that those before me put forth the effort to write inline documentation and I hope that those after me continue the effort. Just because a function has inline documentation doesn’t mean that it is complete. Inline documentation, just like the codex documentation has to be maintained. The nice part, is that the maintenance is at the micro level, meaning that when a function changes, only that documentation needs to change also.

One of my fears, is that people will forget that inline documentation needs to be maintained and it will become worthless because of it. My second fear that new functions won’t be documented has been proven to be unfounded. New functions are being documented by most of the core team and it seems that it matters to most of them.

Well, if I had a choice, I would choose incorrect inline documentation, because then it is easier to correct the parts that are wrong. Trying to add new inline documentation is not a task I want to take up again.

Only 9 files remain and after tonight, there should only be 8. After tomorrow, there should only be 7. After that, I’ll work on capabilities.php, comment.php, and widgets.php, which are the more difficult files to document. That will leave category-template.php, link-template.php, post-template.php, and theme.php. I think that with the rest of the week, it isn’t going to be exactly easy completing the *-template.php files.

I’ll be able to complete the functions that have short bodies, but that is only if I can complete the other files before the weekend. I can probably complete a file a day, there is no way I’m going to be able to complete all of the files left. The only good news is that comment.php is halfway complete anyway.

Possibly Related Posts:


Tags: ,
Posted in General | Comments Off

September WordPress Development Plans

Saturday, September 6th, 2008

Inline Documentation

I have switched my focus to the wp-includes directory files, because there is a lot more support for documenting those files. Peter Westwood helped document general-template.php and Scott H helped with formatting.php. There are only 13 remaining files that need to be documented and I plan on finishing the remaining ones before next week is over.

I hope that those who have contributed will contribute some more. It is a great feeling to be down to such a small number, as opposed to the 26 files from several months ago. It is nice and I hope to have a few more files done today.

It is beginning to get to the point where the functions I’m trying to document aren’t within my ability to correctly do so. I’ll try my best, but I’ll hate to leave the functions without any type of documentation. If it comes to it, I might have to use the functions to understand what they are supposed to be used for. Doing so would take a lot more time, so I hope there aren’t a lot of functions that need this method.

Plugins

I still want to develop several plugins from my previous list. It would be nice to grow my list of plugins. There are some enhancements I’ve been waiting to do for a couple of my plugins. Alternative Mailer needs to support attachments, but I’m actually unsure how to go about doing that. It needs other enhancements.

WordPress Acceptance Tests

Finally, if I can get to it this month, I want to start writing some acceptance test cases using Selenium. WordPress 2.7 is a little too buggy for my tastes and I want to offer better QA, so that users won’t take up arms for the lack of proper testing.

It should go fairly quickly. I’m going to focus on the Administration Panels first and go through each page. There should be upwards to about a 1000 total tests. I think I’m also going to plan it out a bit more, so that it can be known when all of the tests are complete.

Given how much time I’ll need to devote to my plugins, I’m not sure I’ll be able to finish this month. However, starting it and then finishing it in October might give better reason to releasing WordPress 2.7 in November instead of a month early. Well, depends on I think it will take a full week to do everything I need to finish up the plugins and create the new ones. That will give me a week to finish this project.

Given my future plans I’m not sure I’ll be available to create any patches for the administration. It isn’t my area that I usually write patches for. Also, I’ll be moving on to other projects that use the WordPress library, but I don’t really want to support the Administration, unless I have to. Regardless, the tests and bug reports should help the community and core team fix the bugs on their own.

I’m not going to use the Automattic WordPress Tests repository. I’m going to create my own for this project. It is going to require more work than the WordPress Tests, so I’m unsure how many will actually participate with using it.

Possibly Related Posts:


Tags:
Posted in Projects | 2 Comments »

Don’t Use WordPress 2.7 Trunk on a Live Blog

Sunday, August 31st, 2008

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:


Tags: , ,
Posted in Web Applications | 4 Comments »

More Inline Documentation Completed

Saturday, August 30th, 2008

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:


Tags: , ,
Posted in General | Comments Off

« Older Entries
Newer Entries »