Not sure if a ‘LAMP container set’ is the right name, but I have a docker-compose container set that includes Nginx, PHP and MySQL. I seem to build them regularly so thought I’d create a template to start from.
The more development time we spend on the corporate Laravel app the more mature the code becomes and the more our development practices evolve.
One of the introductions was to ensure we carried out unit testing on our modules and classes to ensure we don’t break any existing functionality by introducing new features.
We started using PHPUnit to carry out the testing for our Laravel/PHP API’s. Now when we run our tests can we really be sure we haven’t broken anything? All we’re really doing is proving that we get consistent results to our tests. What we aren’t sure of is if the tests we have built are sufficient to cover all eventualities handled by our code eg. we know the test works when we pass in valid parameters, but did we write a test that passed in bad parameters, or test that we get a failure when we should?
This is where PHPUnit’s code coverage plugin comes into it.Continue reading
Actually this is more about any version of php (5.6, 7.0, 7.1, 7.2) on buster. Php source has taken on a bit of a split and the standard repositories only deal with the one supported version for the current release of Debian you are using.
This means that on Debian 9 (buster/sid) the only version available from the Debian repository is php 7.3.
Our current production systems are Debian 9 stretch and only support php 7.0 and therefore only Laravel 5.5. In order to bring my development platform down to php 7.0 I must use a non-standard repository.
Ondřej Surý has been packaging php for Debian and Ubuntu and distributing them. To get them you need to add his key and repository into your aptitude:
$ wget -q https://packages.sury.org/php/apt.gpg -O- | sudo apt-key add - $ echo "deb https://packages.sury.org/php/ buster main" | sudo tee /etc/apt/sources.list.d/php.list
Now you can add in whatever version of php you’d like even 5.6. eg.
$ sudo apt-get install php7.0-fpm php7.0-mbstring php7.0-zip php7.0-mysql php7.0-sqlite3 php7.0-dev php-pear
If you already had 7.3 installed nothing will have changed yet and when you type php from the command line you’ll see it still runs version 7.3.
$ php -v
PHP 7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f (cli) (built: Dec 17 2018 09:26:59) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f, Copyright (c) 1999-2018, by Zend Technologies
To switch back to 7.0 use the following and you’ll see your php go back to 7.0. Switch back in the same way, but replace 7.0 with 7.3.
$ sudo update-alternatives --set php /usr/bin/php7.0
update-alternatives: using /usr/bin/php7.0 to provide /usr/bin/php (php) in manual mode
$ php -v
PHP 7.0.33-1+0~20181208203126.8+stretch~1.gbp2ff763 (cli) (built: Dec 8 2018 20:31:26) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.33-1+0~20181208203126.8+stretch~1.gbp2ff763, Copyright (c) 1999-2017, by Zend Technologies
I’m trying to test out a version of a SAML project that doesn’t include the now defunct php extension for mcrypt. Using composer require kept on grabbing the master branch, when I actually wanted the “remove_mcrypt” branch.
I found that using composer with the branch like this failed:
$ composer require "aacotroneo/laravel-saml2":"remove_mcrypt"
Could not parse version constraint remove_mcrypt: Invalid version string “remove_mcrypt”
Thanks to a stackoverflow post: https://stackoverflow.com/questions/33525885/composer-require-branch-name I was able to resolve it by correctly prefixing the branch with “
$ composer require "aacotroneo/laravel-saml2":"dev-remove_mcrypt"
I needed a mechanism to upload CSV files to my Laravel instance and then process them into a table. The first part was working out how I wanted to upload the files.
I came across
blueimp-file-upload which seems pretty popular and capable.
There was no need to go overly fancy. Just a simple form will do as the file will probably be uploaded as a single file. First I had to figure out how to get blueimp into Laravel.
What a mission today has been. I think I’ll ultimately roll back to using Debian Jessie as Stretch isn’t a supported system, yet.
To get the MS SQL ODBC driver working even in Jessie appears to be a challenge. In Stretch I almost surrendered. It is working, but I do think it’s a bit of a hack as I’ve had to install an older
libssl1.0.0 and enable the locale
As it’s downloaded using apt over https you’ll need to add in the
apt-transport-https package to your system:
$ sudo apt-get install apt-transport-https
Or you will get this error
Reading package lists… Done
E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?
E: Failed to fetch https://packages.microsoft.com/debian/9/prod/dists/stretch/InRelease
E: Some index files failed to download. They have been ignored, or old ones used instead.
PHP development voted out the inclusion of MS SQL to the project so now you must compile and install it yourself. There are some very good instructions out there to help you – even from Microsoft.Continue reading
Make sure you’ve installed php and the necessary modules before trying to create a new Laravel project.
$ sudo apt-get install php-fpm $ sudo apt-get install php-mbstring php-zip
The order of
php is important as putting them the other way around you’ll find you get
apache2 installed when you probably don’t want that.
Then you should be able to create your empty project using composer without any complaints.
$ cd /var/www $ composer create-project --prefer-dist laravel/laravel [project]
This catches me out almost every time I do an update of our Owncloud server. As it’s using a Debian repository a simple
apt-get upgrade is all it takes to deploy the Owncloud upgrade, but then it sticks in maintenance mode and the upgrade hasn’t really run. It’s just downloaded and waiting deployment.
We needed a semi-secure method of transferring files between staff and 3rd parties. To handle those frequent times when someone tries to attach a 150MB file onto an email. OwnCloud to the rescue.
It’s come a long way since I first used it. Now it has all kinds of plugins and features. What’s good about it is there are clients for pretty much all platforms – many free. Failing that good old HTML will do.
This new version of NGINX is tending to be a bit of a pain in terms of installation. Gone are the sites-available and sites-enabled folders and it does a couple of things during installation that really grips my goat.
Getting php5-fpm working with it needs some manipulation of the config. The site configs are now located under /etc/nginx/conf.d/ and they now have a .conf extension. The default being default.conf.
By default this config sticks the ‘root’ directive under the location /. Which when it comes to running php5-fpm and using fastcgi parameters causes a headache. It’s a simple fix, but put simply the previous use of $document_root will not work because the directive needs to be within the server context NOT location.
Having had the pleasure of handling json data I found that there are a few implementations within PHP libraries that I could make use of rather than rolling my own.
The one I settled on ‘tobscure/json-api‘ met my needs and was easy to use.
I’m not new to PHP and have used it quite often, but what I’ve not really used are frameworks. There are plenty of them out there all capable of different things, but all able to save a whole heap of time when it comes to developing something more than a simple script.
The one I’ve tended to favour is ‘Laravel‘. It’s pretty fully featured and fairly straight forward, but there is a lot to learn.