Tag Archives: Web Development

Slow server? Don’t overthink it. (And don’t forget what’s running on it.)

I’ve just spent the better part of a week troubleshooting server performance problems for one of my clients. They’re running a number of sites on a dedicated server, with plenty of RAM and CPU power. But lately the sites have been really slow, and the server has frequently run out of memory and started the dreaded process of thrashing.

Fearing inefficient code in cms34 may be to blame, I spent a few days trying to optimize every last bit of code that I could, which did make a slight improvement, but didn’t solve the problem.

Then I spent a few more days poring over the Apache configuration, trying to optimize the prefork settings and turning off unnecessary modules. Still, to no avail, although getting those prefork settings optimized, and thus getting Apache under control, did allow me to notice that MySQL was consuming CPU like mad, which I had previously overlooked.

Hmmm… that got me thinking. I fired up phpMyAdmin and took a look at the running processes. Much to my surprise, almost every MySQL process was devoted to an abandoned phpBB forum. Within moments I realized the forum must be the source of the trouble, which was confirmed when I found that it had over 500,000 registered users and several million posts, almost all of which were spam.

As quickly as I discovered the problem, I was back in the Apache configuration, shutting down the forum. Then a quick restart of MySQL (and Apache, for good measure), and the sites were faster than I’ve seen them in months.

The moral of the story: if you have a web server that suddenly seems to be grinding to a halt, don’t spend days optimizing your code before first looking for an abandoned forum that’s been overrun by spammers.

File under “Don’t Make Me Do This Myself”: a comparison of “TTW” (Through The Web) WYSIWYG text editors

I really don’t want to have to spend time thinking about this, but there’s such a dearth of useful information out there on this topic — based on my searches of Google and Bing, which return little more than uncritical lists of 40+ different TTW text editors, usually displayed on such hideously designed or woefully outdated websites that I discount their validity on sight — that I feel compelled to step in.

The question today is TTW (through-the-web) WYSIWYG (what-you-see-is-what-you-get) text editors. If all of that sounds like 10 letters of gibberish to you, feel free to stop here. But if you’re a web developer, especially of the custom CMS variety, you’re certainly aware of the situation: how do you give users of your system a usable tool that allows them to easily edit site content without having to muck around directly with HTML? (That is, after all, kind of the whole point of a CMS.)

It’s something I’ve struggled with for over a decade. At one point I was actually rolling my own. But that’s a little more JavaScript than I care to deal with directly, and I long ago left the project of building a WYSIWYG editor to those who really love that kind of thing.

That puts me in a position where I need to select the best available option for a pre-built, drop-in WYSIWYG editor. Fortunately things have come a long way in this regard over the past decade. I’ve been — more or less happily — using TinyMCE to solve this particular problem for the past 3-plus years. But lately “less happily” has been outweighing “more,” and I’ve been exploring my options.

So far the only viable alternative I’ve found (or had recommended to me) is CKEditor. It’s the successor to one of the really early TTW WYSIWYG editors, FCKEditor, which I tried ages ago and never really liked.

Today I took a major step forward with cms34, my custom CMS, by setting up a configurable site option that allows users to select the editor of their choice: TinyMCE, CKEditor, or raw HTML. As inclined as I am to use raw HTML myself, I’m giving CKEditor a whirl for now.

So far I am inclined to say CKEditor is just the remedy I’ve been looking for to cure my TinyMCE malaise. As good as TinyMCE is, it just gets a little wonky sometimes. It especially seems to have trouble figuring out where to put closing tags when you’re switching between block elements, and especially when you’re inserting new content. I find myself often switching to the HTML pane to fix its quirks manually, but I can’t expect clients to do that.

My experience with CKEditor is still pretty limited at this point, but I have to say I really like how it’s set up for customizing the interface (which buttons to show, especially), in addition to its better handling of switching between elements than TinyMCE. They’re both pretty similar, actually, in how they’re configured, and in the overall user experience. But CKEditor has a little more polish, a little more flexibility. It almost feels like “TinyMCE done right,” although perhaps it’s too early for me to make such a proclamation.

So, that’s it for me, for now. The only two options in this realm that I really have any experience with. I know there are others out there. Some may even be good. Even better than TinyMCE or CKEditor. What’s your favorite?

CakePHP at the command line: it’s cron-tastic!

I’m kind of surprised it’s taken this long. cms34 has been around for almost three years now, and this is the first time I’ve had a client need a cron job that relied on CakePHP functionality. (The system has a couple of backup and general-purpose cleanup tools that can be configured as cron jobs, but they’re just simple shell scripts.)

And so it was today that I found myself retrofitting my CakePHP-based web application to support running scripts from the command line. I found a great post in the Bakery that got me about 85% of the way there, but there were some issues, mostly due to the fact that the post was written in late 2006, and a lot has happened in CakePHP land over the last 4 1/2 years.

