Some tips for the web development workflow with PHP

I’ve been a freelance web developer for almost two years. The majority of my projects were PHP websites or admin panels, and I usually work with this workflow and setup:

I always serve my development project through a remote server. That way, I don’t have to worry about setting up my local environment exactly like in my remote server. If there are another developers working in the project too, several problems could arise if we don’t share the same local OS, so working with a remote development environment prevents that kind of problems too. So, my local project is a clone of the remote git repository, while, also, is a folder mirrored with the remote development folder for the project.

So I push copies of mi local .php files from my local project to the remote development project through scp on change. I use an atom package to do so, but most IDE’s and code editors have similar packages and you can configure Gulp to get it work too. That allows to make really quick changes without messing with git push or any deploy tasks and show them straight to a client in another location in no time.

For .js and .scss or .less files, instead, I use a gulp setup that do all the compilation/concatenation task and then push the result .css/.js file(s) to the remote folder through scp. For instance this is a gulpfile.js I used in a project:

var gulp        = require('gulp');
var gutil = require('gulp-util');
var less        = require('gulp-less');
var sourcemaps = require('gulp-sourcemaps');
var concat = require('gulp-concat');
var uglify = require('gulp-uglify');
var exec = require('child_process').exec;
var minifyCss = require('gulp-minify-css');
gulp.task('syncStyles' ,['styles'], function(){
exec("pathToLocalStyles.css pathToRemoteStyles.css");
gulp.task('syncScript' , ['build-js'] , function(){
exec("pathToLocalApp.js pathToRemoteApp.js");
gulp.task('styles' , function(){
return      gulp.src(['src/less/specific.less'])
.pipe(less() )
.pipe(minifyCss({compatibility: 'ie8'}))
.pipe(gulp.dest( 'public/assets/css' ) );
gulp.task('default', ['watch'], function(){
gulp.task('build-js', function() {
return gulp.src([  
.pipe( uglify() )
gulp.task('watch' , function(){['src/less/**/*.less'] , ['syncStyles']);['src/js/**/*.js'] , ['syncScript']);

Some PHP developers just build their projects in the same folder they’re serving with apache or nginx, causing a little time when the webpage is not visible or the styles are not applied correctly. A simple way to avoid this in PHP is just to point your web server to a symlink that points to a folder; let’s say the symlink www/ points to production/. You can just clone your production/ project folder to a clone/ folder, and then point your symlink there with:

ln -sfn clone www

Then you just delete production/ and deploy your project into a brand new production/ folder, which can take some time: maybe some tasks must be done, composer scripts must be run, or heavy files like .mp4 must be copy into the folder. Since we are serving the project inside clone/ as we deploy, there is no problem with that. When the process is finished, just point the symlink to it again, leaving the clone/ folder with the older version useless. Its good to store the last few deployed versions of the project in a specific folder, so if there is a problem and you need to rollback the site to the previous version, you can do it really easily instead of messing with git versions and with no need to deploy again, so it can be really fast.

If you’re working with frameworks that serve from the public/ folder -or whatever non-root folder-, there is no mess with this. You just need the web server to properly point to that folder, that’s all.

Another important tip I think every PHP developer should be aware of, is to understand quite well Composer and the psr-4 standard. To not do so implies a lot of manual effort to set up external libraries in every deploy, or to add them to the version control repository -which is not a good practice and can lead to several problems as well-. Also, if you’re working with a front-end developer who is not too used to mess with PHP, a good composer set up can save him a lot of problems.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.