When the intention is to write code, to tackle bugs or to just look at the sources, it's always a good idea to do a developer installation. It's not more challenging than an ordinary installation, but one can have a look at older revisions, easily create patches and record changes with only few Git commands.

Developer installations work exactly the same way¹⁾ as installations from the thirty bees release package. It's said that some merchants even run their public shop this way, which is fine.

This page assumes an already working LAMP (or MAMP or WAMP) stack. Which means, one should be able to access self-uploaded files by the command line shell as well as by a web browser. A local installation on an ordinary desktop or laptop PC is entirely sufficient. Web pages are assumed to live in /var/www/html/, which happens to be the default on Ubuntu and Debian. The web server is assumed to run by user www-data and distinct from the developer user account (mah).

On Debian/Ubuntu, installation of Git and Composer is pretty trivial:

sudo apt-get install --no-install-recommends git gitk composer

Actual source code download is pretty straightforward:

cd /var/www/html
# Create a directory owned by the developer.
sudo mkdir thirtybees
sudo chown $(id -u):$(id -g) thirtybees
# Clone the Git repository.
git clone https://github.com/thirtybees/thirtybees.git --recursive
# Install dependencies.
cd thirtybees
composer install

The last command takes a while and consumes like a gigabyte of memory.

At this point the situation is that the sources are owned by the developer, while they're about to get handled by the web server user. Running a shop includes file creations by the web server, which has no privileges to do so in developer-owned directories.

For installations in a Git repository, one should move .git aside first, see Github Best Practices.

To solve this conflict, extended Access Control Lists (ACLs) come to the rescue. Setting this up looks a bit complicated, but it has to be done only once. For more details, see the Git Wiki. Here we can simply copy & paste (except for the second line):

cd /var/www/html
REPOSITORY=<installation folder>
ID_ME=$(id -u -n)
ID_WEB='www-data'
# Set existing files.
setfacl -Rm u:${ID_ME}:rwx "${REPOSITORY}"
setfacl -Rm u:${ID_WEB}:rwx "${REPOSITORY}"
# Set the same as default for files created in the future.
setfacl -Rm d:u:${ID_ME}:rwx "${REPOSITORY}"
setfacl -Rm d:u:${ID_WEB}:rwx "${REPOSITORY}"

That's it, now the developer can edit server-generated files and vice-versa. One can see a + appended to permission flags in a file listing as a reminder that extended ACLs are set:

$ cd "${REPOSITORY}"
$ ls -l
total 170740
drwxrwxr-x+   2 mah      mah          4096 Jun 12 17:26  Adapter
drwxrwxr-x+  10 mah      mah          4096 Jun 26 16:25  admin-dev
-rwxrwxr-x+   1 mah      mah          9813 Jun 21 19:24  build.sh
[...]

Works exactly the same as with an installation from the ZIP distribution. Direct your browser to http://localhost/thirtybees/ (you can click this link) and proceed.

There are a few things one should not do with a developer installation.

Don't update modules by clicking Update in the module list in back office -> Modules & Services. This certainly updates the module, but also deletes its Git repository. Updating is implemented by deleting the entire module directory, then replacing it with contents of the upgrade package.

If you want to upgrade or downgrade a module, do this with Git commands. Each module release gets tagged in its repository. For example, this upgrades module Block Languages to version 2.0.1:

cd modules/blocklanguages
git fetch origin
git checkout 2.0.1

Sometimes a developer wants to verify the installation process, needs an entirely different installation or simply messed up beyond repair. Time to clean out an existing installation for starting over.

Cleaning can happen like this (simply copy & paste to the command line):

rm -rf cache translations mails log img override admin-dev/autoupgrade config/settings.inc.php config/shop.inc.php themes/community-theme-default/lang modules/*/translations/ modules/*/mails robots.txt .htaccess
git checkout .
(cd themes/community-theme-default/; git checkout .)

This also removes the database, assumed to be named thirtybees:

sudo mysql --defaults-file=/etc/mysql/debian.cnf -e 'DROP DATABASE `thirtybees`;'

Given Debian/Ubuntu's great packaging system, that's not too complicated either.

Notably, PHP used by the web server and PHP used on the command line can be of distinct versions. One can change them individually.

Simply copy this to your command line:

sudo add-apt-repository ppa:ondrej/php
sudo apt-get install libapache2-mod-php5.6 php5.6-gd php5.6-bcmath
sudo apt-get install php5.6-xml php5.6-json php5.6-zip php5.6-mysql
sudo apt-get install php5.6-mbstring php5.6-mcrypt
sudo apt-get install libapache2-mod-php7.0 php7.0-gd php7.0-bcmath
sudo apt-get install php7.0-xml php7.0-json php7.0-zip php7.0-mysql
sudo apt-get install php7.0-mbstring php7.0-mcrypt
sudo apt-get install libapache2-mod-php7.1 php7.1-gd php7.1-bcmath
sudo apt-get install php7.1-xml php7.1-json php7.1-zip php7.1-mysql
sudo apt-get install php7.1-mbstring php7.1-mcrypt
sudo apt-get install libapache2-mod-php7.2 php7.2-gd php7.2-bcmath
sudo apt-get install php7.2-xml php7.2-json php7.2-zip php7.2-mysql
sudo apt-get install php7.2-mbstring # There is no php7.2-mcrypt
sudo apt-get install libapache2-mod-php7.3 php7.3-gd php7.3-bcmath
sudo apt-get install php7.3-xml php7.3-json php7.3-zip php7.3-mysql
sudo apt-get install php7.3-mbstring # There is no php7.3-mcrypt

Run this on the command line and choose the wanted version:

sudo update-alternatives --config php

Again, this can be done with a few simple commands:

sudo a2dismod php*
sudo a2enmod php5.6 # <== adjust according to the wanted version
sudo service apache2 restart