H3RALD - Tag 'php' (Atom Feed)

Getting Started with Lithium

2009-10-27T14:48:00Z

So Lithium is now officially out, and its 0.1 release can be freely downloaded from the official web site or by cloning the Lithium git repository. The good news is that although not many web hosts offer PHP 5.3, you can try it out youself, locally and with minimum effort.

Requirements

According to the Lithium Wiki, to develop applications with Lithium you need:

A web server, like Apache or IIS
PHP 5.3.0 or higher
Git (not required, but all example projects are on git repos, so you may as well have it)

For this tutorial, more specifically, you need to download (just download, don’t install anything!):

mongoose, a tiny, standalone (as in one single file), cross-platform web server.
PHP 5.3.0, not the installer, the zip package.
Lithium (version 0.1, at the time of writing)
The li3_docs plugin.

To get the li3_docs plugin you need to register on rad-dev.org, and clone the li3_docs git repository. If you don’t have git installed or you don’t want to read another awesome tutorial to install it and learn how to use it, I’ll save you the hassle and let you download the plugin from here, for this time ony.

Note: This tutorial assumes that you are on Windows. If you are not, some things may be a bit different depending on your platform.

Setting up the environment

Choose a directory on your sistem (let’s call it D:\lithium_test from now on). We’ll do everything in here, and you can move it anywhere you like afterwards, even on a USB stick, without breaking anything.

Unzip Lithium in D:\lithium_test, so that it contains the following files and directories:
- app/
- libraries/
- .htaccess (it won’t actually be used in this tutorial)
Unzip PHP 5.3.0 somewhere and copy the following files to the D:\lithium_test folder:
- php5.dll
- php-cgi.exe
- php.ini (just get php.ini-development from the PHP package and rename it)
Copy the mongoose-2.8.exe executable in D:\lithium_test and rename it to mongoose.exe for convenience.
Create a mongoose.conf file containing the following lines:

cgi_interp      php-cgi.exe
cgi_ext         php

If you did everything correctly, your D:\lithium_test directory should contain the following:

app\
libraries\
.htaccess
mongoose.exe
mongoose.conf
php-cgi.exe
php.ini
php5.dll

Running Lithium

Double click mongoose.exe and point your browser of choice to http://localhost:8080/app/webroot/index.php. You should see the Lithium temporary homepage (yes, I expected something fancier too):

Now, let’s see if we can get the li3_docs plugin running as well:

Unzip li3_docs.zip and copy the li3_docs folder in D:\lithium_test\app\libraries\plugins.
Open D:\lithium_test\app\config\bootstrap.php and add the line: Libraries::add('plugin', 'li3_docs'); at the end. I actually found this commented out already (line 80).

Go to http://localhost:8080/app/webroot/index.php?url=docs, you should see something like this:

Congratulation, you’re now running your first Lithium application!

Fixing URLs

Once the initial excitement wears off you’ll notice that none of the links on the docs page works.

That’s because the mongoose web server does not support URL rewriting (and Lithium needs it badly right now), so we have to change the way URLs are created. @nateabele gave me some tips on how to do this; it’s very simple:

Create a directory called action in D:\lithium_test\app\extensions.
Create a file called Request.php, containing the following:


namespace app\extensions\action;

class Request extends \lithium\action\Request {

	protected function _base() {
		return  '?url=';
	}
}
?>

We’re basically extending the \lithium\action\Request with a custom class, telling Lithium how to create the base URL.

After doing so, open D:\lithium_test\app\webroot\index.php and change:

echo lithium\action\Dispatcher::run();

into:

echo lithium\action\Dispatcher::run(new app\extensions\action\Request());

In this case, we’re instructing the dispatcher to use our custom Request class instead of the default one.

