Get it All

So, in developing the new website application for my company, I’ve hit a peculiar snafu. Namely that, because the same basic system will be used to spawn a number of different websites, things that go into making a website visible, such as images, views, css files and others will need to be different from instance to instance. I found an excellent tutorial on ignoring files, but that’s when I hit the snag: since I put everything under revision already, I discovered that I could not ignore the files and folders I wanted to anymore.

What is the solution? Well, here goes.

The first step is to backup the files you want to keep out of versioning. Just copy and paste them into a safe folder, outside the working directory somewhere. This way, it will be easy to put stuff back where it belongs later.

Next, we explicitly delete the files from the repository:

myhost: working svn delete ./path/to/directory/
myhost: working svn commit -m "We need to make sure that the repository no longer records these files as being under revision."

Ok! Now that the files and folders are no longer in the repository, its time to click and drag / copy and paste our folders back into their correct locations. You will now see something like this:

myhost: working svn status
?      path/to/directory

Thats, ok: in fact, that’s exactly what we want. Now, Subversion does not recognize our directories as versioned items. They’re brand new, as far as Subversion knows or cares. Now we can set the svn:ignore same as we would any other time:

myhost: working cd path/to
myhost: to svn propset svn:ignore directory .
property 'svn:ignore' set on '.'

That’s it! Do an svn up and you’ll see your directories are not listed anymore.

It’s important to remember that, if you’re going to ignore more than one directory or file within a given directory, you need to create a file that you can feed into the svn propedit command that will list them separately. This blog post does an excellent job of explaining how to ignore files and directories. And of course, you should also refer back to the Red-Bean handbook on the subject.

I’ve seen many threads on the CakePHP Google Group about how to organize files on a CakePHP installation, but many of those threads are very old and I don’t think they’re always all that relevant. Once a project gets involved, or if the project is aimed at recreating an already-complex structure, it is common to have many files of similar function that it only makes sense you would want to organize into subfolders for expedience – not to mention neatness. Recently, I’ve had cause to start trying to organize files and thought I’d share a few observations. If you find any errors in my logic or ambiguity in the way I explain things, please comment below so I can make the corrections as needed.

Controllers and Models

Probably the most convenient in terms of CakePHP’s ability to flexibly handle subdirectories are Models and Controllers. Here you have the ability to just throw files into subdirectories of the /controllers or /models folders at will and CakePHP will automatically find them at run time with no extra configuration. I have not tested folder depth: I have not see whether /controllers/deep/path works as well as /controllers/path, but certainly a single subdirectory works fine, even with files that were already created in the root directory and later moved.

Views (and Elements, and Layouts, and so on..)

With Views and Elements, subdirectories still work, but in this case the subdirectory path must be specified. If you put an element file inside /views/elements/charts/template_1.ctp, then the path relative to the /elements folder must be specified like so:

<?php echo $this->element('charts/template_1', $args); ?>

So, that’s pretty much all I had to add to the conversation. I hope this relatively simple blog post helps a few of you out there looking for a straight-forward answer to the question, “How do I organize my CakePHP files?”

This plugin is deprecated and no longer maintained by the developer.

The new 2.7 version of WordPress MU is pretty awesome and I’m glad to have it running on both of my sites right now. There’s a lot 2.7 has to offer in terms of usability boosts, and while I balked at the redesign when it first started, I have to confess that there is much to love about the new layout.

However, one thing that’s been nagging me is the new Admin Bar functionality. It suffers from two things, in my opinion:

  1. It’s a blog by blog setting, not sitewide. This is fine for sites where you want savvy people to start blogging on your network. It’s less so for community based sites like mine, where the idea is a sort of news magazine site where consistency is key.
  2. Because plugins can add their own top-level menus, the Admin Bar can get a bit crowded and I’d like the option to add or subtract items from the list as I see fit. Again, it would be nice to have these settings happen globally rather than by site.

While I have not worked out the second problem just yet, I thought I’d go ahead and post my modified code to this site which allows site-wide settings rather than by-site. It also tucks the Admin Bar settings under the Admin section rather than Options.

There’s nothing magical here: all I did was change every occurrence of “get_option” and “update_option” to “get_site_option” and “update_site_option.” Then, I just modified the menu statement to look like the following:
// Register the settings page
function AddAdminMenu() {
add_submenu_page('wpmu-admin.php', __('WordPress Admin Bar', 'wordpress-admin-bar'), __('Admin Bar', 'wordpress-admin-bar'), 'read', 'wordpress-admin-bar', array(&$this, 'SettingsPage') );

Download the file here and replace the one currently sitting in /wp-includes/wordpress-admin-bar/

Meanwhile, I’m going to work on tweaking the plugin to make it more flexible for MU as I go.

This may be apropos of nothing for a lot of people, but just as a helpful little hint, you can get the theme used by a blog by calling the get_option() method thusly:


I’m using this on a plugin that changes the colors of certain objects (not CSS directable) by checking the current theme and setting matching colors. Think “custom color YouTube video window.”

MU admins, you could use get_site_option() if you’re planning on doing something global.