Here’s a little trick I just saw on Twitter that will let you tweet upside down. All you do is go to this website and enter the text that you want to flip and reverse:

http://www.revfad.com/flip.html

¡ǝldɯıs ʇɐɥʇ s,ʇı
It’s that simple!

Follow us on Twitter: @AWPNY

I recently had trouble getting CakePHP running properly in a subdirectory on the Mosso cloud. The main site URL is http://thinkandthrive.com, and the Cake app lives in a folder off the site root called “tw”. So I was able to connect to http://thinkandthrive.com/tw/, but not to http://thinkandthrive.com/tw (without the trailing slash).

The fix to get Cake working in the subdirectory was to add a single line to the .htaccess file in the Cake root directory ( the “/tw” folder in my case). The .htaccess file should look something like this:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule    ^$ app/webroot/    [L]
RewriteRule    (.*) app/webroot/$1 [L]

Add this line after “RewriteEngine on”:

RewriteRule /YOURCAKESUBDIR$ /YOURCAKESUBDIR/ [L]

Obviously, replace “YOURCAKESUBDIR” with the subdirectory your Cake app in running in. So my .htaccess file now looks like this:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /tw/
RewriteRule /tw$ /tw/ [L]
RewriteRule    ^$ app/webroot/    [L]
RewriteRule    (.*) app/webroot/$1 [L]

(The third line, “RewriteBase /tw/”, is necessary to get CakePHP working in the Mosso hosting environment. If your Cake installation is at the server web root (the Mosso “content” directory) then it should read simply “RewriteBase /”. If your site is not hosted at Mosso just eliminate this line.)

Thanks to Jeff Loiselle for the quick fix: http://jeff.loiselles.com/wordpress/?p=22

Whew, been a while since I’ve posted something useful.

Hopefully, everyone is aware of MySQL transactions and how useful they can be.  They come in especially handy when you want to save multiple related entries into different tables in your app.  Cake actually already uses this in a behind the scenes way with the Model::saveAll() function, which does some of this for you (you can read more about saving your data with saveAll() here).

But you can easily use Transactions for anything you want to do.

Note: for this to work at all you have to make sure whatever table you’re using transactions with are of the type InnoDB, and not the standard MyISAM type.

ALTER TABLE table_name type=InnoDB;

Ok, in your model, set the variable:

var $transactional = true;

Then, in a function you want to use transactions, call the datasource object:

$db =& ConnectionManager::getDataSource($this->useDbConfig);

Then, before you start interacting with the database, you call:

$db->begin($this);

If your action is successful, run:

$db->commit($this);

Or, if there’s a failure, you can roll back your DB with:

$db->rollback($this);

Note that your DB will automatically rollback if there’s not a commit() command anyway.

In the course of a Model class, the usage of these functions could look something like this:

class YourModel extends AppModel {

var $transactional = true;

function someCoolModelAction()
{

  # Grab DataSource Object #
  $db =& ConnectionManager::getDataSource($this->useDbConfig);

  # Start Transaction #
  $db->begin($this);

  /* SQL or Model Functions for whatever you need to do go here */

  # If your database interaction was successful, then commit the changes to the Database ( I'm assuming there is some boolean
  # variable, $successVar, that describes whether the action was successful or not).

  if ($successVar === true) {
       return $db->commit($this);
  } else {
       # If it wasn't successful, rollback any changes and you're good #
       $db->rollback($this);
       return false;
  }
}

}

As you can see, it’s pretty easy. And cool.

I’ve been wrangling with the Cake’s Security Component for the past day, not having the best time with it. If you’ve been trying to use it, you may have noticed that there seems to be near-total lack of documentation on it. Not cool.

So I was trying to use it to make some simple HTTP Authentication requests for a WebTree site of ours. It turns out that whenever the Security Component is initialized in a controller, it requires that all POST-ed data in that controller be validated through the Security Component. For this to work correctly, and not spit you out into a blank page “black hole,” you have to use the Form Helper for every form that needs to be submitted, making sure to use $form->end().

It looks like the Form Helper builds a Hash number based on the name of the fields included in the form and the Security Salt that you set in the config/core.php.

When the form is submitted, a function, __validatePost(), runs automatically, there is currently no way to turn it off, and tries to make the same hash value as all the fields present in the Controller’s $data variable. If the two hash values are the same, we know that no extra data is being submitted directly to the controller, and we proceed with the normal course of things. If they don’t match, we trigger the Black Hole callback function, and go down that route.

Except that in the current RC2 release (7296), there is a bug in the Security Component that will ensure that these two hashes will never be equal.

The problem is in line 662 of /cake/libs/controller/components/security.php:

$check = md5(urlencode(Security::hash(serialize($field) . Configure::read('Security.salt'))));

Should be:

$check = urlencode(Security::hash(serialize($field) . Configure::read('Security.salt')));

Take out the md5() function. Form Helper’s security function that generates the form’s hash value does not include the extra md5 hashing function. It looks like this was fixed in the nightly build.

This will alleviate some of your potential issues using the Security Component. However, if you just want to use some aspects of the component, such as HTTP Auth, there is no way to disable the POST validation, much to my chagrin. Maybe it will change in the future.

Ahh, yes. The shared pain/annoyance of upgrading Cake from RC1 to RC2 and finding that the SQL operator syntax has changed.  Sure it’s more sequre, sure it’s not as elegant looking, and sure there seems to be zero backward compatibility, but yeah, it happens.  It’s still a pre-release.  We deal.

So for those that currently use iano Iglesias’ super-helpful Sluggable Behavior, make sure to change line 121 from:

$conditions = array($Model->alias . '.' . $this->__settings[$Model->alias]['slug'] =>' LIKE ' . $slug . '%');

to:

$conditions = array($Model->alias . '.' . $this->__settings[$Model->alias]['slug'] . ' LIKE '=> $slug . '%');

The current version, 1.1.36, does not include this fix for Cake RC2. Without this, you’ll start getting duplicate slug values, lacking any numerical appending action.