Corrupted strings when using strtolower()

Little blog post at 5am, I'll try to make it very short, I need some sleep.

To avoid getting corrupted string results when calling strtoloweron UTF8 strings, you can call mb_strtolower instead. The mb_* functions are aware of the utf8 encoding.

Unfortunatly, sometime you just can't, because the call is made in the cakePHP core (Inflector). Defining a CTYPElocale for your whole app may be a better solution.

Just add a setlocale(LC_CTYPE, 'C'); in your app and all your utf8 strings will correctly work with string functions.

Just note that on Windows, calling setlocale will change the locale for all threads, not just the one where PHP is running. This may cause unexpected results.

How to fix the Firefox autocomplete 'feature'

Firefox can be quite a pain sometimes. I usually praise this browser features but today I had to deal with one tricky 'intelligent' feature.

You know that autocomplete/autofill feature, so that when you enter your user name, Firefox automatically fill the corresponding password field so you won't have to do it ?

Well, it is bad, and here's why.

How does it work ?

I haven't read the source code, but from what I've experienced it seems to work like that :

For each password field, FF will find the related username text field. This is just a very basic search, it assume that the closest previous text field is the related one. Now, everytime you enter a value in the text field that match one of the username saved, it will autofill the password field.

Note that if you have more than 5 password fields on a page, the feature will be disabled.

What is terribly wrong with this approach

Let's imagine you are a registered user of a website. You want to update your preferences. You have a nice page with lots of input fields where you can change your email, password and date of birth.

For security reasons, your password is not displayed. For convenient reasons, the website also don't ask you to type your password everytime your want to update your settings. It assumes that if you let the password field blank, it means that you don't want to change it. And if you really want to change it, then it asks for a confirmation, to make sure your correctly typed it.

So, with this autocomplete feature, if your email is also your login for the website (as it is often the case), Firefox will autofill the password field with your password. Meaning that if you submit your form, you'll be met with an error because your password and it's confirmation does not match.

You'll then have to manually clear the content of the password field everytime your want to edit your profile. Which is counter-intuitive. The whole convenient method of not changing the password if left empty is rendered useless.

The worst part is that most users won't understand when the error comes and will blame the webdeveloper.

Solutions that does not work

First, Firefox is just doing a very wild guess on that fields. And, there is no way to disable this feature from the page markup. Sure, as a user you can disable it in your browser setting, but as a web developper, you can't disable it.

There is a non-standard autocomplete="off" argument, but it does not work in our case. It is supposed to prevent the browser to store previously entered values on sensible fields (like credit card numbers).

I've tried putting this autocompleteattribute on every input field, even on the form itself. Setting the valueattribute does not work either. Even updating the value through Javascript would not work because the password field will get re-populated on every blur event on the text field.

A solution that does work

The final solution I've found is to add a dummy password field between your real mail and password fields. That way, Firefox will autocomplete this dummy password instead of the real one.

Unfortunatly this adds clutter to your markup, but with a little display:none in CSS it won't ever be seen by your users.

7 advices to start using OOCSS as a coding practice

Not long ago, I stumbled across this video about massive and unmaintainable CSS files from Nicole Sullivan. It made me want to try OOCSS.

OOCSSis a way to code css in a way that replicates the goodies general OOP told us. Classic CSS use the cascade in selectors to emulate a concept of inheritence.

OOCSS puts the concept of inheritence a little step further by telling us to create "modules" in our CSS files. Each module represent a "widget" of our page, or should I say of our whole site.