Now everything should work as expected. Reload the docs page (http://localhost:8080/app/webroot/index.php?url=docs) and verify that the links work by navigating to Lithium, then action and finally Controller.

Now you can use Lithium to display its own API locally (if things didn’t work out, there’s always http://li3.rad-dev.org/docs).

Too many cooks... take #3

2009-10-24T18:26:59Z

Like its predecessor, this is another rant about the (end of the) CakePHP framework. Not that I particularly enjoy writing about the misfortune of others, but after reading this official announcement I felt compelled to post.

It has been two years since my last post on this subject and yes, the cake is still rising, but at what price? Will it still taste sweet now that two of its main ingredients are not part of it anymore? As Daniel puts it, probably the best thing to do now is to drink tea and to wait until the dust settles…

As far as I’m concerned, what really matters is that Garrett Woodworth (former CakePHP Project Manager) and Nate Abele (former CakePHP Lead Developer) are gone. They realized they had enough Nuts over the years and they decided to switch to a more Lithium-rich diet. More helthy and depression-proof, too!

Stupid metaphors and painful jokes aside, this is probably the best piece of news the CakePHP community received in a long time: the birth of a fork of the CakePHP framework, more precisely of the so-called Cake3 branch.

Cake3? I didn’t keep up-to-date with the buzz, so I didn’t know anything about this until today, when I decided to finally start catching up.

“Cake 3.0, on the other hand, is pretty different from the existing core code in a few notable ways. Mainly, it’s been re-written from the ground up for PHP 5.3.”

from Cake 3 interview with Nate Abele, debuggable.com

Of course, in these three years of my full immersion in the Ruby language, I almost completely forgot about PHP too. PHP 5.3 means namespace and closures, i.e. the Rubyist’s daily bread. A more modular CakePHP, properly object-oriented, with an ActiveRecord-like API for models (finally!) is definitely worth a look, especially if it’s Nut-free as well.

The new framework will be called Lithium (sounds more professional already), and it’s due to launch next monday, here: http://li3.rad-dev.org/ (at the time of writing, this link is password-protected).

Personally, I am very excited about this new project. It should have happened three years ago, really, but there’s no point in being greedy: the time has finally come. I would like to (pre-)thank Garrett and Nate for their (upcoming) amazing work, I’ll definitely keep a closer eye on it.

An Interview with the creator of the Akelos Framework

2007-07-19T03:02:00Z

I already covered the Akelos PHP framework in the past, but for those who don’t know it, Akelos seems to be one of the few Rails-inspired PHP frameworks still worth mentioning, besides CakePHP and Symphony of course.

I recently has a look at their recently-relaunched community website and I noticed this phrase:

“Being port of Ruby on Rails to PHP Akelos is also optimized for programmer happiness and sustainable productivity”

Bermi Ferrer, Akelos creator, openly admits the framework is a port of Ruby on Rails to PHP, an attempt to help “Ruby on Rails developers who need to code in PHP”, among others. Of course Akelos is not Rails, simply because Ruby is (thank God for that!) not PHP, however I decided to find out more, and I asked Bermi a few questions, which he promptly answered.

There are a lot of frameworks for PHP, perhaps too many: why did you decide to create Akelos rather than using one of the existing ones?

I started coding Akelos back in 2004 for our internal developments. At that time I only found very few frameworks out there like Mojavi and eZ Publish. These frameworks were not my ideal of an Agile development environment, so I decided to brew my own solution.

After reading Patterns of Enterprise Application Architecture it was clear to me the kind of framework I wanted Akelos to become, so I started to implement some of the design patterns from the book into Akelos.

During the summer of 2005 I had a look into other PHP frameworks like CakePHP, PHP on Trax, and Biscuit but none of them was more complete or easier to use than what Akelos was already at that time.

Then I used Rails for one small personal project and immediately found that Akelos interfaces, conventions and philosophy were close to the Rails approach. Rails ActiveRecord implementation was impressive, better than mine and much much better than other existing PHP implementations, so I first ported the ActiveRecord code using PHP AdoDB as the database abstraction layer.

After that point, whenever I had a problem to solve while coding my customers applications I turned to Rails and they usually had the most elegant solution available. So I did like the idea of digging into Rails code to learn more Ruby and bringing Rails magic to the PHP world. It also helped the fact that Rails inline documentation is excellent so it could be easily adapted for Akelos.

What’s new since last time I posted about Akelos?

The biggest change is the direction that the project has taken. Until now we have not dedicated time to promote Akelos, we just used it for our internal projects and we have been adding features as needed without a fixed roadmap or advocacy.

Now this has changed. More and more developers are using Akelos and contributing functionalities they miss from Rails. After some serious contribution proposals and many developers telling us how much they like Akelos, we decided to take the time to build a nice community site which includes forums, a wiki, a new tutorial and a screen-cast.

There are also some improvements like:

Sintags, now accepts ruby-like calls to helper methods from the views.
Action Webservice, a component for creating and consuming Web Services easily.
Action Mailer, which allows you to receive and send (directly or in delayed mode) emails from within your application. (this is almost ready to ship)
Acts as tree behavior for Models.
Many performance improvements.
Many small contributions and bug fixes.
Code base reduced from 16MB to 9MB.

From the new site, it seems that Akelos is – or aims to be – a port of Rails for PHP. Is that true? Do you aim to target Rails developers as possible users of the framework in situations in which “they have no choice” but to use PHP instead of Ruby?

Akelos has ported many Ruby on Rails components keeping their interfaces and functionality whenever it was feasible to port the Ruby code to PHP. It might be considered a port in the sense of functionality, but there are some Rails strengths that rely on the Ruby language and that are impossible to port to PHP. However, Ruby developers will find that Akelos is the PHP framework with is the closest to Rails.

On the other hand, many PHP developers have moved to Ruby because PHP lacked a hyper-productive and fun-to-use framework like Rails for building complex applications. That is no longer the case, and those who excel at PHP can start being productive from day one by using Akelos. In this way, Akelos target users are those who already know PHP and need to build complex applications that can run on almost any cheap shared hosting using a solid foundation based on good coding practices and widely accepted conventions.

What Rails features are missing in Akelos?

A standalone webserver like WebBrick, RJS, has and belongs to many through associations, string/number/date extensions and Active Resource.

Ruby-powered features like modules, runtime class overriding and blocks will never be available in Akelos.

Scaffolds in Akelos work by generating code, I found quite useless to enable $scaffold = true; and have magic functionality that you can’t modify, so I decided not to invest my time on that one.

I noticed quite a few generators available for Akelos, do they work as a Rails developer may expect them to work?

The ones that are available do pretty much the same as in RoR.

How does Akelos compare to other similar PHP frameworks like, say, CakePHP? What features does Akelos offer which Cake doesn’t offer and vice-versa?

I’m not aware of Cake’s functionalities. At the time I started porting Rails my feelings about CakePHP were that they missed the simplicity point in favor of architectural discussions that lead to confusing code, but that was long ago.

Akelos (and Rails) do not implement ACL like Cake does, as that is a business logic component that varies too much from one case to other, it has no place inside the framework.

Akelos is built with internationalization in its core. You can even internationalize your Models by prefixing the column name with the locale.

I think that Cake only has an act_as_tree behavior on models while Akelos has Tree, Nested Set, and List. Akelos also implements handy features from Rails like optimistic locking, lazy loading, table inheritance, counters, automatic transactions, really powerful validations, calculations…, and I think most of these advanced features are still missing on Cake, but maybe I’m wrong.

Did you include unit tests for all the framework classes?

The main components are fully unit tested, and no new code or patch gets into the trunk without unit tests.

Did you or someone do any performance test or benchmarks on Akelos already?

During the last month a lot of code was refactored to improve performance with the help of Xdebug, Kcachegrind and ab. We significantly improved the performance in one of our most complex intranet applications, a basecamp-like system.

Akelos also implements caching at many levels, so it’s very easy to increase performance as we did with a new CMS that can handle +200 requests per second using Apache in a cheap shared server environment.

Why should a PHP developer choose Akelos over another PHP framework?

Akelos MVC implementation and workflow are really easy to understand.

In Akelos all the methods and interfaces are thoroughly selected, so whenever you need to do something you just need to type what you think. Default options are selected with care so you don’t need to set any configuration unless you want to modify the default behavior.

Coding multilingual applications, building complex relationships within models, distributing databases changes within your development team, building Ajax interfaces, unit testing your code and many other common tasks for PHP developers are really simple to accomplish when using Akelos.

Akelos is designed to work on PHP4 and PHP5 and it comes with an easy web installer you can adapt for your application. It has functions for working with files and directories in common situations when the web server runs as a different user.

And one of the main reasons for choosing Akelos is that it makes coding fun and lets you focus on solving user problems rather than wasting your time in repetitive technical annoyances. When coding with other developers the convention over configuration philosophy helps everybody to understand exactly how everything works and where to find things.

Is there any website using Akelos already?

The Chemical Brothers new website which has been developed by 3rd Eye Vision (3ev) is using Akelos.

The Akelos.org site is running a CMS named Editam which we will release as Open Source in a near future.

Some small websites like Fundacio Caixa Carlet and many intranet/extranet sites that we’ve been coding during the last 2 years.

What are your future plans for Akelos? Anything new on the way?

A new manual, and a better API interface are the main priorities right now.

Continuing bringing Rails functionality as needed.

Releasing our sister project Editam CMS which will help developers who need to add functionality on the top of a CMS using a solid MVC framework like Akelos.

Akelos is real, after all...

2006-08-01T23:33:00Z

Bermi Ferrer kept his promise, and even if a few were skeptic on the pre-announced features of his upcoming Akelos framework, last week he sent me a “development preview” and a few days ago he opened the development SVN repository to the public:

svn://akelos.org/trunk

Go, get it: it’s worthwhile (see below).

“[…] The Akelos Framework is an open-source port of Ruby on Rails to the PHP programming language.
The main goal of the Akelos Framework is to help programmers to build multilingual database-backed web applications according to the Model-View-Control pattern. It lets you write less code by favoring conventions over configuration.”

At the Akelos Framework Features page you can find detailed information about what has been already implemented into the framework.

I think it says it all, well almost. Some people will undoubtedly be disgusted by yet-another-hopeless-Rails-clone: not again! I hear them crying…

Well, yeah, I think this – to be honest – should be the last attempt someone makes to port Rails to PHP or at least port some features and the overall philosophy, like CakePHP did: there are honestly too many for one single language. Look at Python, Django seems to be the only “Rails-inspired” framework available and everyone is happy with it, while as a general rule PHP folks are never happy with what they already got.

Bermi is undoubtedly one of them, and that’s the reason he decided to code his very own Rails-inspired framework for PHP, which is, to date, the most remarkable of the ones I left out (it wasn’t available at the time) in my article.

Confirmed Features & Contents

So well, although I didn’t really have a proper chance to play with Akelos I can certainly herald some of its – verified, this time – features.

For one, it’s huge. Take Cake, add every excellent, useful third party library or class you can possibly thing of and you’ll get Akelos. No kidding. The unzipped source of the whole framework is a massive 16MB, 8.5 of which constitute the vendors folder. What’s in it? Well, all this:

ADOdb
Domit
FPDF
Excel (reader library)
Hyper Estraier full-text search system
Inutio XML-RPC Library
Many PEAR packages
PHPCodeAnalyzer
PHPmailer
SimpleTest
A Simple PHP YAML Class
Textile

Then, similarly, all the state-of-the-art Javascript/AJAX hyper-hyped libraries are included:

AFLAX
Behaviour
Builder
various Scriptaculous packages
Prototype
FileUploader (by the author, using prototype)
Window
EventSelectors

Good, well, kind of: that’s just what others did, but it’s worth noting that it’s all there and – apparently – integrated with the framework, hopefully not too tightly. But people are fussy, and do not get excited easily anymore, long gone are the early days of Rails, when the whole Internet shake at hearing about code generators… Aye, there are in Akelos as well, of course!

Coming to the more juicy stuff, lo’ and behold, ye contents of /lib folder (with comments):

AkActionController (controller)
AkActionView (view)
AkActionWebservice (Web services)
AkActiveRecord (model)
AkAdodbCache (content caching)
AkCharset (utf8 support, includes all mappings)
AkConfig (load config settings)
AkConverters (conversions!)
- DBDesigner > AkelosDatabaseDesign
- Excel > Array (bi-dimensional)
- Excel > CSV
- HTML > RTF
- HTML > Text
- Word > Unicode
- PDF > Text
- Xdoc > Text
AkHeaders (HTTP headers, redirections)
AkImages (Image operations, resizing)
AkLocalize (Localization, countries and timezones)
AkInflector
AkLogger
AkFtp
AkInstaller
AkRouter
AkZip
…

Well, it’s all there, at any rate. The best way to know if it all works, and how it works, is simply to try it out: www.akelos.org.

Remarks

As I said earlier, Akelos looks like CakePHP on steroids: agreed, the Cake philosophy of “no we-may-use-it code in the trunk” has been completely (and intentionally) ignored, but this is our chance to peek at what CakePHP could have become if such philosophy didn’t become a lifestyle for the Cake Dev Team.
Akelos code is Rails-inspired, so yes, it’s very similar to Cake, although with some rough edges and some re-used parts, but it’s the work of ONE person with no community support (yet), don’t forget. Remarkable.

And he needs co-developers, by the looks of it, so there you are then: there’s your chance!

My personal opinion about it? Well, I think Akelos can learn from CakePHP and vice-versa: a merge? Well, at least it would reduce the number of Rails-inspired framework for PHP and possibly meet the needs of more people: those who want just the essentials, as a framework, and those who like to be virtually almighty and be able to do anything, if they wanted to.

Two flavours of the same framework? CakePHP and cAkePHP (note the case)? Bah, let’s stop raving now, shall we?

Akelos Framework: too good to be true?

2006-06-10T09:26:00Z

Someone recently added a comment to my article about Rails-inspired PHP frameworks pointing out that I forgot another Rails-like framework, in my round-up. He obviously posted a link to this rather mysterious Rails port in PHP and spam or not, I’d like to thank this guy for letting me know of the existance of Akelos, a new PHP framework which seems simply too good to be true.

Let me just spend a few words more before writing more about it though. First off, it’s not available yet. OR at least it doesn’t seem to be: the author is planning to release his work to the Open Source community but… well, he’s a bit concerned about the current “PHP Framework War”: he wouldn’t like to end up like Subway or just be slagged off by those merciless reviewers who enjoy write round-ups and comparisons about frameworks. Bermi Ferrer is “just” a talented PHP developer who decided to create his own framework and he really enjoyed doing so, nothing more, nothing less.

“I considered other PHP ports of Ruby on Rails, but we could not find all we needed on them. One feature that I needed on the core was internationalization and Unicode support, so I decided to roll my own framework trying to keep most of the original rails interface so most of its documentation could work for it.”

Where did I hear that? Nothing new: it’s always the same story of frameworks not being as we want them to be etc., it’s human. And yes, it’s another attempt to port Ruby on Rails to PHP, and a damn good one — or so it seems.

Before proceeding any further, I’d like to write a short warning for a few people who may or may not want to pop in and start commenting about the Rails-is-better-than-any-PHP-clone issue: If I see a single comment slagging off this framework (or any other) only because it’s a port of Rails to PHP, it will be deleted, may it be David Heinemeier Hansson himself. Stop it, no seriously, I think it will be counter productive for Rails in the end: I really like RoR and I love the way it works, and yes, I think Ruby is definitely the best language to do that sort of things, EVERYBODY KNOWS THAT. Please, please, save us poor PHP developers the usual preaching.

Right, back to Akelos now. Curious as I am I immediately checked out the official page and all i found was a pretty long list of features which made me dribble, literally… ooops!

Let’s just quote the most juicy ones, shall we?

Active Record [“Model”]

Associations
Callbacks
Transactions
Finders [ $Project->findFirstBy('language AND start_year:greater', 'PHP', '2004'); ]
Versioning
…

Action Controller [“Controller”]

Filters
Pagination
Mime Type
Mime Response
Code Generation
Response handler
…

Action View [“View”]

Templates (using Sintags)
Web 2.0 javascript using prototype and script.aculo.us
Helpers
Partials
Template Compilers
…

And then more Akelos-only goodies:

Multilingual Models and Views
Locale alias integrated on URLS (example.com/spanish will load the es_ES locale)
Database migrations using DB Designer files
Pure PHP support for Unicode (no extensions required)
Unit Tested source code
Code Generators
Built in XHTML validator
Automated locale management
Clean separation from HTML and Javascript using CSS event selectors.
Ajax file uploads
AFLAX integration
Dojo Rich Text Editor
Format converters
File handling using SFTP for shared host running Apache as user nobody (as most CPanel server do)
Distributed sessions using databases

Impressed? I was, honest. And I’m talking as a CakePHP fanatic here, and I must say that if this framework can really offer all this and — and this is what really matters — is also as simple as Cake to learn and well performing… well, this is definitely going to be quite a promising player in the “PHP Framework War” (but is not a real war, is it?), although the author is quite worried about that:

“I’m also concerned about the PHP Framework war, I don’t want to play that game. Building this Framework was a great experience, it works great for me and it has helped me to become a better programmer so I don’t want to spend my time discussing about if this is better or not than other solutions. That’s the reason I’ll first look for great developers interested in the Framework to help me releasing it.”

Really, this will be an interesting project to check out, once it goes open source, and yes, I really wish Bermi all the best. Good luck, Akelos Framework.

CakePHP hybrids

2006-04-14T07:55:00Z

When I first talked to gwoo, CakePHP’s project manager, I asked him if Cake had any potential limitations. I asked him – I was kidding actually – wether it would be possible to build an application like Gmail using the framework and he – very seriously – simply said “yes, why not?”.
I repeat myself when I say that CakePHP leaves plenty of freedom to developers within the bounds of its MVC structure: once you grasp the basic logic behind it, your possibilities are endless. I don’t want to act as a Ruby on Rails fanatic and boast that you can do anything with CakePHP and things like that, but I can certainly say that CakePHP can be extended and integrated with other collections of scripts, frameworks and projects. With limitations, of course: you probably don’t want to force an integration between CakePHP and another MVC/Event Driven/Whatever framework, simply because it would be rather pointless and potential conflicts may occur.

What I keep finding online is other open source projects adopting CakePHP as backend and structure. I’m sure there are many examples which could be mentioned here, but I chose two in particular: one has been around for a few months and the other is just born.

AMFPHP is quite an interesting project:

“[it] is an open-source Flash Remoting gateway. It’s fast, reliable, 100% free and open-source. Flash Remoting is a technology built into the Flash player core that enables sending data between the server and the client seemlessly.”

In other words, it makes lifes much easier for developers who’d like to integrate their flash animations and script more tightly into their PHP application. If you are curious to see some results, head off to AMFPHP showcase.
Cool, but what has this project to do with CakePHP? Well, gwoo recently created CakeAMFPHP, a CakeForge project which just yesterday reached its 0.4.0 release, and it’s fully compatible with AMFPHP 1.2.3 and CakePHP 0.10 final.
Here’s an excerpt taken from CakeAMFPHP README.txt file:

“[…]
1) get CakePHP 0.10 final (http://cakephp.org)
2) get amfphp 1.2.3 (http://amfphp.org)
3) get the UFO js http://www.bobbyvandersluis.com/ufo/
4) put amfphp into /app/vendors
5) put cakeamfphp into vendors
6) put the cake_gateway.php in /app/webroot
7) put the cakeamfphp.php in /app/views/helpers
8) put CakeMySqlAdpater.php in /app/vendors/amfphp-core/adapters
9) Voila: NetServices.setDefaultGatewayUrl( ‘http://localhost/cake_install/cake_gateway.php’);
Access the service browser through
http://localhost/cake_install/vendors/cakeamfphp/cakebrowser/”

The installation doesn’t seem too painful at all. And – guess what – gwoo recently updated a very informative tutorial showing how to create a simple – but still impressive – bullettin board with CakeAMFPHP.

“Cool, but I never liked flash, what about AJAX?”

CakePHP has a nice AJAX helper to be used in conjunction with prototype, but there are truly a lot of libraries, mini-frameworks, pre-built applications to create interactive desktop-like user interfaces. Some people may already know qooxdoo,

“[…] an advanced open-source JavaScript-based GUI toolkit. qooxdoo continues where simple HTML is not enough. This way qooxdoo can help you implement your AJAX-enhanced web 2.0 application – easier than ever before.”

In a recent discussion on CakePHP user group someone suggested the possibility to integrate qooxdoo with CakePHP. Apparently qooxdoo people were evaluating various MVC frameworks, and Cake was obviously listed together with two other Rails clones for PHP. The good news is that 100rk just started a new project called CQX, which – although still in pre-alpha a development demo is already available, and it shows off most of qooxdoo’s features… Take a look

Best of luck to 100rk and his brand new project, I really hope to see more of it soon!

A look at Drupal

2006-01-12T06:42:44Z

Important Notice: This article is about changes occurring to zZine Magazine's site[1]. At the time of writing, www.zzine.org uses the old site, and not the Drupal-based one presented in this article, which is currently under construction[18].

"Why can't we log who edits the articles?"
"Can we send newsletters?"
"We should really have a members' area..."

zZine.org[1] is a scratch-built site, coded from the ground up to offer zZine journalists, editors and readers all the functionalities and features they wanted. I'm not totally against sites being coded from scratch, but what happens if something needs to be fixed, or new functionalities have to be implemented and you realize that the code cannot be extended or patched easily?Case Study: zZine Magazine

zZine Magazine is an online magazine which publishes not only IT-related and other articles on a weekly basis, but also monthly publications containing CyberArmy[2] digests, special columns, and featured articles. A team of journalists, researchers, editors, publishers and outside contributors has access to the zZine site to write, submit, and edit articles, manage publications and perform various other tasks through a password-protected administration area. This is common to approximately 75% of the websites on the Internet: they have a front-end to present content to the general public and a semi-hidden administration backend which is normally more difficult and tedious to code. That's why someone started developing Content Management Systems[3]: ready-made, fully-featured administrative back-ends for creating and managing almost any kind of website, from blogs to eCommerce portals.

Could a CMS be used for zZine Magazine? Probably - zZine doesn't need any innovative or advanced features, just a bunch of commonly-used functionalities like:

Add, delete, edit and publish articles
Customizable user permissions, ideally role-based

Creating and managing monthly publications
Editor's tests
User signups, notifications, etc.
RSS feed generation
Sending newsletters to subscribers
Logging user actions

Some members of my team raised some concerns regarding the usage of a CMS, which were mostly based on our past experience with just a particular product and not CMSes in general. Everybody agreed that if we were to go back to a CMS, we had to choose the best this time: something flexible, easy to use, fast, search-engine friendly, and extensible. I spent some time researching CMSes, because while I knew that there's no such thing as the best CMS, there was certainly a CMS that was best for our needs.

Making the right choice

In the past, I had played around with Xoops[4] when I first thought about creating websites, and I used Mambo[5] for some other sites. I admit that I never actually spent time creating complex Mambo components and modules, but I must say that in the end I felt somehow tied to third-party modules and unable to understand how they really worked: Mambo seemed to give developers too much freedom, and had neither a solid API nor conventions to follow, at least when I used it.

So I decided to have a look around again, starting from the two most important sites people should look at when choosing the most suitable CMS for their work.
The first site is CMS Matrix[6] which - as the name implies - provides a really handy matrix, or chart, to compare the various features offered by nearly all CMS available, both proprietary and open-source.

I remember choosing Mambo last time I used the matrix simply because it appeared to be one of the most feature-rich. This is actually something not to do when choosing a CMS: always concentrate on what your site needs rather than what the CMS is able to offer. Otherwise, you run the risk of having too much to work with.

The other important website to visit when choosing a Content Management System is OpenSourceCMS[7], which basically allows you to try a demo of every open source CMS online. This is perhaps more useful, but also much more time-consuming: it's better to narrow down the list of possible CMSes after checking CMS Matrix and then try each one rather than just picking one at random.

At this point, an experienced CyberArmy staff member[8] suggested Drupal[9]. I asked her why, and she simply said that it seemed to be the best choice according to zZine's needs, as it basically offered all the features we were looking for, either natively or through modules. She also admitted to be biased, as she's actually part of Drupal's documentation team and involved with Drupal development[10].

Before making any kind of commitment, I checked out Drupal's website to see how they organized things, and I was quite impressed. I immediately noticed the Handbooks section[11], which contains all the official Drupal documentation and it seemed pretty much complete. No "under construction", "please write content here" or "we're a new project, help us write the documentation" notes, just a load of good-quality documentation, including a fully documented and stable API![12]

This surprised me, because some projects I came across, even really good ones, lacked a proper documentation section. I think this is a common problem with new open source projects, and Drupal for this reason gave me the impression to be quite mature and useable already. After visiting the very clear and organized Downloads Section[13], I downloaded the CMS and a few modules and installed it on my laptop.

Installation

Drupal needs three things to run:

A web server - Apache is fine, and ISS is reported to be working
PHP - Either version 4 or 5, Drupal started supporting PHP5 since 4.6.0 release
A PHP-compatible database - MySQL or PostgreSQL is recommended

I used a WAMP[14] installation to test Drupal. First of all, I created a MySQL database, granting ALL privileges to the database user accessing the Drupal database. When I uploaded the site to the remote server, later on, I had some problems because the LOCK TABLES privilege wasn't granted by the host. Drupal requires this, so I had to contact my host to solve the problem. I then imported the database scheme located in the database directory under the installation directory and modified the configuration settings (sites/default/settings.php) to allow Drupal to access the database. Installation complete.

Drupal was now up and running with the default configuration settings, with a minimum of fuss. For all the details concerning the installation process, consult the exhaustive documentation.[15] I didn't read it when I installed it, but it can really be useful in some situations.

There are actually two non-critical things to consider if you're planning to use Drupal for a medium-sized project: the first involves changing a few settings on php.ini, in particular increasing the amount of memory allocated to PHP from 8MB to 16MB, especially if you're planning to use either a lot of simple modules or a few complex ones, and the second is setting up your crontab to execute http://www.yoursite.com/cron.php every hour or so. This is required by some semi-essential modules like the site-wide search, but a common alternative (if you don't want to setup the cron task manually) is the poorman's cron module[15], which I used myself and found to be workable.

Keeping your site under control

Perhaps one of the best things Drupal has to offer is a rock-solid general-purpose administrative backend. The first thing I found in the backend which really impressed me (and that also I never found in another CMS) is the ability to create custom role-based user accounts and access permissions for everything: every module can be configured so that, for example, not all people can see its output and just a few can administer and modify it.

For zZine, I created four types of accounts:

Administrator

Publisher

Editor

Writer

These were precisely the account types I was looking for in a CMS. Granted, other products offer them by default, but having pre-defined account types is one thing, and being able to customize them completely is another.

User accounts are great, but sometimes it's good to know what the users of your sites are doing as well. On our old site we had user accounts for editors and administrators, and even if only a few people had access we had no way to determine who edited an article or who published something unless that person told us. Drupal comes with a radical solution to this: Almost every action is automatically logged by the watchdog core module. Every website error, every page not found, and every PHP or MySQL error is logged, as well as every content submission or modification. Page accesses, meanwhile, can be logged through the statistics module.

Themes & Templates

"We shouldn't use a CMS: I don't want zZine to have the overly used *nuke-style look." I've heard this too many times. Sometimes people associate the word "CMS" with "lack of original design", and that's not true by any means, especially for Drupal. Of course, there are plenty of ready made themes[16] which can be freely used or modified for any Drupal-based site.

I must confess that when I first saw the themes section I feared that Drupal "themes" used their own template engine, like some CMSes do nowadays, but I was wrong: currently Drupal supports some template engines[17] but also pure PHP-based ones. Theme engines do their job wonderfully and can offer some interesting features, but templates written natively in PHP tend to perform better, simply because there's no extra parsing or additional overhead involved.

I decided to have a look at a standard PHP theme. Basically, it's nothing more than a PHP-enriched xHTML file and its corresponding stylesheet. There are a few functions which must be used to perform particular tasks, like showing the main navigation links, but nothing too hard to understand. It's also very customizable. In fact, we're already working on a custom zZine theme, which doesn't seem any harder than coding a standard xHTML template. As design should always be the last thing to worry about, I decided to use a temporary template I created by slightly modifying an existing one.[18]

To switch or not to switch?

When creating a new site for an organization which already has one, there's something very important to consider: what happens to the old data?
Assuming the old site was dynamic and using a database of some sort, there are three possibilities:

Don't bother doing anything: any data on the old site will not be transferred to the new one.
Make the old website available somewhere else as an

archive

Import all the data from the old site to the new one.

Obviously we went straight for the third one, which is the most difficult to implement, but it was necessary: there were over 1000 articles on the old site-

Of course, in reality, I didn't even mention the possibility of using Drupal until I figured out a way to import the old data into the new database structure. Never praise features or convince people to switch unless you're 100% sure you can handle the situation. Luckily for me, it turned out that everything could be imported easily enough.

The first difference I found between Drupal and zZine was that we didn't really have proper user accounts. Every article had an author, but it was stored as a field in the article's record, and that was all. Drupal, on the other hand, supports (and perhaps requires) user accounts - everything present on the site must be written or edited by an existing user.

The solution I cam eup with was rather drastic: I created about 120 user accounts, retrieving usernames from the articles and inserting them through a custom PHP script into Drupal's user table. Of course, those users never registered on the new site[18], so I didn't personalize the accounts at all: I simply put a notice on the first page asking everyone who contributed to zZine before to contact me in some way to enable their account with a valid email address.

After this initial difficulty, importing articles was relatively easy. Pretty much every type of content in Drupal is, in its simplest form, a node. Nodes have a title, which is a teaser generated automatically from the body text, and an author (the node table in the database has more fields, but these are the key ones for us). Essentially, Drupal's two default models for writing stories and pages write data to this table only. The most important thing to understand about Drupal is that almost every module used to create something on the site - an article, a blog entry, even songs - will use the node table, and add everything else on other tables. This makes the whole system much easier to administer: every node can potentially be extended in any way by third party modules!

What about categories? Well, Drupal has become famous for its taxonomy module: whereas most CMSes only support, or in fact impose, a one- or two-level hierarchy for categories, Drupal's taxonomy module supports the creation of as many different terms to describe data as you can think of. Each piece of content (categorization can be applied to any node, and since almost everything is a node-) can belong to none or n different categories, which can be nested in a n-level hierarchy. Since the zZine articles were already divided into categories, I imported all of them directly into Drupal. On the old zZine site, every article could have at most one category, which is fine, but it's good to know that we can now configure the system to support a more advanced categorizing system.

After importing the articles, the last important thing to transfer to the new site were the zZine Publications. Publications are what we call the article collections that we release as an issue every month. I could have created a new module for this, and it wouldn't have been that hard, but there was already an excellent module for that. This was pure luck, but the epublish[19] module seemed like it was tailored specifically for our needs.

Drupal API and Modules

We were lucky enough to be able to use existing modules for the main functionalities of our site, but in some cases you might not be able to find exactly what you're looking for.

In our case, even if we could have used the story module, which is part of the default installation, for zZine articles (stories have a body, a teaser, a title and an author, exactly like our articles) we decided not to. I wanted our editors and writers to know what to use when submitting articles, and the name "stories" sounds a bit too ambiguous for my liking. So, I decided to have a look at the standard story module to see how modules work, and create something similar.

Note: I'm curious by nature and I didn't read anything in the Drupal API[12], or about developing custom modules; I looked at the story module without any prior knowledge of Drupal's conventions.

All I found in the story module was a bunch of functions like:



/**

 * Implementation of hook_node_name().

 */

function story_node_name($node) {

  return t('story');

}

which seemed to be enough to tell the Drupal core what to do. I was used to Mambo components, where developers have more liberty to do what they want, including outputting HTML code anywhere. Drupal is nothing like that; on the contrary, it has its own structure and coding conventions that developers have to follow when creating custom modules. Even if a simple function like the one above is fully commented, it has to have a standard indentation (two spaces) and an obviously standardized name. I noticed that all the functions similar to this one started with "story_", so I created a new file named zzarticle.module, copied and pasted the story module code into it, and changed every function accordingly, like this:



/**

 * Implementation of hook_node_name().

 */

function zzarticle_node_name($node) {

  return t('zZine Article');

}

Trivial enough, and it worked fine! I put my shamefully copied module in the /modules directory and I was able to create "zZine Articles" (which were nothing but stories with a different name).

At this point I decided to have a proper look at the API, and read about hooks:

"Drupal's module system is based on the concept of "hooks". A hook is a PHP function that is named foo_bar(), where "foo" is the name of the module (whose filename is thus foo.module) and "bar" is the name of the hook. Each hook has a defined set of parameters and a specified result type.
To extend Drupal, a module need simply implement a hook. When Drupal wishes to allow intervention from modules, it determines which modules implement a hook and call that hook in all enabled modules that implement it. [-]"

A hook was used for the previously mentioned function, and this was diligently commented:



/**

 * Implementation of hook_node_name().

 */

This made me understand how Drupal is actually geared towards developers and at the same time suitable for non-technical users. Wait a minute, what if someone is not familiar with PHP and still needs custom modules and features? Is there any way to extend Drupal without having to physically code new things? Yes, there is, and two modules come to mind:

Webform

Flexynode

flexynode

Conclusions

For now I must say I'm very happy with what Drupal has to offer, and if there's something we need for the site, we can code it ourselves and then integrate it into Drupal.
One of the major strengths of this CMS is definitely its developer-friendliness: while other CMSes mainly focus on users at the price of limiting extensibility and trapping developers into predefined modules, Drupal even encourages developers to integrate their code into the existing structure, opening virtually unlimited possibilities. Granted, it may seem difficult to understand at first, some people I talked to told me that 'Drupal is too complex' or has a rather steep learning curve, but I just think everything becomes clearer after reading parts of the vast documentation section: this is the only price to pay, and believe me, it is definitely worthwhile.

Notes
[small]
[1] zZine Magazine: http://www.zzine.org
[2] CyberArmy Community: http://www.cyberarmy.net
[3] Content Management System, Wikipedia page: http://en.wikipedia.org/wiki/Content_management_system
[4] Xoops - Official Page http://www.xoops.org/
[5] Mambo - Official Page: http://www.mamboserver.com
[6]CMS Matrix: http://cmsmatrix.org/
[7] Open Source CMS: http://opensourcecms.com/
[8] Snarkles's CyberArmy Profile: http://www.cyberarmy.net/~snarkles
[9] Drupal - Official Page: http://www.drupal.org
[10]Webchick's Drupal Profile: http://drupal.org/user/24967
[11] Drupal - Handbooks: http://www.drupal.org/handbooks/
[12] Drupal API: http://drupaldocs.org/api/head
[13] Drupal Downloads: http://www.drupal.org/project/
[14] WAMP Server Package: http://www.wampserver.com
[15] Drupal - Installing and Upgrading documentation: http://drupal.org/node/258[/url]
[16] Drupal - Themes: http://drupal.org/project/Themes
[17] Drupal - Theme Engines: http://drupal.org/node/509
[18] zZine Beta site: http://beta.zzine.org
[19] Drupal - ePublish module: http://drupal.org/project/epublish
[20] zZine Podcasts: http://beta.zzine.org/podcasts
[/small]

Easy-to-install server packages

2005-06-28T20:12:19Z

The first and most obvious difference between, say, a C++ programmer and a PHP developer is that the PHP developer needs a server with PHP support up and running somewhere in order to "show" others that the application is working. This normally means that a PHP developer must either have remote access to a server, or have one set up on his machine. Installing and configuring a server can be tricky sometimes, especially if you want to configure it "properly", but in some cases - for Linux/BSD users mainly - there are some pre-configured servers you can download and install.

I won't examine all these methods in this article, but I'll describe three alternatives for installing and run a webserver on windows in 10 minutes or less.

Preliminary considerations
Let's assume that you just want to have a server set up on your computer for internal use only, for testing purposes. That means that you wouldn't need to be concerned about "security" or similar issues - you just want to be able to run your PHP scripts and access your database(s) quickly and easily.

As I said earlier, Linux users would probably opt for some package available for their favourite distros - they would only have to download and install an .rpm or .deb package for (presumably) Apache httpd, PHP and MySQL, and just use a basic configuration. There are other tools around which can help if you want to compile or configure Apache, but that is beyond the scope of this article.

Let's just focus on Windows users, then. Normally they like things that are easy to install and can be configured in a few minutes maximum or not at all. Finally, let's assume that as a Windows user, you don't want to spend more money for a new operating system with a bundled server, like Windows 2003, because you can use Apache on Windows as well, for free. Having said this, I actually found 3 possible solutions that are handy for PHP (or Perl) developers who don't want to spend time learning how to configure a server. There are people like that, including myself to some extent.

WAMPserver
WAMP stands for "Windows Apache MySQL PHP", and I must say that this product happens to be my choice. The current version, available at the time of writing, offers:

- PHP 5.0.4
- Apache 1.3.33
- MySQL 4.1.10a
- phpMyadmin 2.6.1-pl3
- SQLitemanager 1.0.4

This is basically a fully working PHP5 environment, with other tools like phpMyadmin to administer your MySQL database even more easily (more laziness!), and, if you're into the new functionalities of PHP5, it also comes with sqlitemanager, a php application similar to phpMyAdmin but for sqlite databases, which are supported by default in PHP5.
You download it, you start the installation program, and it's DONE. That's it. In 5 minutes you have your own little apache/php/mysql(ite) environment up and running and you can start showing off your sites to your friends and co-workers right away.

The program also installs two services which can be run at startup, a little icon in the system tray to access all the tools and, of course, http://localhost in your favourite browser.

If all this is still not enough for you, and you want more things more easily, you can install addons to set up PHP4 (and seamlessly switch between the two with a single click!), Perl, Zend Accelerator, and so forth.

EasyPHP
The second suite I will briefly describe is EasyPHP. This is a French project (like the previous one, actually), which offers PHP4, MySQL and Apache, plus phpMyAdmin to administer the MySQL databases. However, it doesn't offer PHP5 support yet (so it's not my favourite) and thus there's no sqlite support either.

