I haven’t been using MODx for very long, but I have worked with several other content management systems previously and experienced both the good and the bad with them. MODx appears to be a fairly simple MVC style content management system with a bit of a pluggable architecture. I haven’t written any plugins for MODx, but it appears that hooks are used just like WordPress does.

I have found MODx to be very easy for creating fully tableless XHTML compliant sites and creating very search engine friendly websites. Very easily, it is also possible to hide what cms is running the site by using the easily created pretty urls. (There’s just a couple of simple settings and a file renaming.)

I found the templating system to be extremely frustrating because the template is actually stored in the database instead of in the file system like done in most traditional CMS. I really find editing the templates, snippets, and larger chunks extremely frustrating to edit in the manager because of the lack of syntax highlighting, and issues with formatting.

Of course, the manager does offer the advantage of being able to edit content and site structure from pretty much anything that can access the internet and doesn’t mind some fairly heavy javascript use. MODx’s requirements for webhosting aren’t exactly hard to find either although there is a forum of reviews and suggestions.

Overall, MODx doesn’t appear to be too bad for smaller boutique websites which are a large chunk of my current business. I believe I would recommend it to fellow freelancers for smaller websites that don’t have much need for plugins or high amounts of customization.

I’m hoping to use this post as a way of clarifying the lifetime of an object in PHP because I am continually running into webdesigners and programmers that don’t understand the lifetime.

To simplify, in PHP between requests only the variables in the contents of $_SESSION are retained. This means that whenever a script executes objects and variables are created and upon completion all objects/variables are destroyed. Many programmers that have programmed in more traditional object oriented languages like C# or Java often build extensive object hierarchies that will be rebuilt on every request unless stored in $_SESSION, cookies, or some other external store.

Unfortunately, many of the patterns and refactorings suggested by the Gang of Four have to be used with caution in PHP because of the stateless nature. The stateless nature of PHP does allow us a lot of extensibility though and allows for much greater scalability.

For the last couple of weeks, I have began playing around with Drupal because I’m so sick of fighting proprietary CMS. The proprietary CMS suffers from the vendor updating only updating the CMS when convenient for them and this ends up holding the purchaser hostage. Rolling your own CMS is a terrible idea when there are at least 100s of other CMS that often include 100s of plugins that can perform a lot of the needed functionality.

So far, I haven’t really found anything negative with Drupal’s community or documentation. I am very impressed with the Drupal Handbook and so far have found it sufficient for most of my needs. Drupal doesn’t seem to really suffer from a lack of documentation found in open source software or seem to have any large splits in the community.

So far, I really only have two major complaints or issues with Drupal and both are really more of my fault than anybody else’s. I haven’t exactly found documentation or examples on how to migrate from a different CMS or WordPress: I’m hoping to move away from using a separate templating engine and a separate WordPress blog and combining them in a single instance of Drupal. Migrating completely to one system should allow me to have a single website instead of two distinct entities that only share a domain name: I never really planned to ever have a blog and sort of just bolted it on in hopes of doing something later on.

Drupal’s core is extremely well documented if you happen to start reading the documentation first. I sort of just glanced over the documentation quickly after I did my first install and started tinkering, adding modules, modifying settings, etc. I always seem to learn best by doing. My learning by doing always results in me heading into completely unknown territory and potentially damaging things that already work but again this really helps me to learn a lot about how the software or code performs. I was a little disappointed about the structure of drupal’s core being in multiple “root” folders and thought it would have made more sense to be in a folder like /core to discourage programmers to modify the files. Immediately, I started dropping modules I wanted to use in /module and only realized after reading a little more about the core that modules shouldn’t just be added to /modules and instead should be added to /sites/SITENAMEHERE/modules

Overall, I know that drupal has enough of the functionality that I need in modules and the core to significantly improve the efficiency of my programming and possibly offer a large learning opportunity on software architecture.

A couple of weeks ago, I noticed there was a new version of PHP out than I was using for my development environment (WAMP) and decided that I should take the time and upgrade the development environment and perhaps even the production environment after retesting my web applications.

