CorePress Revisited, Now ALW

Posted by Jacob Santos on May 27, 2009

It has caught on, I suppose, but a name change is in the works. Meh, Alternative Library for WordPress might work or ALW. All it is really is an BSD library that implements WordPress common features for PHP 5.2 and PHP 5.3 with emphasis on PHP 5.3, so namespaces, closures, and the like. The primary focus will be to implement something that implements both dependency injection and a similar plugin model that is in WordPress.

I’ve decided that I’m not going to maintain that much backwards compatibility with WordPress. I’m building this from the foundation to be my own, so there won’t be any license issues with going with New BSD and LGPL dual license.

Below I’m placing an emphasis on what I’m going to be developing for planning and for keeping track of what I’ve implemented. The key is that I’m going to be pretty much scrapping the last CorePress project and starting anew. The goal eventually, will be to use the project as an replacement to BackPress and for usage in a project to replace WordPress using Yii Framework (which is also New BSD). The project is not meant to fragment the community, because I doubt it will at this time, because hell, there isn’t any working code at this moment.

The problem I have is that WordPress is stuck in the PHP4 era and even when it jumps to PHP5, its architecture isn’t really going to be all that ready for PHP5 way of implementing classes and redoing the paradigm. I’m starting that now, so that hell, with as many frameworks as there are out there, why should WordPress have to maintain the controllers, views, etc implementation? I’ve looked at Yii Framework and it implements a lot of what WordPress has already, with a little work with models and views it should be a fine replacement.

The reason I haven’t yet started is that I’m unsure of whether is the best way to go. I know I’m going to do it, but others might not want to use the Yii Framework, so forcing it on them doesn’t seem like a wise choice. What I’m going to do actually is provide a library that will hook into WordPress, hook into Yii Framework, and allow others to create their own hooks for their projects.

