Category: Composer


This is real easy, but i keep forgetting which option to use!

If you have separated some of your code into a composer vendor package, and are currently using it in a project, it can be annoying if you need to update it. First you need to open that project up, make your changes, commit, push, wait for tests to pass on travis etc, tag a new version (depending), update packagist if it hasn’t automatically already, and then you can go back into composer and update.

So to save that hassle, composer has the –prefer-source option (–prefer-dist is the one that confused me). This puts the .git folder in your vendor package folder, allowing you to edit, commit, and push from there. Much better.

If you already have the package installed, just delete it. If you haven’t installed it yet, just require it. Both with the –prefer-source option.

composer require delboy1978uk/user --prefer-source
// or
composer update delboy1978uk/user --prefer-source

Replacing my own package above with the one you need, of course. Have fun!Screen Shot 2016-01-14 at 20.26.55

As a Zend Framework 1 user I loved the simplicity of the class naming convention, being Folder_Subfolder_ClassName. However as you probably know, these class names get really quite long! The latest PHP as you already know uses namespaces and allows for shorter classnames that wont clash with each other. Now I have added an API to my website using the incredible Apigility (http://apigility.org) which was built in Zend Framework 2, I thought it would be nice to upgrade my existing classes to autoload PSR-0 style, so I can eventually migrate easily across.

First thing then, you need composer installed. If you’ve been following my blog, or using any other vendors packages, you’ll already have it in your project.

In ZF1, the library folder was where you would keep your different modules/packages/classes. I have a library called TTB. So in the TTB folder, create an src folder, and another TTB folder in there (this is a quirk of PSR-0, but trust me). In that folder, recreate your classes. Changes aren’t very difficult:

<?php
namespace TTB\Form;
use TTB\Form\Element;

class Contact extends \Zend_Form
{
    //etc
}

The line TTB_Form_Contact extends Zend_Form is shortened by way of the namespace line at the top to just become Contact, and the Zend_Form gets a backslash in front of it as it is in the global namespace. You also specify use  to import any other classes into the namespace. Now we can call Textbox instead of Element\Textbox or TTB\Form\Element\Textbox.

You probably know all this stuff anyway! The point is, to get it autoloading in your project!

So in your index file of your ZF1 project, require once vendor/autoload.php. And in your composer.json, add the following:

"autoload": {
     "psr-0": {
         "TTB" : "application/library/TTB/src/"
     }
 }

Finally, run composer dump-autoload in the terminal from your site root, and this will generate the classmap. You are now ready for PSR-0 compliance! Now you just need to spend all day refactoring! It’ll be worth it when you take your old project to a new framework!  😉

I’ve started using Apigility for building my API for my mobile app of my site! It’s incredible, you have to try it!

Anyway, I wanted to be able to load my existing code into ZF2 so I didn’t have to reinvent the wheel.

My API is running on a subdomain in an api sub folder within the main project. In the api folder, I made a folder called library. Then I symlinked my Zend and other folders from my ZF1 project into it (this may not have been necessary, but I didn’t want ../.. relative link type stuff in my composer.json)

:~/www/site/api/library$ ln -s ../../application/library/Zend Zend
:~/www/site/api/library$ ln -s ../../application/library/ZendX ZendX
:~/www/site/api/library$ ln -s ../../application/library/TTB TTB
:~/www/site/api/library$ ln -s ../../application/library/AA AA

Next you need to do is tell composer.json about your libraries.

 "autoload": {
 "psr-0": {
 "AA_": "library/",
 "Zend_": "library/",
 "ZendX_": "library/"
 }
 },
 "include-path": [
 "library"
 ]

Finally get composer generating autoload files. Type in:

~/www/site/api$ composer dump-autoload
Generating autoload files

And thats it! You should now be able to call things like:

$awesome = new Zend_Pdf();
$old_skool = new AA_Old_Skool_Class();

Yay!

cd-ing into a directory then running ./command, or worse yet, php command.php, sucks!
As an example, I wanted to run the doctrine command from anywhere.
I already have composer installed globally, and no longer have to type php composer.phar, but I haven’t blogged it since it was pretty easy, but anyway here it is:

curl -sS https://getcomposer.org/installer | php
 sudo mv composer.phar /usr/local/bin/composer

Then you can just type composer from anywhere. If you already have composer you should run sudo composer self-update. Anyway on to our php binaries (Doctrine, PHPUnit, Behat, you name it). If it’s a fresh install of composer you should see when you type composer global install:

Composer could not find a composer.json file in /home/username/.composer

Now we know where we can create our composer.json. Go to the sites for the packages you would like and copy paste the require field info; Here is Doctrine’s:

{
    "require":
    {
       "doctrine/dbal": "2.3.4",
       "doctrine/orm": "2.3.5"
    }
}

Now run composer global install and it will install in /home/username/.composer/vendor. The bin folder is inside that. Lastly we need to have our bin path set in our PATH environment variable, so the system knows to check that folder for a binary matching the command’s name. edit ~/.bashrc (it could be .bash_profile or something similar). At the end, paste this in:

export PATH=$PATH:/home/username/.composer/vendor/bin

now exit the shell and open a new terminal up and log back in. you can now type doctrine into the command line and lo and behold, your composer executables are rocking!