Capistrano is great for deploying web applications. But the “current” symlink construction causes issues with PHP-FPM and OPcache enabled. PHP-FPM will display old pages after deployment or PHP-FPM just hangs. The hanging / freeze will result in your browser loading for minutes but you will just see a white screen.
To fix this, use $realpath_root instead of $document_root and set the SCRIPT_FILENAME in Nginx to pass to PHP-FPM.
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT $realpath_root;
This will pass the actual path “releases/20150208145800″ to PHP-FPM instead of “current” that is switched to the new release directory. OPcache can’t detect More >
When you write unit tests with PHPUnit there is a big chance that you have to mock several objects. If you want to write a unit test for your controller action and you use Doctrine ORM in your project, you will have to mock the Doctrine EntityManager, specific repositories and specify return values of the repository method calls. In the example below a repository method calls are “getCustomers” and “getNewHouse”.
The use of $this->at() (not possible)
Mocking multiple calls to the same method can be a bit difficult with PHPUnit. Because if you have More >
Building a REST API with Apigility that is built on top of Zend Framework 2 is awesome. I’m also a big fan of Doctrine. So I started with the zf-apigility-skeleton and added the zf-apigility-doctrine vendor.
I created an User API and a Doctrine REST service called “User” with the route “/users[/:userId]“. You can defined fields per REST service. Every field will become an instance of Zend\InputFilter\Input, and together they are specified in a Zend\InputFilter\InputFilter.
The username must be unique, so for the POST (adding a user) /users More >
For my projects I use the awesome tool Capistrano for deployment. In a project that uses Solr, I want to update the Solr core as a deployment step if the Solr configuration of that core is changed. After the reload of the configuration I want to do a full import with the Solr Data Import Handler.
If you have a large import then this can take a while. But it is possible to do this without any downtime! The trick is to work with two cores. A “live” core and a “on deck” core. The More >
Xdebug is a very nice extension for PHP. It makes step by step debugging possible in your IDE. For most people it’s easy to install Xdebug and start debugging their web application on localhost with some IDE, for example Netbeans. Because after installation of Xdebug, it just works. A lot of this tutorial works almost the same for PhpStorm.
But getting Xdebug remote to work if your website runs on a virtual machine / Vagrant box, it’s a bit trickier and requires a bit more configuration.
First let me explain how the Xdebug More >
In doctrine 2 there are by default no foreign key fields a ID. For example your “product” entity might have a “shop” property, but no “shopId” property.
To get all the products that belong to a shop you would always have to make a join like this:
But in certain situations it would be nice to use the foreign key column directly, in this case “shopId”. That More >
Doctrine 2 doesn’t have an i18n (internationalization) behaviour in the core anymore like Doctrine 1 had.
But luckily for us, Gediminas Morkevičius build the translatable behavior extension for Doctrine 2. Translatable behavior offers a very handy solution for translating specific record fields in diferent languages. Further more, it loads the translations automatically for a locale currently used, which can be set to a translatable listener on it’s initialization or later for other cases through the Entity itself.
Checkout the website: http://gediminasm.org/article/translatable-behavior-extension-for-doctrine-2