Deploy on OVH shared hosting with different PHP versions

Recently we’ve been working on a Symfony project that needed to be deployed on a shared hosting by OVH.

This server was running PHP 5.4 and we could not upgrade it because they had some legacy projects that needed to remain..

So after banging our head quite a few times, we found out that you could create a configuration file so that OVH server reads and reconfigures the settings of the server for that project/folder only.

The file must be called .ovhconfig and it must be on the target folder the DNS points to, so in our case being a Symfony project it should be in the /web folder

app.engine=php
app.engine.version=5.6
http.firewall=none
environment=production
container.image=stable

PHP 5.6 and PHP 7 on same Mac with Liip

So the other day I wanted to upgrade to php7 but didn’t want to completely remove php56 as I still have legacy projects to maintain and I’m not ‘dockerized’ yet..

You can install php with liip here.

Liip doesn’t overwrite Apple’s php binaries, it installs it under a php5 folder under /usr/local/php5 and then creates the link.

All you now need is this handy bash script to switch from one php version to the other.

#!/bin/bash

#usage:
#./switch-php.sh 
#./switch-php.sh php5
#./switch-php.sh php7

#activate php56
if [ "$1" == "php5" ]; then
   sudo rm /usr/local/php5
   sudo ln -s /usr/local/php5-5.6.29-20170114-210819 /usr/local/php5
   sudo pkill php-fpm && sudo php-fpm
   echo "activated php5;"
   sudo apachectl restart
elif [ "$1" == "php7" ]; then
   sudo rm /usr/local/php5
   sudo ln -s /usr/local/php5-7.1.9-20170914-100859 /usr/local/php5
   sudo pkill php-fpm && sudo php-fpm
   echo "activated php7;"
   sudo apachectl restart
else
   echo "parameter expected: php5 | php7"
fi

PS: You’ll have to obviously adapt the version to the one you installed!

Bundle-less applications with Symfony Flex and Symfony4

So these last few days we’ve had a pretty interesting thread on twitter with @gigo6000 and @WladimirAvila about Symfony’s new directory structure, specially about Bundle Inheritance. You can check the thread here

For the ones like me that still didn’t know or haven’t read it somewhere, bundle inheritance is deprecated from Symfony 3.4 onwards, therefore it makes sense to have bundle-less applications from now on.

It turns out that bundle inheritance was rarely used anyway, except for customizing some templates. Who hasn’t inherited the FOSUserBundle before customizing just the login page? And maybe the entity for some extra attributes?

The question that I ask myself though is how are we going to customize all of this now? Not just templates, but all the config associated, services, entities, forms…

To me, one of the best things about Symfony’s magic was the ability to extend ready made bundles/vendors. Hope there’s still a way to do this!

More info on the Symfony4 directory structure here.

More info on bundle inheritence here

Gedmo Tree in Symfony3

So today at work I’ve had to rethink the way we work with products in an app, and it turns out the best way to face the problem is having a tree based architecture, as products can have sub-products and so on and so forth… so instead of reinventing the wheel, why not use a well established library that uses trees right? Gedmo please!

So it’s actually really easy to install Gedmo extensions to your project.

1) First of all composer install it

php -d memory_limit=-1 /usr/local/bin/composer require stof/doctrine-extensions-bundle

(yes I don’t like playing with my php.ini so for this command I rather pass the memory_limit parameter, also remember to put your composer path correctly, as it won’t read your alias if you pass parameters to php)

2) After that you need to include it to you Kernel

$bundles = [
			...
            // Gedmo
            new Stof\DoctrineExtensionsBundle\StofDoctrineExtensionsBundle(),
            ...
        ];

3) And the final step is adding the extra configuration in your config.yml

Under the doctrine.orm configuration:

# Doctrine Configuration
doctrine:
    ...

    orm:
        auto_generate_proxy_classes: "%kernel.debug%"