There are two big differences in app/webroot/index.php in CakePHP 1.3 compared to the version that existed at the time of that original post: first, the calls to the Dispatcher object are now wrapped in a conditional, so the instruction to replace everything below the require line should now be something closer to “replace everything within the else statement at the bottom of the file.”

The other big change is that this file defines some constants for directories within the application, and those paths are all wrong if you move the file into the app directory as instructed.

Below is my revised version of the code. Note that I also reworked it slightly so the command can accept more than two arguments as well. There’s a space before Dispatcher is called where you can insert any necessary logic for handling those arguments. (I also removed all of the comments that appear in the original version of the file.)

<?php
if (!defined('DS')) {
    define('DS', DIRECTORY_SEPARATOR);
}
if (!defined('ROOT')) {
    define('ROOT', dirname(dirname(__FILE__)));
}
if (!defined('APP_DIR')) {
    define('APP_DIR', basename(dirname(__FILE__)));
}
if (!defined('CAKE_CORE_INCLUDE_PATH')) {
    define('CAKE_CORE_INCLUDE_PATH', ROOT);
}
if (!defined('WEBROOT_DIR')) {
    define('WEBROOT_DIR', APP_DIR . DS . 'webroot');
}
if (!defined('WWW_ROOT')) {
    define('WWW_ROOT', WEBROOT_DIR . DS);
}
if (!defined('CORE_PATH')) {
    if (function_exists('ini_set') && ini_set('include_path', CAKE_CORE_INCLUDE_PATH . PATH_SEPARATOR . ROOT . DS . APP_DIR . DS . PATH_SEPARATOR . ini_get('include_path'))) {
        define('APP_PATH', null);
        define('CORE_PATH', null);
    } else {
        define('APP_PATH', ROOT . DS . APP_DIR . DS);
        define('CORE_PATH', CAKE_CORE_INCLUDE_PATH . DS);
    }
}
if (!include(CORE_PATH . 'cake' . DS . 'bootstrap.php')) {
    trigger_error("CakePHP core could not be found. Check the value of CAKE_CORE_INCLUDE_PATH in APP/webroot/index.php. It should point to the directory containing your " . DS . "cake core directory and your " . DS . "vendors root directory.", E_USER_ERROR);
}
if (isset($_GET['url']) && $_GET['url'] === 'favicon.ico') {
    return;
} else {
    // Dispatch the controller action given to it
    // eg php cron_dispatcher.php /controller/action
    define('CRON_DISPATCHER',true);
    if($argc >= 2) {

        // INSERT ANY LOGIC FOR ADDITIONAL ARGUMENT VALUES HERE

        $Dispatcher= new Dispatcher();
        $Dispatcher->dispatch($argv[1]);
    }
}

After implementing this version of cron_dispatcher.php, I was able to get CakePHP scripts to run at the command line without being fundamentally broken, but there were still a few further adjustments I needed to make (mostly in app_controller.php). Those were specific to my application. You’ll probably find yourself in the same boat.

A couple of other things worth noting: if your server is anything like mine, you’ll need to specify the full path of the PHP command line executable when running your scripts. In my case it was /usr/local/bin/php. And, the one sheepish confession I have to make: I know the goal with the way the file path constants are defined is to avoid any literal naming, but I couldn’t find a good way to get around that for WEBROOT_DIR, with the file no longer residing in webroot itself. I’ll leave fixing that as an exercise for the reader.

Good luck!

Download the Script

Download zip file... cron_dispatcher.php
cron_dispatcher.php.zip • 1.2 KB

A brief rant against “mobile” websites, and in praise of CSS3 media queries

This morning, as I do on most mornings, I eased the transition between my peaceful slumber and the mayhem of conscious life by lying in bed, catching up on the goings-on of humanity on planet Earth with the help of my iPhone and the Internet.

This usually consists of checking Twitter, Facebook, and my Google Reader feeds, but when that isn’t enough, I’ll occasionally search the web for whatever random piece of information crosses my stream of consciousness. Today that happened to be the Tim and Eric comedy tour that’s currently underway, since I’ll be seeing it when it arrives in Minneapolis on Wednesday. So I googled Chrimbus Tour review and one of the first links that came up was a review on BuddyTV.

BuddyTV is not a site I think of often. I believe I was vaguely aware of its existence before today, but I didn’t know what it was all about and I never had any inclination to visit it. But I was certainly happy and willing to click the Google link and read its review of the Chrimbus Tour.

Unfortunately, the site did not reciprocate that happy willingness. Instead of taking me to the desired review, it detected I was arriving via iPhone, so it shunted me off to an annoying splash page imploring me to download the BuddyTV iPhone app. No thanks, I really just want to read the article I came here for in the first place. Oh, great! You’ve provided an “Or continue to BuddyTV.com” link at the bottom. Thanks!

