There are a two main things that tripped me up while I was writing functional tests for my Laravel controllers: POST requests, and session state.
Laravel’s Controller class has the
call() method, which essentially makes a GET request to a controller method. In order to make POST requests, it’s necessary to inject some extra parameters into the HttpFoundation components. To make this easier, I created a ControllerTestCase class with convenient
post() methods: Continue reading
Unlike Doctrine 1 with it’s NestedSet behaviour, there is no nested set functionality in the core of Doctrine 2. There are a few extensions available that offer nested set support:
I tried all of these extensions, but none of them felt simple or lightweight enough for my application. What I wanted to do was have a Category entity which could have a tree of sub-categories, e.g: Continue reading
I came across this recently while I was developing a module for PyroCMS. Some of the PyroCMS tables contain ENUM columns, which Doctrine doesn’t support. You would think that this wouldn’t be an issue since these tables are not mapped, but apparently when Doctrine builds the schema it includes all tables in the database – even if they are not mapped. This has been reported as an issue, but the Doctrine team has given it a low priority.
The symptom? When using the SchemaTool to create, update, or drop the schema; an exception is thrown:
Fatal error: Uncaught exception 'Doctrine\DBAL\DBALException' with message 'Unknown database type enum requested, Doctrine\DBAL\Platforms\MySqlPlatform may not support it.'
Thankfully, the fix is very easy. There is even a Doctrine Cookbook article about it. All you have to do is register the ENUM type as a Doctrine varchar (string):
/** @var $em \Doctrine\ORM\EntityManager */
$platform = $em->getConnection()->getDatabasePlatform();
This fix can be applied to any unsupported data type, for example SET (which is also used in PyroCMS):
Doctrine 2.1 has been released, bringing many major changes to the ORM – some of which are not backwards-compatible with Doctrine 2.0. Continue reading
It’s debatable whether or not it’s good practice to use short syntax in PHP. I personally prefer to use short syntax because it keeps my view files looking tidy.
The regular expression below will find all one-liner
echo statements (e.g.
<?php print $var; ?>) and convert them to
<?=$var?> statements. It will not match statements containing closing brackets, for example when using ternary operators:
<?=($foo == $bar) ? 'Foobar' : 'Foo'?>
If you want a quick way of getting Doctrine 2 working with CodeIgniter 2, you can download a pre-configured installation from my GitHub repository. There are currently three branches available:
- master – the latest stable versions of CodeIgniter and Doctrine.
- develop – the latest development versions of CodeIgniter and Doctrine. Not recommended for production use.
- doctrine-2.1 - the latest stable version of CodeIgniter, and the latest stable 2.1.X version of Doctrine. This branch is provided as a way of keeping Doctrine 2.1 applications up to date without breaking backwards compatibility.
For more information, read my post on integrating Doctrine 2 with CodeIgniter 2
CodeIgniter 2.0.0 was released today, signalling a huge step forward for the already-popular PHP framework. The interesting thing about CodeIgniter 2 is that there are two branches in development: CodeIgniter Core, which is the ‘official’ branch developed by EllisLabs; and CodeIgniter Reactor which is a community-driven branch enabling faster adoption of new features. Reactor will essentially become CodeIgniter, as EllisLabs recommends Reactor for day to day development. Continue reading
Doctrine 2′s console is really powerful when you know how to use it. You can generate entity classes and their method stubs, reverse-engineer a database, validate your entity schemas, and much more. In this post, I’m going to cover some of the Doctrine console’s more useful commands and explain how you can use them to reduce development time. For a full overview of the Doctrine 2 console, read the Doctrine Tools documentation. Continue reading
A word of warning: eAccelerator does not play well with Doctrine 2. This came to my attention today after I installed eAccelerator so that I could measure the performance gains (if any). As it turns out, one of eAccelerator’s “features” is to remove Docblocks from PHP scripts – probably to reduce compile times. Suddenly my application was throwing exceptions with the message “Class X is not a valid entity or mapped super class”.
My latest CodeIgniter 2 project requires that I use query strings in some of my URLs. CodeIgniter 1 was notoriously difficult to work with when you enabled query strings, and unfortunately CodeIgniter 2 is no different. Whereas in CodeIgniter 1 you could change two configuration options to enable a combination of segment-based URLs and query strings, this same approach only makes matters worse in CodeIgniter 2.