Using external PHP libraries with the Yii framework

July 11, 2009

Yii is an easy to use and flexible PHP5 framework. It comes with all essential functionality needed to quickly create any sort of web application. Because Yii is not intended to be an all-in-one solution, you can easily extend it to fit your needs. On the Yii web site there are several extensions available.

But you are not restricted to the use of Yii extensions. If there is an existing library out there you like, use it.

  1. Create a vendors folder in your application folder:
    protected/vendors
  2. Copy your libraries to the newly created vendors folder.
  3. Add the folder to your include path in your configuration file (protected/config/main.php):
    ...
    'import'=>array(
      'application.models.*',
      'application.components.*',
      'application.vendors.*',
    ),
    ...
  4. Yii uses the autoload functionality of PHP to automatically load scripts. For this to work in Yii, the file name must be equal to the class name. So for example, if you want to use Simplepie the script file must be named protected/vendors/Simplepie.php.

    You can then simply create an object in any controller with:

    $feed = new Simplepie;

    Simplepie uses the idna_convert class for international domain names. This class must also reside in the protected/vendors folder

But that is not all. You can also use library collections, like Zend Framework or eZ Components, that utilise PHP's autoload. And you can use them at the same time using spl_autoload_register().

The easiest place to register the libraries is in the entry script. This way they can be loaded from any controller.

  1. You first have to unregister Yii autoload, because Yii raises an error if a class isn't found.
  2. Next step is to include the autoload scripts and register the autoload functions of the libraries.
  3. The last step is to register Yii autoload again, so everything works as before.

The final entry script (index.php) will look like this:

<?php
$yii='/path/to/yii/framework/yii.php';
$config=dirname(__FILE__).'/protected/config/main.php';

require($yii);

// unregister Yii autoload
spl_autoload_unregister(array('YiiBase','autoload'));

// register Zend Framework
Yii::import('application.vendors.ZendFramework.library.*');
require('Zend/Loader/Autoloader.php');
spl_autoload_register(array('Zend_Loader_Autoloader', 'autoload'));

// register eZ Components
Yii::import('application.vendors.ezcomponents.*');
require('Base/src/base.php');
spl_autoload_register(array('ezcBase', 'autoload'));

// re-register Yii autoload
spl_autoload_register(array('YiiBase', 'autoload'));

Yii::createWebApplication($config)->run();

Now you can create any object without worrying where the class scripts are located.

Moving Apache rewrite rules from .htaccess to VirtualHost

June 2, 2009

Using the concrete5 CMS with pretty URLs for a website, I broke it after moving the rewrite rules from .htaccess to the virtual host. Although I use Apache mod_rewrite quite often, I keep forgetting that there are subtle differences between a .htaccess and VirtualHost context. Basically it comes down to relative vs. absolute paths.

For .htaccess concrete5 uses the following rules:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]

For the virtual host I had to change them to:

RewriteEngine On
RewriteRule ^/$ /index.php [L]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php/$1 [L]

Hopefully I will remember it the next time.

Using pretty URLs in concrete5 with Cherokee

May 11, 2009

Concrete5 is a very easy to use content management system (CMS). By default concrete5 produces URL's like http://www.walterebert.de/index.php/en/home/. But the index.php in the URL does not contain any relevant meaning. Luckily you can remove it from the URL by activating the "pretty URLs" setting. You will have to use URL rewriting to make it work. Concrete5 automatically shows you which code you have to apply. Unfortunately these are only valid for the Apache web server.

Recently I discovered the Cherokee web server. It is very fast and has a web interface that makes it easy to configure. Problem is that the Apache rewrite code cannot be used. So I had to configure Cherokee to make it work.

Cherokee uses handlers and behavior rules to tell it what to do. To make the URL rewriting work with concrete5 you have to change the handler for behavior "Default" from "List & Send" to " Redirection". Then you have to define the rule to apply. Select "Type > Internal". Then insert ^/(.*)$ under "Regular Expression" and /index.php/$1 under "Substition" .

screenshot of redirection rule in cherokee interface

But now every request is redirected, including all static files such as images. So you have to define handlers for directories and files that need to be accessible.

To do this you have to add behavior rules. Directories that need to be defined are /concrete, /themes and /files. For these directories you should choose rule type "Directory" and handler "Static content".

For files you select the rule type "File exists" and handler "Static content" and add the files that need to be ignored by the rewrite rule.

Make sure that the php rule is listed above any static content rules (you can drag & drop them). Otherwise php scripts won't be processed for those rules and send as static pages with the full source code.

screenshot of behavior list in cherokee interface

Now concrete5 is good to go!

[Update] Cherokee now provides a configuration wizard for concrete5

Deciding what blog software to use

April 11, 2009

Reading blogs is a good way to keep track of what is happening on the Web. But I haven't got round to start writing one for myself. So deciding that this must change, I had to look how to run a blog.

Already having a web site and doing the design and programming, I didn't want to use a hosted blogging service. So I started to look around for software I could use.

Some of the requirements for me were:

After some (shallow) research I came up with the following shortlist:

Wordpress is an obvious candidate and it seems like everybody is using it. But it uses old style PHP programming techniques, so it won't brake plugins and you are still is abled to run it on outdated PHP versions. More specifically it relies on "register globals". This is disabled by default in current versions of PHP for good reasons. Being backward compatible is of course a sensible thing to do for the Wordpress developers. But in this case I rather like to use new technology.

Serendipity and PivotX looked promising, but both use the Smarty template engine. I don't like Smarty and I am not the only one. The most important reason for me is that it always feels like you are using a template engine that tries to recreate PHP inside PHP.

Habari is a new kid on the block, to me at least. The interface is very clean. Actually to clean for me at first. It made me wonder if it was really that powerful. Luckily there were some screencasts for Habari to explain how it works. Watching the screencasts actually made me decide to start using Habari. So here I am.

Next step will be customising the design and maybe even start writing some plugins.