$oldErrorReportingValue = error_reporting();
error_reporting($oldErrorReportingValue ^ E_STRICT);
// call offending PEAR code…
error_reporting($oldErrorReportingValue);

This didn’t work. No matter what I set error_reporting to, the E_STRICT errors would keep showing up in my logs. I found others with the same problem, but I was led on a wild goose chase:

• http://pear.php.net/bugs/bug.php?id=9950
• https://bugs.php.net/bug.php?id=40244
• http://www.php.net/manual/en/function.error-reporting.php

One of the causes was PEAR running the non-strict code during a registered shutdown handler. Another cause was the strict errors getting thrown at compile time. But neither of these applied to my case.

After messing around for quite a while I discovered the answer in the set_error_handler documentation. My custom error handler was the cause…

“It is important to remember that the standard PHP error handler is completely bypassed [...] unless the callback function returns FALSE. error_reporting() settings will have no effect and your error handler will be called regardless – however you are still able to read the current value of error_reporting and act appropriately.”

• Demo
• Download
• Github

The “dropdown” button style can be customized with css. Here’s a quick example.

The Markup:

<input id="combobox1" type="text" name="fruit" />

And the Javascript:

jQuery(function () {
 
    jQuery('#combobox1').combobox([
        'Apples',
        'Oranges',
        'Bananas'
    ]);
 
});

I intend to add support for more flexible custom styling. The plugin is listed on jquery.com

/*
Plugin Name: Broken Plugin
*/
 
$plugin = "oops!";

Looks innocent enough. But try to activate this plugin and you’ll get an admin error notification:

The plugin “oops!” has been deactivated due to an error: Plugin file does not exist.

The reason for this is that when WordPress activates the plugin it includes your plugin file into the scope of the activate_plugin function. It does this in order to do a “Sandboxed” execution of your plugin to catch any errors, or premature output that could mess with the WordPress headers. The problem is that the “Sandbox” scope is full of other variables that are used in the process of registering the plugin. One of those variables is… you guessed it… $plugin.

Here’s a simplified version of what’s happening in activate_plugin:

function activate_plugin ($plugin, /* other stuff */) {
   include(WP_PLUGIN_DIR . '/' . $plugin);
   // OOPS! NOW $plugin HAS AN UNINTENDED VALUE
   if (/* NO ERRORS */) {
      $installedPlugins = get_option( 'active_plugins', array() );
      $installedPlugins[] = $plugin;   
      update_option('active_plugins', $installedPlugins);
   }
}

What made this bug a giant PITA for me was that I happened to assign an object to $plugin. So, not only did my plugin not install, but it riddled my WP install with cryptic errors about incomplete objects.

The Solution…

The simple work around to this is to not use $plugin, or any other variable name that happens to be used in the body of activate_plugin. The better solution is to eliminate variable declarations and code execution from the top scope of your plugin altogether. This can be achieved easily by wrapping any code in a bootstrap function:

function my_plugin_bootstrap () {
   $plugin = new MyPlugin();
   $plugin->init();
}
my_plugin_bootstrap();

There is a note in the WordPress documentation about scoping in plugins that is related to this issue. Personally, I think this is a bug — If I get a change to file it, I’ll link to the ticket and followup here.

Randomly, it popped into my head. “Doesn’t Google have a service for building basic websites? I wonder if its any good?” A few minutes later I had a multi-page documentation site with embedded media, configurable tables and list, file attachments, and comment support. It also supports private sites with the ability to control viewing and editing privileges.

Here are some of the highlights…

No-nonsense Rich Text Editing
No fluff. The controls are paired down which makes maintaining consistent formatting easy.

Great Navigation Controls
You can either create your own custom navigation, or have sites generate the nav for you automatically. You can also drop in Table of Contents blocks on individual pages that render automatically by detecting the heading structure of your document.

Decent Layout Control
You can configure the layout of each page (x columns, headers, footers). Seem to give you just about every standard configuration you could want.

I won’t be using Google Sites to build my next client’s site any time soon. A friend of the superstar css tweaker it is not. But for something that needs to be functional, consistent, and organized this is a great tool.

It’s a common one. You have a project that requires uploaded images. These images need to be displayed in different layouts at different sizes based on the context (ex: large on a detail page, thumbnail on the list page, etc…) In the past I would have encapsulated these sizes in an image class and implemented the resizing to happen at upload time.

The problem pops up when the layout changes. You (or someone else) decides that the thumbnail need to be bigger. You go into your code – say it’s in a class called Image. Your image class has methods like, resizeAndInstallThumbnail(), getThumbnailUrl(), etc… Like a good little OO programmer you’ve hidden the actual dimensions of the thumbnail in the class. So you change those and you’re all set.

Well… sort of. You forget that you used getThumbnailUrl() in another layout, and that one wasn’t supposed  to change. After breaking the other layout severely you fix the problem by adding a method like getSearchResultThumbnailUrl(). Annoying, but not so bad. But, wait. You forgot this site is in production, with hundreds of uploaded images that all need to be resized. If your app has been storing the original uploaded files then you can write a one-off script to regenerate the resized images. If not, it’s time to re-upload all your images.

The Solution

The real problem here is that the rate of change in the presentation layer is high. And we’ve coupled some lower-level infrastructure to that presentation by designing our api around it with method names like getThumbnailUrl(). “Thumbnail” is a presentation word. Why does the object responsible for uploads and resizing need to know what a “SearchResultThumbnail” is? Why not have the presentation layer talk to the image infrastructure layer in a more generic way… Like pixel dimensions? Here’s what you end up with:

<img src="<?php echo $image->getUrlByHeight(55); ?>"
    alt="Product Thumbnail"/>

The benefit here is that the hard-coded pixel values now appear in the presentation layer, where they belong. In addition, you can easily resize the images on demand. If you add new sizes to your layout, all you have to do is specify the new dimensions and any new images files will be generated as needed.

My brother Jay came up with this idea. I’m sure others out there are using similar techniques, but there was something about the simplicity of his solution that really appealed to me.