Category: Lithium

Lithium Problem on Rackspace

Today I came across a situation where I was deploying a PHP-based webapp written in Lithium and running on a Rackspace cloud site. In my scenario, I noticed 2 symptoms (appearing differently, but having the same cause).

  1. if the Lithium app is a subdirectory of another webapp (in my example, the main site is WordPress), you will always get a WordPress “Oops! The page you are looking for does not exist.” error.
  2. if the Lithium app is in the root, you will get an “Internal Server Error” page.

As it turns out, the problem is the .htaccess file included with Lithium.

I don’t think there’s anything wrong with the .htaccess per se, but under Rackspace you seem to have to include the “RewriteBase” directive.

So, as a result, you must edit all 3 .htaccess files in your Lithium project thus:

  • /.htaccess – RewriteBase /
  • /app/.htaccess – RewriteBase /app/
  • /app/webroot/.htaccess – RewriteBase /app/webroot/

If your webapp is a subdirectory, this subdirectory name will need to prepended to RewriteBase path:

  • /.htaccess – RewriteBase /subdir/
  • /app/.htaccess – RewriteBase /subdir/app/
  • /app/webroot/.htaccess – RewriteBase /subdir/app/webroot/

And presto, it now magically works!

Lithium Filters – What’s the Point?

I’ve used Lithium for 2 projects now, and I have one major issue – I honestly don’t see the benefit of “filters” vs. “callback” methods.

I understand that conceptually it’s supposed to “decouple” the filter logic from the model itself. However, every example of applying filters to Models show the filter being applied to an individual model directly using the 2 methods below:

<?php
class MyModel extends \lithium\data\Model {
    public static function __init() {
        // ...
        static::applyFilter('save', function(...) {
            // ...
        });
    }
}

or

<?php
class MyModel extends \lithium\data\Model {
} 
MyModel::applyFilter('save', function(...) {
    // ...
});

In my humble opinion, neither of this is “decoupling”, since the actual code for the filters exists directly within the model itself anyway.

One would think you can overcome this my applying the filter to the “Model” class directly – WRONG! The filter never fires.

So, since I have a filter which is shared, I created a method in some other class which my individual filters call. How is this any different than simply having a callback which invokes the external method, too?

No – to me filters are thus-far fairly useless in the Model context (I’ve successfully used it on the Dispatcher).