Live Q&A with Bruno Škvorc on PHP Environments - Feb 4, 1PM (PST)

You tweeted that we should avoid using node. I think you need to write an in-depth article about how to do that.

Wait, avoid Node? why?

Hi @cashwilliams,

thanks for the question!

There’s an easy solution to this, actually. When you run composer install, Composer will create a composer.lock file in your project where all the currently installed versions of all the dependencies are noted. This file is to be committed to version control along with everything else you wish to deploy. This makes sure that when you run composer install on a production server (during deployment) only the versions you’re also using locally are installed on your live server. That’s step one of production server protection - the inability to go beyond the local-dev version of a package, so production is in sync with local.

Step two is following the packages you’re interested in - Versioneye can help with that, it’s an amazing tool. It’ll send you daily notifications about outdated dependencies. When you notice a dependency is out of date, take a look at the changes. If it’s something you need to apply, delete the local composer.lock, change the version in composer.json locally and have composer.lock regenerated, and if your application still works as expected, push this new lock file online. Run update on the production server, and the package will be up to date again.

An alternative (one I do not favor) is not using composer.lock in production and instead relying on minor version constraints in composer.json. For example, declaring a dependency version as ^2.3 will make sure the minor version is updated when needed, but not the major. This means no BC breaks, and you can run a daily cron for updates - but you have to rely on package maintainers to follow Semver. That’s a bit too much trust for my liking.

For some more info about the lock file see here.


Well, obviously PHP 7 wins on all fronts. It’s faster, uses less memory, and has more features. The updates would be too numerous to list, so I encourage you to look at this post.

As for migrations, I would recommend the official migration guides at and follow the versions from the one you have to 7.0.

1 Like

He did.

1 Like

What exactly is your concern?

Hi. Appreciate any guidelines with regard to PHP application deployment on-prem for Customers while protecting against piracy of the source code as PHP is interpreted at run-time as against compiled executable for other programming environments.
Appreciate your feedback

Q&A with Bruno Skvorc


There’s too little information about it and it is hard to find. It seems that we don’t look further than using PDO. And there’s even less information about proper security testing so you only do the obvious

Missed that one. Thanks

1 Like

I do not. I have tried it out, but only for local development - not for deployment. While I agree that Docker is a fantastic piece of technology that should find its home in many a complex app, I don’t favor it for the following reasons:

  • it doesn’t work identically on all operating systems. I, however, do. I hold workshops, do mentoring, develop on the road, and develop at home - all these environments have different prerequisites, and I want my tools to work identically across all of them. With docker, that’s just too much trouble. With Vagrant, I’m always 5 shell commands away from a running VM.
  • not all apps are microservices, and most won’t be deployed as such. Docker excels in separating the database from the logic, from the logger, from the job queue, etc. But chances are any app one will be developing is, in fact, perfectly suited to be a microlith (a small monolith?) because it’s likely not going to be generating so much traffic it would even tax a single $5 DigitalOcean droplet to its full extent. In most cases, I would argue, Docker is just unnecessary.

That said, if I were going into a real heavy-duty project with a team, knowing its architecture and planned scope, I’d probably opt for docker from the get-go.


I find manage my own VPS - risky task…I always afraid to use CLI in Linux remote VPS,…So always outsource it… you have help articles/tuts in Sitepoint of this?
I currently do some Shell Scripting course online… And I should consider Practice on VM Linux…I am in right way? What follows?

BTW migrate Servers - now Cent OS 6.5 - I strangle what next new VPS : Ubuntu or Cent OS you have help articles in Sitepoint of this pros & cons & advise to decide?

And lastly (sorry all in one post) GIT in book about Server update web files + migrate + auto update hosting files on update , can be done from - that gives Free Private Repos…?

Well, when working locally, I usually go for XDebug and breakpoints set up with PhpStorm (see here), and for simple debugging I use Vardumper. For more serious debugging, I go with Blackfire - an absolutely amazing tool that can optimize even the worst apps. When doing contract work, I also implement Bugsnag just so I can trace the errors more easily.


Thanks, VersionEye looks to be what I’ve been looking for!

Haha, I was wondering if someone would :smile:

There are actually a few pictures on my first treadmill adventure blog at Look around :smile:

But yeah, basically, just a plank across the handles, peripherals on top, and that was it. I suspended the laptop on a fake shelf above the treadmill, as you’ll see in the pics.

Oh there’s also another pic here of a more recent setup.

1 Like

Hi Bruno - do you have any experience with Nette framework? If so what do you think about it (e.g. in comparison with Laravel)?

I’m on the last chapter of your book, I read it b/c I heard (and agree) that it was a great introduction to PHP and getting started right. I’m planning on reading Jump Start PHP, but the Jump Start series are short books, and I feel I will want to get more in depth into PHP. What would you recommend I read next?


Definitely, I agree. If you have many sites, then I would definitely recommend transferring them one by one.

However, if your VPS is at DigitalOcean, I have an interesting service to suggest: - they can hook into a server, then you set up as many sites as you want, and they install several versions of PHP. Then, you can switch the version of PHP for each individual app as you see fit, like this:

This would help you test upgrades on the same server where your apps already are :smile:

1 Like

I know that sounds cheesy, but when and what was your very first commercial PHP project?

(I obviously am not the right person to ask technical PHP questions :smile: )

@jeffreylees beat me to it - I did indeed write a tutorial about a node-free setup here :smile:

As for why, it’s just personal preference. I think it’s a fad, an unnecessary (and very unstable and bad) tool, and a horrible language, much worse than what people make PHP out to be. In fact, we had a vigorous discussion about it here. For further arguments against the silliness of modern JS apps, see:


Bruno you mentioned mastering data mining and common machine learning algorithms in Are there any PHP tools/libraries you can recommend for this?