It comes with a simple list of principles that could allow one to write much more flexible and maintainable code. I rewrote the whole CSS for this website (as well as the admin interface I'm using behind the doors) following those principles, and I thought I'll share it with you.

Drop the #id selector

We won't be using the #id selector anymore (except for some edge cases). Instead of #commentList {} we'll use .commentList {}

This change alone lets us reuse the same element multiple times on the same page.

Note that we will still add ids in our HTML markup for form inputs or for Javascript purpose (document.getElementById is still the faster selection method).

Don't make your selector dependent on the page structure

We won't style our elements based on where they will be displayed in the page.

We don't care if our module will be displayed in a footer, sidebar, specific page or whatever. We just style it all the same.

Instead of writing .sidebar .lastComments {}, we will go for the shorter .lastComments {}.

This will allow us to easily display the last comments on any page, anywhere. You should carefully name your modules to something that clearly evoke what the module is supposed to display, without ambiguity.

If you need to tweak the display of an element in a certain part of the page, you could always write a specific selector for this specific need, that will overwrite the default rules. But this must not be your default selector.

Do not use both tag and class selector on the same element

Avoid the div.errorMessage, ul.userList selectors. The first one is just too specific : what happen if you ever want to style a <p> instead of a <div> ? The second one is useless, <ul> is a list by definition.

There is only one moment when being that specific can be useful, it is when you need to overwrite, for a specific element, rules defined for the class. Fortunatly, thanks to the OOCSS coding style, this won't happen much.

Don't make your selectors over-specific

This is a followup of the previous rule, but don't write overly specific rules, like .userList table thead tr th a. A simple .userList thead a is enough.

First, you are overly detailing each level of the markup while most of the time the uppermost and lowermost parts are enough. But you also define useless selectors like tr th or ul li, where th or li are enough (those elements can not be placed in any other parent element).

Create your own reset stylesheet

To avoid repeating margin:0; padding:0 over and over in your stylesheets, you should spend some time finding a reset stylesheet that you like and then tweaking it to fit your coding practice.

I used to include the Tripoli framework in my previous projects but I found that I had to reset styles it was settings far too often.

All reset stylesheets are not equals, some will just remove all styling from elements, letting you define them as you want. Others will also assign default rendering styles to make something both visually beautiful and cross-browser.

But the best reset stylesheet you'll get is the one you'll create (or, as it is quite a bit of work, tweak) yourself.

Use a grid system to place elements

Some years ago, I found CSS Framework like Blueprint to be a waste of time. I didn't want to clutter mu HTML markup with non-semantic classes for handling the styling.

I also found that the psd files I was given to integrate couldn't fit in grids because the sidebar was 173px wide for example.

Now I still don't think cluttering the HTML with span-6 pull-2 is the best thing that happened to CSS, but I found it much better than cluttering my CSS with endless overflow:hidden and float:left; margin-right:10px declarations.

And I still got design from not-so-professional designers to integrate that do not seems to have any logical proportion, and can't fit them in grids. But I also work with more talented people that deliver beautiful design and they tend to be the one that fits easily into grids.

So it may not always be possible to use a grid system, but more often than not, it is and even if that means tweaking the original (badly designed) design a dozen pixels off, it will greatly help the CSS process.

Create a global stylesheet for your main classes

I also create a main stylesheet for all the classes I know I'll be reusing all accross this project (and others). I include it at the top, right after the reset one.

In it I'll defined general classes that could be extended by all the other inner classes later. Like a .message class, that I may be extending later using .message.error or .message.success

One final word

Ok, this is it. I'm fairly new to OOCSS too, so I'm still discovering it too. So far I found that I have greatly reduce the size of my files but most importantly, my styles are way more easy to tweak for special needs than before.

It also helped me separate the various elements of the website, and it is much more easier to find the piece I need. Fewer classes to depends on means I know where the rules are coming from and I can write more specific selectors if need me more easily.

Testing a custom ErrorHandler in cakePHP

I just finished writing the test case for a custom AppErrorclass. Writing the tests case was indeed much more difficult than writing the class itself.

Here are some things I've found that may interest anyone wanting to test their own ErrorHandlers. Most of the ideas are taken from the core ErrorHandlerTest.

Anatomy of an error

Every class in cakePHP extends Object. And in Objectis defined a method named cakeError. It means that anywhere in your app you can call $this->cakeError() and the whole app will stop and display the specified error.

What cakeErrordoes is instantly create an instance of either Controlleror CakeErrorController, find the correct view, render it, and stop.

Because of the use of static variables, exitcalls and other happyness, testing several errors in a test case needs us to define some new classes to shortcircuit most of the logic.

Preparing the test

This step is actually pretty short. Just load the default ErrorHandlerby calling App::import('Core','Error');

Creating a dummy AppController

Then, you'll have to create a new AppControllerclass that extends Controller.

We will override the headermethod to prevent 'Headers already set' error when calling several errors in a row.

We will also override the render method to store in an inner property the name of the rendered action. It will help test that the correct error is rendered.

You may also need to define a custom list of helpers if your custom views are using any custom helpers.

Here is what it looks like on my side :

class AppController extends Controller {
  // Helpers used in the view. If not set, will generate a fatal error
  var $helpers = array('Caracole.Fastcode', 'CaracolePacker.Packer');
  // Overriding the header method. If not set, will generate 'Headers already set' errors;
  function header($header) {
    $this->header = $header;
  }
  // Overriding render method to keep track of the rendered error
  function render($action) {
          $this->renderedAction = $action;
          return parent::render($action);
  }
}

Creating a TestErrorHandler

This class will extends your AppError. It will just overwrite two methods to make it correctly work in a test case.

First, we'll need to overwrite the __construct. The default construct will set the inner $this->controller property to either a Controlleror a CakeErrorControllerinstance depending if its the first error fired or not. I must admit that I haven't really understand the difference between the two. But I know that CakeErrorControllerextends AppControllerwhile Controllerextends Object.

And as we need to overwrite methods of this property, it being a CakeErrorControlleris great, while it being a Controlleris bad. Anyway, what I did was copy/paste the parent __construct into TestErrorHandlerand just force it to always create a CakeErrorControllerinstance.

The other method we need to overwrite is the _stop. If we don't, the whole script will halt after the first error you'll test.

So, enough talk, here's the code :

class TestErrorHandler extends AppError {
  // Copy/paste of ErrorHandler construct method, but force a new instance of CakeErrorController as $this->controller each time
  // CakeErrorController extends AppController, so we can overwrite its methods
  function __construct($method, $messages) {
    App::import('Core', 'Sanitize');

    // Forcing CakeErrorController
    $this->controller =& new CakeErrorController();
    $options = array('escape' => false);
    $messages = Sanitize::clean($messages, $options);

    if (!isset($messages[0])) {
      $messages = array($messages);
    }

    if (method_exists($this->controller, 'apperror')) {
      return $this->controller->appError($method, $messages);
    }

    if (!in_array(strtolower($method), array_map('strtolower', get_class_methods($this)))) {
      $method = 'error';
    }
    if ($method !== 'error') {
      if (Configure::read('debug') == 0) {
        $parentClass = get_parent_class($this);
        if (strtolower($parentClass) != 'errorhandler') {
          $method = 'error404';
        }
        $parentMethods = array_map('strtolower', get_class_methods($parentClass));
        if (in_array(strtolower($method), $parentMethods)) {
          $method = 'error404';
        }
        if (isset($code) && $code == 500) {
          $method = 'error500';
        }
      }
    }
    $this->dispatchMethod($method, $messages);
    $this->_stop();
  }

  // Preventing the error from stopping all the request
  function _stop() {
    return;
  }
}

Writing your tests

Ok, your almost done. You just have now to write your tests. They have to follow a special syntax to correctly work.

First, you'll have to wrap your ErrorHandlercreation between ob_start() and $output= ob_get_content(), otherwise you'll end up with error popping right into your test case because the ErrorHandlerforce the controller to render the view.

You'll be able to access interesting properties through $errorHandler->controller->renderedAction and $errorHandler->controller->header. You can also directly test the view output through $output.

Ok, so here's one of my tests :

// DEV : Error will use the error layout
function testCallingErrorInDevWillUseErrorLayout() {
  ob_start();
  $errorHandler = new TestErrorHandler('missingController', $this->errorParams);
  $result = ob_get_clean();
  $this->assertEqual($errorHandler->controller->layout, 'error');
}

Conclusion

It took me some hours to glue all this pieces together, I hope it may be useful to others, too. Writing the AppErroritself was way easier, but as I'm now test infected I don't imagine writing code without the corresponding tests.

Correctly instanciating models in components

I sometime need access to a specific model in a component. Say a Usermodel for checking user rights in an Authcomponent. In that cases, I just create an instance of the model by calling a $myModel = &ClassRegistry::init($myModelName). It works perfectly.

Today I found that it wasn't working exactly as I wanted. In fact, behaviors used by models loaded that way are not completely set up. All their callback methods (beforeFind, afterFind, beforeSave, afterSave) works as expected, but the main setup method is never called.

This caused some havoc in my app because some *reaaaaally *important stuff was defined in the setup method

There I fixed it

I just manually fired all the setup methods by calling a simple :

foreach($myModel->Behaviors->_attached as $behaviorName) {
  $myModel->Behaviors->{$behaviorName}->setup($myModel);
}

Once again, small fix, but does the trick. I did not file a bug report because I'm not really sure this is bug or if that is so by design.