Task Priority Est. Time Actual Time Unit Tests Done
Database 10 21 0 0%
Main class for loading the connector wrapper and managing a similar API to wpdb. Some work was done, but majority of it needs to be reduced and the scope limited. Will use Dependency Injection pattern to offset some tasks. 10 3 0 0%
Connector Interface for which to test for when accepting connector classes in the main class dependency injection implementation. 10 1 None 0%
Default PDO Connector class: loads WordPress DB constants as long as they exist or accepts parameters for connecting. 10 3 0 0%
Yii Framework Connector class: Basically just accepts or tries to pull in the Yii PDO connection. Will inherit from the default PDO Connector Class, so this shouldn’t take any time. 10 1 0 0%
MySQLi Connector class. Will pull in the WordPress variables, or accept parameters for connecting. 5 3 0 0%
MySQL Connector class. Will pull in the WordPress variables, or accept parameters for connecting. 2 3 0 0%
MySQL Connector class. Will pull in the WordPress variables, or accept parameters for connecting. 2 3 0 0%
Scheme Loader class. 8 4 0 0%
Plugin 10 21 0 0%
Factory Plugin Class. This class stores the plugins and actions class and returns the class to add, remove, and execute plugins. 10 3 0 0%
Hook Parent Class. The Actions and filters will extend this class and it will have majority of the functionality here. Just that the executing is different for filters and actions. 10 2 0 0%
Filter Class. 10 4 0 0%
Action Class 10 4 0 0%
ParameterList Class. This class will take the extra parameters and package them up for the hooks. They will only have to accept this class and then use it. 10 2 0 0%
Back-compatibility Hookable Class. This will provide backwards compatibility for classes that don’t wish to implement the Hookable class. It will be slower, but should function the same. 3 2 0 0%
Habari Compatibility Class. This will allow for loading a class and have the methods hook into available hooks automatically. 1 4 0 0%
HTTP API 7 24 0%
HTTP API Main class. This will initiate the request to the URL. This is different from the current implementation in WordPress in that everything is stored in this class and this class will delegate most of the functionality to other classes. 10 3 0 0%
Streams transport 10 2 0 0%
Fsockopen Transport 10 2 0 0%
cURL Transport 10 2 0 0%
HTTP Extension transport 10 2 0 0%
Compress Class. This will handle the deflate and sending compressed data to servers. 10 2 0 0%
Headers Class. This will handle the manipulation of headers. 10 2 0 0%
Cookies Class. I did not write the implementation in the WordPress HTTP API, therefore I will have to rewrite this on my own. If I follow the specs, I should be fine. 5 6 0 0%
Proxy Class. I’m not sure, but I wrote a lot of the current code in the WordPress HTTP API, so I’ll still be able to use it for here. There are changes I’ll be making, detailed below. 10 2 0 0%
Deflate Class. Handles deflate support for the response. 10 1 0 0%
Template 0%
CRUD 0%
Users Table. 10 4 0 0%
Posts Table 10 4 0 0%
Taxonomy Scheme Classes. The implementation will be a bit more complex, since handling one table per class would be worthless. Each table has to be handled together given a specific task. 10 10 0 0%
Meta Data Table. 10 1 0 0%
Options Table. 10 1 0 0%
Authentication / Authorization 0%
Registering. Uses Dependency Injection for implementation. 10 5 0 0%
Authentication. Uses Dependency Injection for implementation. 10 5 0 0%
Authorization. Uses Dependency Injection for implementation. 10 5 0 0%
Widget 0%
Widget Management. Adding widgets controls to Widget areas. Remove widgets controls from widget areas. Will have file, manual and database backend. 7 10 0 0%
Widget Control. Base Class, Single Widget Class (extends Base), Multiple Widget Class (extends Base). 7 6 0 0%
Widget Area. Registering Widget Areas. Displaying Widget Areas. Checking widget area contains controls. Manually adding Widgets. Getting widgets controls from database. 7 6 0 0%
Default Widget controls. 5 10 0 0%
Caching 0%
Caching Class. API for adding contents to the cache, then managing. Majority of the work will be delegated to other classes below. 7 3 0 0%
Memory, per request cache. Similar to default in WordPress. Allows for only calling SQL queries once per request, instead of fetching multiple times. 7 4 0 0%
XCache Variable Caching. If variable caching is enabled in XCache, then this class will use it. 7 3 0 0%
Memcache Caching Class. This implementation will use Memcache, if it is available. 3 4 0 0%
APC Variable Caching. Will cache using the variable cache in APC, if extension is available. 7 3 0 0%
Dependencies 0%
Dependencies Class. Adds and queues scripts and style sheets, so that printing the lines out can be simplified for the developer. 7 2 0 0%
Output Classes. The dependencies that are outputed will have helpers for outputting the scripts and stylesheets in the header and footer. 7 4 0 0%
Security 0%
Base Security Class. The goal is to implement very little of security into the library and rely on external libraries (Zend Framework, PHPass, etc) for implementation. Inclusion of the WordPress API will most likely be GPL, since the code would be pulled from the WordPress library. That is not ideal in a New BSD library, so any attempt will be to either not have it and delegate it out to another library or to rewrite to be compatible with New BSD licensing. 10 10 0 0%
HTTP validation and sanitization. This will wrap HTML Purifier (separate library, will not be packaged with ALW), KSES, and regular wrapper for PHP strip_tags. Other libraries will be evaluated as well. 10 10 0 0%
Uploading Security. Image validation, File extension upload validation, etc. This is done so often that basically it is part of majority of libraries and packages. 10 5 0 0%
Streams transport 10 2 0 0%
Upload 0%
Uploader Class. Wrapper for controlling the security and placement of the uploaded files. 7 7 0 0%
SWFupload Wrapper. Implementation to get SWFupload and JavaScript progress uploading working. 3 15 0 0%
Image 0%
Resize Class. The goal is to dynamically resize images. 5 4 0 0%
Cropping Class. This will include integration with jCrop jQuery plugin, but won’t require it. 5 4 0 0%
GD Implementation. Pluggable class for the above two implementations that uses the GD extension. 5 7 0 0%
ImageMagick Implementation. Pluggable class for the above two implementations that uses one of the two ImageMagick PECL extensions. 3 7 0 0%
Debug 0%
Timer Class. Keeps track of time. As well as individual anon and named timers. 5 2 0 0%
Deprecated Class. Informs caller that the usage of the function, method, or class is deprecated and will be removed in a future version. 5 2 0 0%
Debugger Class. This class captures the errors and exceptions and allows for a plugin to write it to a log or to display it. It will also enable or display globally the debugging. Not having debugging should speed up execution, since errors won’t be written to the database or to a file. 5 4 0 0%
Error Output Class. This class and function utility will display an formatted message to the user. The format can be HTML, JSON, or XML, or XMLRPC. 5 8 0 0%
Logger Class. This will log to either the database or to a file. 5 4 0 0%
Installer / Upgrader 1 68 0%
Installer Class. Main class, lets the actions know that an installation is taking place. 10 4 0 0%
Upgrader Class. Main upgrade class, lets the actions know that an upgrade is taking place. 10 4 0 0%
Requirement Class. Used to test for a prerequisite is available. This will be a parent class or abstract class. 10 4 0 0%
Default Requirement classes that are available for the user to plugin to the installer or upgrader class by default. 8 16 0 0%
Information Class. Informs the installer about the specs they have. Will also be a parent or abstract class. 10 4 0 0%
Available Information classes that are available to the developer by default. 8 16 0 0%
Action Class 10 4 0 0%
DB Table Scheme Class. Extends the Action Class to create tables. Will also run modifications to tables as well. 8 8 0 0%
DB Table Row Scheme Class. Extends the Action Class to create rows in existing tables. 8 8 0 0%

