Using composer in your local dev environment

With OXID eShop 6, composer was introduced for the installation of the shopping cart system, as well as for updating it and installing modules (functional overwriting of existing classes and methods). From a pure technical point of view this was 100% a step in the right direction – some other PHP projects like Contao or Typo3 took this path already, others will definitely follow in the near future.

However, there’s still the question floating “should I use composer on my live OXID eShop instance or do I use it in a development environment locally first?”.

Experienced power users would always answer this question like “well, if you know what you’re doing”. But IMO, this is not the entire truth: Composer is a PHP tool that manages dependencies between the used libraries and versions of tools used in an application like OXID. My concern is: what happens if in the very moment you compose a new update to your OXID eShop productive instance when somebody – lets say from any FOSS library used – decides to cancel his service on GitHub? Right: your entire instance will be blown in that moment of your open-heart surgery.

That’s why I always suggest to use a development environment just for development purposes on your local machine where you can run composer without any risk and upload the results of your work to your productive server environment – for example via (S)FTP.

This local environment doesn’t necessarily have to be a docker or vagrant box – these are just proposals that might work smoothly. Basically, the only thing that is important is that your dev environment is as equal as possible to your server environment: as composer naturally manages dependencies, you might have different results in library and other component versions if your local environment is different to the productive one, savvy?

Read out server environment

As said above, let’s configure the local environment as equal to the productive server environment as possible. Hence, we need to read out the packages installed on the server. If you have SSH access, please connect to your server and run the following command. Best practice: pipe the output into a text file:

dpgk -l > server_conf.txt

(Thanks to my mates at the Facebook group Linux Helpdesk Germany, especially @Tomas, for this valuable hint!)

Without SSH access, this is scarcely possible. Maybe you can ask your web hosting provider to run this command and pass the results to you (at least for some bucks this should be possible).

As your web hosting provider may update their server environments from time to time, you should execute this command regularly.

If you don’t have SSH access but can run cron jobs on your hosting environment, you can also put this command into a shell script and run a (weekly?) cron job on it.

Compare with your local machine

Compare the results with the configuration in your local machine (be it docker, vagrant or anything else). The advantage in these virtual boxes is that you can configure it according to your server environment in your config YAML file before your start it the first time.

For example: if you notice that your server runs PHP 7.1 where your local machine is still using PHP 5.6 => change this behaviour in the config YAML of your local machine to PHP 7.1 along with other discrepancies. Now provision your local machine and off you go.

Or – in case your local system is already running – get the same information about your local system with the command mentioned above. Compare both files with diff and re-provision your local instance to adjust it to the productive environment.

It might become a bit more complicated if you run one of these old fashioned XAMP, WAMP, MAMP or LAMP environments. Sorry if I can’t help you with that at all as I refuse to have a clue about it ?

Develop locally – upload your work

Now you should be able to install and update your OXID eShop project locally as well as to install modules and/or change the storefront. You may even upload your work to your production server via Grandpa FTP – great, isn’t it?

Here is even more for you to read:

Questions, comments, improvements and even contrary discussions welcome.

3 Likes