Back Blogging Again

Bless me internet for I haven't blogged, it has been 274 days since my last post.

I have wanted to blog, but I kept on finding excuses to avoid it - need to upgrade the software, need to finish x, y and z, need to focus on projects a, b and c etc. One of the main reasons is that I have been too lazy to put the effort in. I find it takes time to think of what to blog and then to bash it out, refine it and post it. When I have had the time to put that effort into my blog, I haven't had the inclination.

While things have been quiet here, I have microblogging using the open source laconica platform through identi.ca, which also posts to StixCampNewstead.

More recently I have been working with a client in France who has some serious collaboration requirements. At last count they have almost 2100 instances of drupal running. This has involved a lot of work, and some travel. I will blog about this project soon - it is pretty awesome (even if I say so myself).

We have built a small drupal powered site for a local assest management consulting business. They are very happy with the results. Now their customers just log in to download the software. Everything was off the shelf drupal - except for the theme and a 60 line custom permissions module.

We have built the Newstead community website using drupal. It still needs some polish before final launch. The community has been heavily involved in the development of the site. So far over 30 locals have been trained in maintaining their page/s on the site. There is no "webmaster", each local business and community group will maintain their own content

A couple of months ago I/we joined the drupal association. One day the buttons will be added to the site.

Where to next?

I plan to blog more about projects I am involved in. I also plan to switch this site to drupal 7 as close as possible to the release date - it looks like others will be switching too. Next week I will be commencing the build of the Newstead community wireless network.

Watch this space, lots happening - including more frequent updates from here on in.

Updated IMCE plugin for Drupal YUI Editor

My IMCE plugin for YUI Editor has been included in drupal CVS and the 6.x-2.33 release. Now I can claim to have code included in an official drupal release, ok it is a small plugin for a contrib module, we all have to start somewhere.

The version included in Drupal only supports YUI 2.5.x as the API has changed in 2.6. I have a new version which supports 2.6.x, but it has a layout bug, so I won't be submitting it until this bug is fixed. If you can tolerate the visual bug or want to help fix it, grab the lastest version of the IMCE plugin for Drupal's YUI Editor. Use the same installation instructions as last time.

Feedback welcome.

YUI Editor + IMCE for Drupal 6

Update: This has now been included in the 6.x-2.33 release of Drupal's YUI Editor module and I have added support for YUI 2.6.

Earlier today I finished off another Drupal based site. The client was pretty happy with it. Once they launch I will probably post a link.

The client came back to me and asked how they could insert images using the RTE. Based on some positive reviews I used the YUI Editor module this time around, instead of FCKEditor or tinyMCE for the rich text editor. The YUI Editor module doesn't support file browsing. I tried to see if someone had already hacked something together for this, if they had I couldn't find it.

In the past I have used the IMCE module for image browsing and uploading in FCKEditor or tinyMCE. Adding IMCE support to the YUI Editor module seemed like the fastest solution.

So here it is - the IMCE based image browser plugin for YUI Editor on Drupal 6.

Here is a quick howto. Install the YUI Editor and IMCE modules into your Drupal 6 install. Save the plugin tarball into your modules directory above the YUI Editor module and extract it. You should now have 2 extra files yui_editor/plugins called img_browser.inc and img_browser.js

Feel free to leave comments about how well this works for you. Enjoy!

A Virtual Host per Project

Not long before my old laptop got to the end of it usable lifespan I started playing with the Zend Framework in my spare time. One of the cool things about ZF is that it wants to use friendly URLs, and a dispatcher to handle all the requests. The downside of this approach, and how ZF is organised, it works best if you use a Virtual Host per project. At first this seemed like a real pain to have to create a virtual host per project. One Saturday afternoon I worked through the apache docs and found a solution - then I found it fantastic. Rather than bore you with more of my views on Zend Framework, I will explain how to have a virtual host model that requires a little work up front and is very low maintenance.

It gets tedious copying and pasting virtual host config files each time you want to start a new project, so instead I let Apache do the work for me.

I added a new virtual host config file called projects to

. The file contains

UseCanonicalName Off

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon

<Directory /home/dave/Projects>
Options FollowSymLinks
AllowOverride All

	ServerName projects

	CustomLog /var/log/apache2/access_log.projects vcommon

	VirtualDocumentRoot /home/[username]/Projects/%1/application/www
	AccessFileName     .htaccess