The actual upgrade process itself was simple, but PHP 5.3 deprecates the MSSQL Extension. Instead you must now use at least the SQL Server Driver for PHP v1.1 which is of course Windows only and requires any installation of Windows preceding Windows 2000. You need to ensure you have installed the SQL Server 2008 Native Client. Making the change wasn’t overly difficult because I took the upfront time and wrote a very simple Database Access Layer because I assumed something may change in the future (driver, database, etc.)

The biggest advantage of the change is being able to better take advantage of Microsoft SQL Server features that probably made you choose to use SQL Server in the first place.In addition, Microsoft has made the source code available. I’m really excited to hear a new version will be out soon that will allow PHP programmers to use PHP Data Objects (PDO) with SQL Server!

Test Driven Development and xUnit seem to be popular among many of the professional and very public programmers, so I thought I might like to give it a whirl and see if I can improve the flexibility of my source code and better decouple objects. Unfortunately, I use WAMPServer on Windows as a development server while at work so directions for installing PHP related plugins/PEAR aren’t exactly identical. (Usually, I can figure it out fairly quickly.)

Installing WAMPServer is fairly quick and well documented online, so I won’t cover it specifically although I will mention I am using WAMPServer v2 at time of this writing. I will also assume that you have used the default file paths of “C:\wamp” and “C:\wamp\www”

Steps to installing PHPUnit:

1. Install PEAR if you haven’t already by opening up a new command window and entering the following commands
   
cd \wamp\bin\php\php5.3.0
go-pear.bat

2. Press enter when the list of directories appears
3. When asked if you want PHP.ini to be modified press Y and then enter.
4. You will be told the include path is updated. Press enter.
5. You be will be told PEAR_ENV.reg has been created.
   PEAR_ENV.reg
6. Pear is installed, but it isn’t the newest version of the updater, so we should update because PHPUnit requires at least PEAR Updater 1.8.1
   pear update-channels
7. Thankfully, we are nearly done our journey. We simply need to add a channel to PEAR and then we can install!
   pear channel-discover pear.phpunit.de
pear install –alldeps phpunit/PHPUnit

Good luck testing and keep checking back to see how to test!

Recently, I have been busy using Windows Server 2003 and IIS to host a web-enabled application written in PHP,using the PEAR modules, and MySQL and MS SQL.

I couldn’t really believe how much messing around is necessary to get PHP to function correctly, and to properly use the PEAR modules. I have probably spent two hours modifying the php.ini file based on what I have found on php.net and around the internet.

My webapp, needed sessions and of course I kept getting warnings and critcal errors from PHP. I found so much information that was just plain wrong and probably never was correct. My latest problem in this epic battle was this warning:

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct () in Unknown on line 0

Eventually, I read through my PHP.ini file from start to finish and found this information:

; Argument passed to save_handler. In the case of files, this is the path
; where data files are stored. Note: Windows users have to change this
; variable in order to use PHP’s session functions.
;
; As of PHP 4.0.1, you can define the path as:
;
; session.save_path = “N;/path”
;
; where N is an integer. Instead of storing all the session files in
; /path, what this will do is use subdirectories N-levels deep, and
; store the session data in those directories. This is useful if you
; or your OS have problems with lots of files in one directory, and is
; a more efficient layout for servers that handle lots of sessions.
;
; NOTE 1: PHP will not create this directory structure automatically.
; You can use the script in the ext/session dir for that purpose.
; NOTE 2: See the section on garbage collection below if you choose to
; use subdirectories for session storage
;
; The file storage module creates files using mode 600 by default.
; You can change that by using
;; session.save_path = “N;MODE;/path”
;
; where MODE is the octal representation of the mode. Note that this
; does not overwrite the process’s umask.

In conclusion, if you will run your web-enabled application on a Windows PC you must set the session.save_path to something and you must create the directory structure yourself. I am using the session.save_path = “C:\temp” and recommend you do something similiar.