Apart from that, it works exactly like WAMP: you download it, you install it, and it's done. Services are installed and you have - again - your little icon on the system tray to access all its functions and tools. It works well, but it doesn't seem to have any add-ons available like WAMP does.

XAMPP
This is by far the most complete distribution of the three I am focusing on. This project is developed by Apache Friends and has a lot of features and flavours. XAMPP currently includes:

- Apache HTTPD 2.0.54
- MySQL 4.1.12
- PHP 5.0.4 + 4.3.11 + PEAR + Switch
- MiniPerl 5.8.6
- Openssl 0.9.7g
- PHPMyAdmin 2.6.2-pl1
- XAMPP Control Panel 1.0
- eAccelerator 0.9.3
- Webalizer 2.01-10
- Mercury Mail Transport System for Win32 and NetWare Systems v4.01a
- FileZilla FTP Server 0.9.8a
- SQLite 2.8.15
- ADODB 4.63
- Zend Optimizer 2.5.7
- XAMPP Security for Windows 98, 2000, XP

Honestly, you can't ask for more! If by chance you want to run this suite on other platforms, there's a version for Mac OS X, Solaris, and even Linux.

The installation method for XAMPP is slightly more difficult than the other suites - you actually have to download and unzip it in a folder of your choice. Then you're off and running.

Unfortunately (or fortunately), there's no icon on the system tray, so you need to actually access http://localhost to get a list of services and tools. It also doesn't come with sqlitemanager, but you can download it and install it in the documents folder (like I did).

I actually use XAMPP - the "lite" edition, which is smaller and has less features - for my USB drive. Since it doesn't require any services to be installed in order to run, you can simply copy it onto a USB stick and run it from there!

Conclusion
I'm quite impressed by all of the server packages I reviewed; WAMP and XAMPP in particular. I can now carry around my websites and applications and instantly run them or show them to anyone who has a computer with a USB port.

As I said in the beginning, these programs are NOT meant to be used in a production environment or to be accessed publicly, therefore, security is not a consideration here. In my opinion, they are simply excellent for testing purposes, and for now, that's what I need them for.