But — and this is so often the case in this scenario — that link did not helpfully take me to the article I wanted. (And as a web developer, I can tell you it is not at all difficult to make it do that.) Instead it just went to the BuddyTV home page. Now what? I’ll tell you now what: I closed Mobile Safari and got out of bed. Not only did I not download their app; I didn’t expose my eyeballs to any of the ads that pay for their website; I didn’t get to read the article I was interested in; and I was left with such a negative impression of the site that it drove me to this public rant.

All of this is not really to single out BuddyTV for its bad behavior, though. BuddyTV is just one site among many I’ve encountered over the past couple of years that all adhere to this same pattern of deplorably ill-conceived UX design. Surely this is not the reaction the owners of these sites hope to elicit. But it’s exactly what happens with me, every time, and I’m sure I’m not alone.

There is a solution.

We frequent users of web browsers on mobile devices just want to see your site. We want to see the same pages we’d see on our computer. The same content. But it doesn’t hurt to have that content optimized for the mobile browsing experience. Resized to the smaller screen. A streamlined layout that’s easier to navigate with a touchscreen. But, fundamentally, the same experience.

While there are some tools out there to help turn a regular website into a mobile website (most notably Mobify), there’s a far easier solution: CSS3 media queries.

CS-what media what now? CSS3 media queries are, simply, a set of stylesheet definitions that are applied to a web page selectively depending on certain characteristics of the media the page is being viewed on, most notably, screen size.

With CSS3 media queries, you can define an entirely separate set of stylesheet attributes to be applied only when the user is visiting the site from a small screen. Or an extra large screen. Or you can describe a bunch of intermediate sizes, so with the exact same HTML content the user will see a perfectly laid-out page, optimized to their screen, whether that’s an iPhone, a netbook, a “standard” computer monitor or a 30-inch Apple Cinema Display.

I’ve begun working more extensively with CSS3 media queries on some of my own projects lately, and I am very excited about the potential. If you’re a web developer or designer, you should learn about CSS3 media queries now. And if you’re a website owner, you should know that “mobile” sites are sooo 2008. Now you can have your cake and eat it too. You can have the best of both worlds. Insert cliché here. Just don’t subject your site visitors to any more obnoxious plugs for your iPhone app, or dump them thoughtlessly on your mobile home page with no way of tracking down the article they were coming for. It’s not fair to your users, it’s not fair to your public image, and if you’re supporting your site with ads — or, for that matter, if you’ve been convinced to drop a ton of extra cash on developing a separate mobile site, or an iPhone app that just displays your site’s content anyway — it’s costing you money.

Making CakePHP’s TreeBehavior work with scope

We’re not talking mouthwash here. We’re talking code.

CakePHP’s TreeBehavior is cool, but tree traversal is a pretty arcane concept, even for developers, and MPTT is not something that is easy to digest mentally, or to develop around. Unfortunately, it’s also not incredibly efficient on large data sets. Even not-so-large data sets, on the order of a few hundred items, make certain actions — reordering, in particular — really processor intensive.

I’m using a JavaScript drag-and-drop tool in cms34 to allow admins to manage the page tree on their sites, and the data gets stored using CakePHP’s TreeBehavior, which is MPTT-based. The problem is, it really wasn’t working. So I completely rebuilt the code that assigns the über-critical “left” and “right” values to each node in the tree. My new way is much faster, even though it may break a few rules, and requires bypassing TreeBehavior’s callbacks.

Once I got that working, I was delighted, but then I discovered some other problems, namely pertaining to… scope. My CMS supports multiple sites in one installation, which means multiple trees, which means scope. The problem is, I was having a hell of a time figuring out just how to make scope work with TreeBehavior. Finally I found a link to a succinct and effective solution.

The upshot here is that you can’t define your $actsAs in the model, because… well… to be honest, I only have a vague understanding of why not, but essentially it’s due to the split roles of the model-view-controller framework. You’re building a rule that requires access to specific data values, which is something that needs to happen in the controller; the model is strictly for the abstract structure of the data. I understand it just enough to agree that it makes sense not to do it in the model. Which means you have to do it in the controller. The sample code from the link above goes a little something like this:

function add() {
    $this->Task->Behaviors->attach('Tree', array(
         'scope' => "Task.schedule_id = {$this->data['Task']['schedule_id']}"
    ));
    $this->Task->create();
    $this->Task->save($this->data);
}

That didn’t quite work in my situation, but it got me far enough along that I could figure out what to do from there.

I still need to do a little more testing to make sure my solution to the more efficient tree reordering is rock solid, and then I’ll post a tutorial. But for now, I hope this helps spread the word that scope does work on TreeBehavior… if you do it right.

Update (September 22, 2010): Although this didn’t really seem to be breaking anything, just throwing up a warning (when debugging was turned on), I discovered a minor issue with this code yesterday. Turns out CakePHP expects the value of scope to be an array. Just taking the string it was defined as and wrapping it in array() did the trick.