As part of that, a way of storing “meta” information was needed, that is information that was unique to a venue or type of venue that not all would have, much like WordPress lets additional information about a post be stored in a separate table which makes, say, adding an ISBN number field to book reviews easy.

After rolling our own for several projects, Felix Geisendörfer’s Expandable behaviour was chosen because it was simple to set-up and use and it just worked. Hopefully CakePHP at some point includes a similar functionality as an “official” add on much like virtual fields was added in CakePHP 1.3

Which leads to a “gotcha”….
One issue combining virtual fields and the Expandable behaviour is that virtual fields can end up being interpreted as new fields by Expandable and Expandable then saving them. What’s worse, is that when the table entry is loaded, the virtual field and field from Expandable are combined with one overwriting the other.

This particular behaviour happened when we added a way of cloning venues, removing and replacing certain information along the way. The reason for this would be adding a chain store location; the address and phone number would change but the description or products sold probably wouldn’t. Now the table that stored the venues had a virtual field, full_name, that contained the name and sub-name of a venue (e.g. “Joe’s Bar”, “and Delicatessen” as “Joe’s Bar and Delicatessen”) which Expandable saw as a new field and saved the virtual field to its table and led to about 20 minutes trying to figure out if there was some kind of weird caching issue going on.

Anyways, the fix was to turn off the virtual fields like so:
$this->Venue->virtualFields = false;

…and that was the end of that problem.

If you haven’t, check out Edward A. Webb’s original post from 1998 2008.

This same technique can be used in the bootstrap.php file for other settings that change based on the server, for instance GoogleMap keys:

However, when baking a model, the database file only defines two types: prog and test so you pick one and end up with a model file with a line like:

in your baked model that doesn’t cause any problems right up until upload it to your live server late one night and start getting errors about being unable to make a connection- guess who did that?

The solution is simple: just define a default

somewhere in the file, now when you bake cake will give you the option of using the default connection which won’t add any problem-causing $useDbConfig to your model.

Hope this saves someone 20 minutes

To solve this, I figured I’d better put a no-index on those pages fast; after mucking around with CakePHP’s html->meta handler (because I wanted the meta tag in the header where it belonged) and not finding anything, I came up with:

BTW: The pages where empty at the time because there wasn’t a lot of data in the system, so a lot of searches where coming up empty- that’s been “fixed” now too.

Hopefully this saves someone else 20 minutes

Now the messy part…
In oder to display these in a list, the venues had to be pulled out and listed in that order; as well, if there was more than 40 venues, they had to be split and displayed on two or more pages. In the end, it turned out the quickest way to write it was to query MySQL for each venue one at a time. Needless-to-say not an optimum solution.

…and the right way- 4 years later
When this came up last summer during the re-write of SimcoeDining.com, I figured there there had to be a proper way of solving that problem, and I found one in Imthiaz’s blog entry:

See with MySQL (at least since v5) lets you specify a field and values to sort them by which nicely fits into CakePHP’s Paginator too.

That’s the good news. The bad is the time I have to work on it. Ideally, I’d like to re-write nearly everything about it, then fix up the layout, which is too ad-heavy, as opposed to content for me right now. I have a few ideas about how that can be improved, but the fact is, adding content is the biggest task right now.