Test Cases

The goal is to have at least 80% code coverage for every library component. Not that code coverage is a good indicator of flaws and bugs, but it is far easier to extend into fringe areas if at least the majority of the library has tests. The goal is to correctly test that the code is working as well as try to break the damn code (which is extremely difficult to do when you know too much about the code).

Another issue I have is that it increases the time for developing the library when you are writing inline documentation and unit tests. It extends the time further when you have to build mock classes to accurately test some of the library code. It is one of the issues I had when writing the library before was that it felt like I wasn’t getting anywhere when I had to correct so many tests.

Well, the reason I continued to do it was that it would be worth it in the future. I should still be able to use some of the test cases that I’ve written as well as some of the code. It will increase the motivation to continue and the DB parts I’m going to focus on completing enough to have it working

Installer / Upgrader Task

The upgrader, installer task is to implement a simple contained task based class structure. How the page is handled is outside the scope of the API. The user can do it by smoke signals or a front controller or page controller. The key is that if successful, a certains of events will be performed and if it is a failure, it exits and prints a message to the user. The key is that with WordPress, the Installer is largely a huge mess and navigating it, is not fun.

The point is that the person should be able to extend or remove elements from the installer and upgrader with ease. I like certain elements of how the WordPress installer is implemented and something like this really needs to be separated from the main application. I’m also going to try other ways to do this. A FTP installer where you basically download a small package and then able to choose which parts you actually install would be cool as well, but that would just be another action or class that will exist for the developer to implement in the installer.

I’m going to start small, with something that just replaces what is in WordPress. The Package name will be external from the rest of the library. This will keep it from being confused with the core library replacement for WordPress. Its falls under administration API, so its priority is pretty low.

HTTP API

Well, since I hold the copyright for some of the code in WordPress, I can take what I had and work off of it. So it won’t be building from the ground up again. I think I’m going to use a different pattern than what is in WordPress currently. There is something I had wanted to explore with the code I added into WordPress, but I never got around to implementing it, nor was I sure how I would go about doing so.

The problem is that similar actions are performed in different locations, so it almost makes more sense to handle it that sort of way. You know, basically have the API where the data is added, and the transport handles it based on the different classes. I think this will be step up in the architecture, but still wouldn’t be perfect. Also I think it would be better to make it completely independent of WordPress and the API, so I’m going to do the same thing as the Installer and Upgrader. I’m going to place this in its own package name.

Database Scheme

I’m interested in what better ways there can be for writing the Database Scheme. I’m going to attempt three ways on how to do this and then I’m going to implement something like ADODB as well. That said, I’m going to experiment with an installer for the WordPress for the database scheme.

  1. Different classes with the SQL inline for each CRUD implementation for each table.

    Advantages: I don’t know. It is something I’m familiar with, so it will be super easy for me to implement. It should work the same no matter which DBMS I’m working with when using the Scheme Loader class.

    Disadvantages: I’ll still need an interface to plug in the different scheme. This will be somewhat different from what I’ve implemented in the past, so it is unlikely to be perfect when first developed.

  2. CRUD class class in Scheme class that contains the SQL statements.

    Advantages: Depends, I’ll have all of the SQL contained in a single place, so that when I need to make a change, I can do so in one location or a few locations. This may simplify things, but…

    Disadvantages: This is uncharted territory, so what SQL might work in one table might need to be handled differently in another. If I’m working with prepared statements, it should make it easier, but still seems a little unclean.

  3. CRUD class class in Scheme class that contains the SQL query.

    Advantages: This is different from the first one in that the CRUD class does the checking and pulls in the correct Scheme class to perform the action. Probably better than 2 in that I don’t have to worry about unforeseen limitations with the second choice when switching to another DBMS.

    Disadvantages: I’ll probably have to do more work, because I’ll be basically duplicating code that would be in a single class in option 1, so it will take longer to implement.

Overall, I think I’ll have the best bet with 1, so I’m going to attempt it first. Well, the nice part with dealing with a single class is that if I decide in the future to do it the second or third way, then I won’t have to do extreme rewrites of the code that depends on the actions with the database. Even if I’m using ADODB, I’ll still be able to use a single class and just have one scheme to pull in. I’ll be doing benchmarks to determine if it is a good idea.

Possibly Related Posts:


General

Comments are closed.