#        naming_strategy: doctrine.orm.naming_strategy.underscore
#        auto_mapping: true

        default_entity_manager: default
        entity_managers:
            default:
              connection: default
              naming_strategy: doctrine.orm.naming_strategy.underscore
              auto_mapping: true
              dql:
                  numeric_functions:
                      ACOS: DoctrineExtensions\Query\Mysql\Acos
                      COS: DoctrineExtensions\Query\Mysql\Cos
                      RADIANS: DoctrineExtensions\Query\Mysql\Radians
                      SIN: DoctrineExtensions\Query\Mysql\Sin
              mappings:
                  gedmo_translatable:
                      type: annotation
                      prefix: Gedmo\Translatable\Entity
                      dir: "%kernel.root_dir%/../vendor/gedmo/doctrine-extensions/lib/Gedmo/Translatable/Entity"
                      alias: GedmoTranslatable # (optional) it will default to the name set for the mapping
                      is_bundle: false
                  gedmo_translator:
                      type: annotation
                      prefix: Gedmo\Translator\Entity
                      dir: "%kernel.root_dir%/../vendor/gedmo/doctrine-extensions/lib/Gedmo/Translator/Entity"
                      alias: GedmoTranslator # (optional) it will default to the name set for the mapping
                      is_bundle: false
                  gedmo_loggable:
                      type: annotation
                      prefix: Gedmo\Loggable\Entity
                      dir: "%kernel.root_dir%/../vendor/gedmo/doctrine-extensions/lib/Gedmo/Loggable/Entity"
                      alias: GedmoLoggable # (optional) it will default to the name set for the mappingmapping
                      is_bundle: false
                  gedmo_tree:
                      type: annotation
                      prefix: Gedmo\Tree\Entity
                      dir: "%kernel.root_dir%/../vendor/gedmo/doctrine-extensions/lib/Gedmo/Tree/Entity"
                      alias: GedmoTree # (optional) it will default to the name set for the mapping
                      is_bundle: false

Yes, it’s important to remove the auto_mapping as it won’t recognize the key under doctrine.orm

And under the stof_doctrine_extensions configuration:

# Stof Configuration
stof_doctrine_extensions:
    default_locale: "%locale%"
    translation_fallback: true
    persist_default_translation: true

    # Only used if you activated the Uploadable extension
    uploadable:
        #stof_doctrine_extensions.uploadable.validate_writable_directory
        validate_writable_directory: true

        # Default file path: This is one of the three ways you can configure the path for the Uploadable extension
        default_file_path:       "%kernel.root_dir%/../web/uploads"

        # Mime type guesser class: Optional. By default, we provide an adapter for the one present in the HttpFoundation component of Symfony
        mime_type_guesser_class: Stof\DoctrineExtensionsBundle\Uploadable\MimeTypeGuesserAdapter

        # Default file info class implementing FileInfoInterface: Optional. By default we provide a class which is prepared to receive an UploadedFile instance.
        default_file_info_class: Stof\DoctrineExtensionsBundle\Uploadable\UploadedFileInfo
    orm:
        default:
            translatable:   true
            blameable:      false
            timestampable:  true
            tree:           true
            uploadable:     false
            sluggable:      true

That’s it! You’re set, super easy right?

Now let’s go to the entity, in my case it’s the Product. Don’t forget to import the Gedmo annotation and then add the annotation to the class, like so:

use Gedmo\Mapping\Annotation as Gedmo;

/**
 * @ORM\Entity(repositoryClass="AppBundle\Repository\ProductRepository")
 * ...
 * @Gedmo\Tree(type="nested")
 */
class Product
{
	/**
     * @Gedmo\TreeLeft
     * @ORM\Column(name="lft", type="integer")
     */
    private $lft;

    /**
     * @Gedmo\TreeLevel
     * @ORM\Column(name="lvl", type="integer")
     */
    private $lvl;

    /**
     * @Gedmo\TreeRight
     * @ORM\Column(name="rgt", type="integer")
     */
    private $rgt;

    /**
     * @Gedmo\TreeRoot
     * @ORM\ManyToOne(targetEntity="Product")
     * @ORM\JoinColumn(name="tree_root", referencedColumnName="id", onDelete="CASCADE")
     */
    private $root;

    /**
     * @Gedmo\TreeParent
     * @ORM\ManyToOne(targetEntity="Product", inversedBy="children")
     * @ORM\JoinColumn(name="parent_id", referencedColumnName="id", onDelete="CASCADE")
     */
    private $parent;

    /**
     * @ORM\OneToMany(targetEntity="Product", mappedBy="parent")
     * @ORM\OrderBy({"lft" = "ASC"})
     */
    private $children;

    ...
}

Running the command

bin/console doc:gen:entities AppBundle:Product

will generate all the getters and setters, pretty handy…

And now the repository:

use Gedmo\Tree\Entity\Repository\NestedTreeRepository;

/**
 * ProductRepository
 *
 * This class was generated by the Doctrine ORM. Add your own custom
 * repository methods below.
 */
class ProductRepository extends NestedTreeRepository
{
...
}

The NestedTreeRepository has very useful functions, play with them before making your custom ones, cause they’ve already thought with pretty much everything, for instance the function childrenHierarchy() gives you the nested array, with decoration output if you pass parameters as options. You can find more info in the RepositoryInterface and RepositoryUtilsInterface from Gedmo\Tree namespace.

PS: Don’t forget to run your schema update command

bin/console doc:sch:update --force

Now you focus on what really matters, you project’s logic.

Happy coding! 🙂