Local composer package development

A new feature on composer which I really appreciate is the “Path” repository type.

Imagine you are working on your super-cool-project, and one task requires new functionality where there is no composer package existing yet – yeah, this probably is a bit hard to imagine. Now you want to create your own super-awesome-package, because we all like it nice and separated and such.

So far, I would have developed the super-awesome-package directly inside the vendor folder of my super-cool-project – which somehow did not feel right. Obviously others felt the same, so now we can use the “path” resource type for packages which you develop right at the moment!

  "require": {
    "my-namespace/shoppingcart": "*@dev"
  "repositories": [
      "type": "path",
      "url": "../shoppingcart"

Instead of using VCS as package source, you simply specify the directory (relative or absolute path both work) where your super-cool-package is located on your machine. In my case, I just refer to the shoppingcart folder, where the package is currently developed.

Composer will then add a symlink in the vendor folder upon running composer update, so all your changes on that package can immediately be used in your super-cool-project.

Now that’s what I call convenient!

Remote CLI debugging with XDebug

There are quite some tutorials out there on how to use XDebug to debug PHP CLI code, which where more confusing than helpful (to me). I found out that, once you have a running XDebug configuration, it is very easy to debug on the console, particularly with phpStorm.

Simply run the following line once

export PHP_IDE_CONFIG=serverName=www.domain.com ; export XDEBUG_CONFIG=idekey=PHPSTORM

(after customizing it to your needs, of course), set your breakpoints and run the script. That’s already it. You can also put this into your .bashrc file.

Use HeidiSQL with your vagrant box

I already discussed how to use HeidiSQL with a remote server in a former post. I now switched to use a local Vagrant VM instead of a remote VM. Of course I still wanted to use my beloved HeidiSQL. And it is – again – very easy!


On the above page, you need to use the MySQL Username and Password.


On the “SSH tunnel” tab we have to use the Username and Password for the SSH connection. I use a Private Key instead of a password, so I leave the password empty and specify the Private key file instead.

My box is configured to use SSH port 2222 instead of the default port 22. This will most likely differ on other boxes, so it is worth to check this first if the connection is not possible.

That’s it ๐Ÿ™‚

Expand your Windows Taskbar: Dual Monitor Taskbar

If you use multiple monitors with Windows, and ever wanted to have the $%#ยง! taskbar spread across all monitors, here’s your cure:


It can also be set up to let the Windows only appear on the taskbar of the actual screen. This is very handy.

It’s free, but it hasn’t been updated for a while. Better get your copy now.

PyCmd & Console2 – Windows command prompt reloaded

Finally! A command prompt for Windows that doesn’t suck! Now the Linux guys have no reason to smile at (the) Windows (console) anymore.


It offers you a searchable(!) command history(!) and surely some other cool stuff, but I stopped reading at this point and directly installed it right away.

It integrates nicely with


which amongst other kick ass features allows multi tabs(!) and a not-totally-weird-and-counter-intuitive way to Copy & Paste text. Nice.

Just go to Settings > Console and select the PyCmd executable for “Shell”. If you want to define different tabs go to Settings > Tabs. This way you can also integrate MINGW32, the Linux bash emulator for Windows that comes shipped with Git for Windows.

Ultimate command prompt power unleashed. Sort of.

Neor Profile SQL

Recently I discovered a free and easy to use SQL Profiler for Windows, Mac and Linux:


It works as proxy between the Application and MySQL itself, so basically all you need to do is configuring your Application to use it by simply adding the port number 4040 to the host (and configure the Proxy to connect to MySQL, of course).

As inherent to the functional principle of a Proxy, the Profiler has to be running – so don’t forget to remove the port from the host when you don’t need it.

Updating XAMPP without a headache

After some years the time has come to update my local WAMP stack to a more recent PHP version. I also made good experiences with WAMP (the other cool stack for Windows), but I’ll stick with XAMPP and install 1.8.2. This will also make things easier.

  1. Rename the old xampp installation directory C:\xampp (or where you installed it) to C:\_xampp
  2. Install new XAMPP under C:\xampp
  3. Copy all (needed) files/projects from C:\_xampp\htdocs to C:\xampp\htdocs
  4. Copy all (needed) databases from C:\_xampp\mysql\data to C:\xampp\mysql\data. EDIT: Don’t do that if your databases contain InnoDB tables. Use mysqldump instead.
  5. Check differences between both php.ini files, located in C:\xampp\php
  6. If you made changes on your MySQL configuration, don’t forget to check C:\xampp\mysql\bin\my.ini as well
  7. check your PHP Extensions in php/ext: you will need new versions of any additional PHP extensions (e.g. libpdf). Keep in mind that PHP 5.4 has been compiled using VC9 instead VC6 as in PHP 5.3 when chasing for downloads!
  8. Take over changes in C:\xampp\apache\conf\httpd.conf – most likely you’ll have some VirtualHost configurations
  9. Run the security check in XAMPP (http://localhost/security/index.php) to set the MySQL password to the same password you used in the old XAMPP installation (if you’re using a password)
  10. Be happy! You now shouldn’t need to change any path configurations, passwords etc. to run your web applications on your new PHP 5.4 stack!

The actual migration from PHP 5.3 to 5.4 shouldn’t be a problem, as there aren’t that many compatibility issues. I didn’t experience any PHP issues so far.

I was rather concerned about just copying the MySQL files – but it worked like a charm and is definitely quicker than doing mysqldumps and loads on many big databases – UNLESS you don’t have InnoDB tables in your databases. In this case better use mysqldump. In general it’s a good idea to keep an eye on the mysql_error.log in the data directory.

Good thing about this approach: you still have your old XAMPP installation at hand which you can reuse by simply renaming the two directories. Always be backed up!