The important bit is the VirtualDocumentRoot directive which tells Apache to map a hostname to a path. I use an IP address from the range for the virtual host, so they aren't accessible to the outside world and I don't have to worry about it changing every time I check locations.

All of my projects live under ~/Projects and each one gets a directory structure that looks something like this.

  +- notes - coding notes, like grep output when refactoring etc
  +- resources - any reference material or code snippets
  +- application - the code for the project
     +- www - document root for vhost

There are usually other paths here too, but they vary from project to project.

To make this work there are few more steps. First enable the new virtual host

$ sudo a2ensite projects

Don't reload apache yet.

Next you need to add the apache module

$ sudo a2enmod vhost_alias

Time to edit your

file so you can find the virtual hosts. Add a line similar to this projects phpgw-trunk.project [...] phpgw-stable.project

Now you can restart apache.

$ sudo /etc/init.d/apache2 reload

This is handy for developing client sites - especially using drupal.

Now my

is just an empty file.

I am getting a bit bored with adding entries to

all the time. If I get around to adding dnsmasq with wildcard hosts to the mix, I will post a follow up.

This setup is based on my current dev environment (Ubuntu Hardy), but it also works on older versions of Ubuntu. The steps should be similar for Debian and derivatives. For other distros, it should work, just how to make it work may be a little different. Feel free to post tips for others in the comments.

phpGroupWare release?

I have been thinking about how to deal with releases of phpGroupWare. For me it is a technical, procedural and political question.

Over the last few months I have been playing with drupal a fair bit. I love drupal. It is simple to install, skin and hack. The community is great. The website is massive and has almost anything you want about durpal. They dog food their stuff. I have quite a few clients using drupal for their sites, they love it. There are many cool things on technical level within druapl too - but that would take this post off on a long tangent.

Drupal was allocated 20 summer of code places by google. phpGroupWare received 1 spot, indirectly. To me this is a sign of the popularity of the project and the level of activity within the community.

I hear you thinking, but hang on, drupal is a CMS, phpGW is a groupware suite, compare apples with apples. Well, you see I am not trying to compare apples with apples. I am looking for good ideas about how to build a quality release.

I think drupal have it sus'd. The have the core which is released when it is ready. They also have a stack of modules which are released when the developers feel like they are ready. This provides a lot more flexibility to all developers. Developers can prepare versions for multiple versions of drupal, but also release stuff when they think it is ready for release, not wait for the next mega tarball to be prepared.

I think that the drupal release model may work well for phpGroupWare. We could prepare the core (probably API, admin, addressbook, calendar, email, filemanager, notes, preferences, setup, todo - the PIM apps amd sync when it is ready) and release that as phpGroupWare 0.9.18. Then modules developers would be free to package there modules and release them when they were ready. Modules which were tested and stable at the time of the official releases would be listed in the release annoucements. It would mean that getting our apps site working would be important as that would be the entry point for a new eco system. It would also mean that if someone is working on new features for an app, they could release often, while the core would be more static and stable, in order to encourage more app development.

I don't think that we can have a release time table for the core unless we have significantly more (paid?) resources available.

I think that covers the technical and procedural issues, the political hopefully won't be too painful either.

The decision on what is core and what is not will need to be made early. The criteria for assessment should be made publicly available. Developers should be free to ask that their app be considered core. Being a core app is not a vital thing, apps will still be promoted it they are not core.

We could look at 4 levels of apps. Core, as discussed above. Supported, apps which meet the core app standards, but are not considered core for what ever reason. Unsupported, apps which work but do not meet the project standards for some reason (coding standards, bypassing the api, lack of docs, require patches etc). Dead, apps which are no longer maintained and other developers feel should no longer be maintained. The status of the apps would be publicly listed.

Such a model as proposed above would allow us to release a 0.9.18 core with some additional supported apps (such as ged, property, messenger, tts) a lot sooner than trying to get all the 0.9.16 tarball apps ready for release.

The only technical issue to resolve in this plan would be version control as savannah's CVS. isn't really designed for this model of development. I have been discussing switching to SVN with the savannah hackers, they are supportive of the idea.

I do have comments open on my blog, so feel free to leave a comment, otherwise discuss it on the dev list. I will post a summary of the comments there if I feel it is warranted.