How to ignore or include files by wildcards in a Magento tgz package

When you’re packing Magento extensions in Magento admin and want to ignore (or include) a file or directory then there’s a special syntax for it. Let’s say you want to exclude folder “tests” from the tgz package. Number signs (#) are used as wildcard placeholders. Add following line to “Ignore” field:

Your tests folder will be excluded from the tgz package.

PHPStorm and OSX Yosemite Java problem


I just upgraded to OSX Yosemite. It looks pretty cool and works fine. In addition to Java, CSS, Javascript we are writing a lot of PHP while develop data management solution MageFlow for Magento.

I noticed a problem when I tried to start my everyday IDE PhpStorm:



Stop! I just upgraded to a fresh, new OSX and I’m forced to install an almost 10 year old Java? Nope…

I have Java 8 installed to my Mac and I thought it would be cool to run PhpStorm on top of that one.

So I looked around and the solution is surprisingly simple.

Solution 1 (deprecated – see the update)

Open file /Applications/ with your favorite editor (mine is vim)

Find the following tag:


Below that one there should be


or similar.

Replace 1.6* with


Start PhpStorm.



Important update

It’s important to know that changing the Info.plist file would break the application’s digital signature. There are consequences like the app asking for firewall permissions on each start and not the patches not being applied properly. See more info on JetBrains Support page.

In short you need to add the wanted Java version to a preference file instead of hacking application’s Info.plist.

In my case I created file ~/Library/Preferences/WebStorm9/ with contents:


This applies for WebStorm but it’s done the same way for all JetBrains IDE-s. Just change the app name in the path.

For PhpStorm put the file to:


Thoughts on digital garbage

This article was first published in LinkedIn.


We all know what garbage and littering is. We know it, we feel it, we see it, we – people with good kinderstube –  despise it and fight it. We clean it up.

I feel the same way about digital garbage. Do you – a fellow e-citizen with good manners in digital environment – feel it, too?

I feel there is too much digital garbage. It’s everywhere, it suffocates me. I feel really bad if I see people creating more and more useless, excessive data every day.

Painful experience

I used to work at a big corporation for many years. As in every big company this company hosts some morons, too, who make themselves useful by creating Powerpoint slideshows of tens and tens megabytes and then spread these files by e-mail to present often outdated and useless information to colleagues or customers. Nobody raises an eyebrow because it’s normal there. I’m absolutely sure that this big corporation is not an exception. It’s the rule. It happens everywhere, in almost every company.

It does not happen in my company. Otherwise I’m pretty open minded and tolerant but I do not tolerate digital littering at MageFlow. It’s a clearly stated policy and it’s repeated over and over again.

For me it comes down to three things: skills, ethics and energy.

Please continue reading if you care about cleaner e-nvironment.


Most people don’t have the skills to behave correctly in digital environment. They’re like young calves in the spring. Nobody has told them how to handle data properly without creating another and another and another useless copy of it.

I’ve brought this example before but I guess it’s good enough to repeat it here. Please do a little math for me now and tell me how many copies and megabytes of one file with size of 1 megabytes there will be if you send this file to 2 of your friends by e-mail? 1? 2? 3? 5?

Correct answer is at least 4 assuming your friends don’t save it to their harddisk and not including all the possible e-mail servers that may or may not keep an additional copy for whatever reason.

How’s that possible then? Here’s how:

1 – original file on your computer’s hard disk

2 – a new copy attached to the e-mail in your sent mail folder

3 – a new copy in your friend #1’s inbox

4 – a new copy in your friend #2’s inbox

Is that enough copies for you? For me it’s 3 too many. The files are stored somewhere, the files will be stored somewhere. Forever – I tend to think nowadays. There’s also question about file versions, integrity, consistency. I mean – can you tell me now which version of those 4 files is THE correct one, the master version? Can you? I can’t!


Actually I think it’s unethical, unfair to litter other people’s digital space the same way it’s unethical and even criminal to litter other people’s physical property. It’s not right to make other people to buy more and more storage because you cannot send links instead files or you cannot use streaming instead of downloading.

It’s like littering someone’s backyard. You don’t do that IRL. Why should you do it in the Internet? However, it’s not that simple always.

Sometimes I send images of my kid to my mom as attachments because I know she would call me otherwise and ask if she should open that (whateverish*box or *drive) link in that e-mail or is it a virus or … Moooommmm!!! Oehhh…

Eventually it’s about skills. It’s about education. It’s about experience.

We – the responsible and aware e-citizens – should teach the less knowledgeable. Be it our parents, our brothers and sisters – we need to teach them behave in the modern digital environment – the e-nvironment. There are do’s and don’ts exactly like in the real world. This is our responsibility to spread the world and behave as role models. It takes a lot of patience, though.


There are also energetical issues. Maybe those more at home at physics or information technology know the answer already but I don’t. Feel free to comment if I’m wrong here.

Anyway – we spend energy, a lot of energy on storing data, the bits and bytes, on different types of storage. What happens to that energy once we delete a file? Is it being freed? Where does it go? How to catch it, how to reuse it? I mean – almost metaphysically – what happens to that information that was just there – ␡ – and it’s gone. Where did it go? What did it become now?



The wrong way to handle data is to create more copies of it that are possibly false and outdated. The right way to handle data is to maintain an original and enable others to access it. Thank to all gods – Odin and fellows included – that there are tons of sharing solutions nowadays. It hasn’t been the case always. And it’s not the case in the corporate networks because these big corporations are still shitting their pants when they hear words like “cloud”, “sharing”, “openness” and so on. They have their reasons but it doesn’t change the fact.

The right way to act in movement towards a better world with less digital garbage is to lead by example. Act as a role model. Refuse to send a file by e-mail if someone asks you to do so. Politely explain your reasons and offer an alternative – sharing. Secure sharing if necessary.

Become an ambassador of clean e-nvironment and establish a policy of handling data at your workplace. Start small but start smart. Spread the word and explain the reasons. Be patient.

Final word

Huge amount data is downloaded from the Internet every day for entertainment or other reasons. Be it movies as torrents (legal or illegal – doesn’t change the fact or amount of data) or MP3-s or e-books. Don’t be part of that madness! Avoid unnecessary copies. Use streaming and sharing instead.

Can you imagine that everyone who consumes electricity from their wall outlets is forced to store that energy somewhere at their home? I can! This is exactly what downloading reminds me. Lots and lots of energy downloaded and wasted instead of just letting it flow thru and just catch your part from the flow.

Imagine a wind turbine working in and because of the flow of air versus a very big bag that is kept against the wind until it’s full and taken somewhere indoors where the wrong turbine is located. There the bag is pushed empty against that turbine to make it work and again and again and again … Sounds stupid, right?

Part 2: Continuous Integration server to package Magento Extension with a click from JIRA

Starting Magento Connect extension packaging process from JIRA

When I wrote the first part of Continuous Integration server to package Magento Extension I didn’t know how to make it work with a click from JIRA. As you may know in JIRA there’s a way to release versions and trigger Bamboo builds during this release process. That’s what I was aiming – to make it work from JIRA so that it would NOT require any technical knowledge from let’s say Project Manager or Release Manager. I didn’t know it yesterday but here at MageFlow we have a learning mindset. I know it today:)

First – there are now 2 build plans configured in our Bamboo for our MageFlowConnect extension:

  1. “continuous builds” or “CI builds” that are triggered by commits that are made to the git repository that contains MFX code.
  2. “release builds” or “manual builds” that are triggered by clicking “Release” in JIRA

There are 2 main problems with creating Magento extension packages automatically:

  1. when and how to update extension’s version number (in module’s etc/config.xml and in package.xml mentioned in previous post)
  2. how to update release notes inside package.xml. However this one is not mandatory and it’s not resolved yet by us either.


Install xsltproc to your build server and configure an executable “XSLTProc” in Bamboo.

Updating version numbers

In Part 1 I’ve created a XSL stylesheet that does the job of replacing extension version number in package.xml. Exactly the same XSL can be used to replace version number in extension’s etc/config.xml, too.

In your “CI build” process you may want to have extension version number increased with every build automatically. So that’s what we do  – we set the extension version number to that already defined in package.xml with added Bamboo build number. For example if package.xml contains version number 1.1.3 and Bamboo build # is 43 then the final version number of that extension build would be

In order to replace version numbers in the “CI build” process add following 2 XSLTProc tasks to the build job in Bamboo:

  1. –output public/var/connect/package.xml –stringparam package_version ${bamboo.buildNumber} utils/update_version.xsl public/var/connect/package.xml
  2. –output public/app/code/community/Mageflow/Connect/etc/config.xml –stringparam package_version ${bamboo.buildNumber} utils/update_version.xsl public/app/code/community/Mageflow/Connect/etc/config.xml

First one appends ${bamboo.buildNumber} to existing version number (e.g 1.1.3) in package.xml while second does the same in etc/config.xml

In order to replace version numbers in the “Release build” (build triggered from JIRA) process add following 2 XSLTProc tasks to the build job in Bamboo:

  1. –output public/var/connect/package.xml –stringparam package_version ${bamboo.jira.version} utils/update_version.xsl public/var/connect/package.xml
  2. –output public/app/code/community/Mageflow/Connect/etc/config.xml –stringparam package_version ${bamboo.jira.version} utils/update_version.xsl public/app/code/community/Mageflow/Connect/etc/config.xml

First replaces version in package.xml with the version number specified in JIRA (let’s say 1.1.4) while second does the same in extension’s etc/config.xml

That’s it!:)

Please feel free to comment or send me questions directly.



Continuous Integration server to package Magento Extension

Here’s the situation.

MageFlow is developing Magento Extension called MageFlow Connector. It’s an integration extension that is used to connect a Magento Instance to MageFlow. We are using Agile development processes and state-of-the-art tools by Atlassian like JIRA, Confluence, BitBucket, Bamboo and others. Bamboo is used as build and deployment server that automates a lot of development operations incl building and packaging our software.

Packaging Magento extensions – standard method

Usually Magento extensions are packaged in Magento backend. There’s a form that needs to be filled in with information about specific extension like version number, release notes, files and folders that should be packaged etc. After that you need to upload your extension to Magento Connect and publish it.

It’s pretty good tool but it requires manual work in order to create a package. However in our case we just despise any manual work:) Everything should be automated to max. That’s also why we even started creating MageFlow. Anyway …

Packaging Magento extensions with Bamboo CI

Packaging an extension with Bamboo requires some manual labor too. That cannot be avoided in my opinion. However …

Here’s my wild guess … With a really tight integration between JIRA and Bamboo and some tricks/scripts full automation could be achieved on the way from clicking “Create release” in JIRA to a fully packaged extension as an artifact of a Bamboo build. But right now it’s bit too much work for too little to gain.

But – keeping my head cold and not aiming 100% automation yet I created a following way to package an extension with Bamboo CI.


GIT. For extension development we also use modman – a very useful tool for every Magento developer provided by Colin Mollenhour. It is also assumed that you have development environment ready in your local machine or elsewhere where you can prepare the package metainfo.

You also need to have a (preferred – vanilla) Magento (DevMagento) codebase in a GIT repository and you need to have YourExtension in a GIT repository. Make sure your DevMagento works fine and you can log in to the backend (admin).

Let’s name these GIT repositories like that for example:

DevMagento –


Prepare Magento extension and modman

First you need to add MyExtension to DevMagento by using modman. In terminal do:

cd /srv/vhosts/magento
modman init
modman clone

Second you need to create MyExtension XML metadata for Magento Connect package. This is done with the Magento Connect tool in Magento backend. Go to System->Magento Connect->Package extensions. Fill in all required fields there. Add version, release notes, files and folders, authors, dependencies etc. Click on “Save” button.

No back to Terminal:

cd /srv/vhosts/magento
ls public/var/connect

You see 2 very important files there now:

MyExtension.xml and package.xml

A mindnote here that package.xml will be overwritten if you package another extension in the backend of the same Magento while being in the same GIT branch.

Now create var/connect folder in your modmanned extension folder and move the files there:

cd /srv/vhosts/magento/.modman/my_extension
mkdir -p var/connect
mv ../../public/var/connect/MyExtension.xml ../../public/var/connect/package.xml var/connect/

Add these files to GIT and to your modman file.

Run modman update to re-create these files under Magento var/connect folder as symlinks:

cd /srv/vhosts/magento
modman update my_extension

Run a packaging test from command line to see if it works:

cd /srv/vhosts/magento/public
./mage package /srv/vhosts/magento/public/var/connect/package.xml
Done building package

It’s needless to say that you need to “git add”, “git commit” and “git push” your stuff etc. Now we’re almost ready to make Bamboo CI to create MyExtension-1.0.0.tgz. Also – see paragraph below about Magento bug after you finish next paragraph about configuring Bamboo.

Configure Bamboo CI

We are using standalone Bamboo CI in our own server. I’m not sure if everything looks the same in the ondemand solution…

Running unit tests on your Magento extension is not covered by this post. However I’m planning another post about this topic, too.

Install modman on your build server and add it as Bamboo executable if you haven’t done so yet.

In Bamboo create a new build plan called My Extension with plan key MYX. (Bamboo upper case plan keys and thus build paths with uppercase characters is where the Magento bug will strike in with its forced lowercase paths).

Add 2 repositories to your Build plan:

  1. DevMagento repository
  2. MyExtension repository

Make your build plan be triggered by periodically scanning the MyExtension repository for changes.

Configure build steps

Step 1: checkout source code from DevMagento repository. You may want to check out clean repo each time. It’s quite quick and you don’t build that extension too often. The reason is that otherwise next step will complain.

Step 2: run modman init. I.e choose modman executable and add “init” as command argument.

Step 3: run modman clone. Choose modman executable and add “clone” as command argument

Step 4: Add a script as build step with ${} as an argument to that command. The script is provided in this gist:

This script does 2 things:

  1. it runs mage script that creates Magento package
  2. it moves created tgz package from modmanned extension var/connect folder to Magento’s var/connect folder. The point is that Magento’s Package.php that creates the package uses realpath() PHP function. realpath() resolves symlinks created by modman and that’s why the .tgz package is created under .modman/my_extension/var/connect, not under public/var/connect.

After configuring build steps configure your build artifacts. Specify public/var/connect/ as artifact location and *.tgz as Copy pattern. You can make the artifacts shared so that a Bamboo Deployment plan can use the artifacts and deploy them to – let’s say – your test server;) But that’s another whole story …


Bug in Magento packaging scripts

NB! There’s a bug/misdesign in Magento packaging scripts. The solution is provided as a gist:

You may need to fix it in 2 places: under lib and under download. That’s why I recommended to use a vanilla Magento repository because you need to fix core library files. Create a special Magento repository, fix the bug there and use this Magento for packaging your extensions.


Alan Storm has created a good piece of software that enables creation of a Magento extension package from command line. However I found it too late and I’m not sure about 100% match with my problem.


It’s a pretty long post that covers quite complex issues. Feel free to leave a comment here or write me directly if you have any questions or thoughts about it.


Update: please see Part 2 of the same topic.

2 useful scripts for managing your GIT repository

First – GIT is not good at storing large and changing binary files (like images, mp3-s etc). It’s not meant for this. Don’t use it for this. Anyway, sometimes things happen and you have got some large images into your repository and the repo is growing and growing and growing…

I have published 2 scripts that help to manage your GIT repository. First one helps to find large files from your repository and the second one helps to remove these from the whole GIT repository history. If you thought that git rm would remove it or make your repository smaller then think twice:) It’s much more complex than that. If you have a distributed repository that has large binaries in it then you’re in bigger trouble. This case is not covered where although there are some methods to shrink those distributed repos, too. But it’s beyond this article’s scope.

Script for finding files:

Script for removing files:

PHP system, exec, passthru and return code 127

This is a mindnote for myself. If someone else finds it useful, too == profit.

Because of MageFlow development I need to use quite a lot shell commands, for example ping.

Whenever exec, passthru or system returns code 127 check the path of the command. It means that the command cannot be found. It also means that PHP runs the command in such a shell that does not necessarily have PATH set properly and thus the command is not found.


system('ping', $retval);

$retval is 127.

Specify full path to ping command:

system('/bin/ping', $retval);

$retval is 0 or 1 depending if is available or not.

Oneliner for retrieving Magento database password from local.xml

No comments:

Setting up Magento development environment, step by step. Part 3: Naming and structure

Naming and structure

Welcome back to Measure9 blog. Here I continue with article series “Setting up Magento development environment, step by step“. Please read Part 1 and Part 2, too.

I write about naming of things in this post. It’s important, it’s very important because in the long run it defines how you and you’re colleagues are going to talk about things, how you point at things and so on. It’s important to use common terms to build common understanding. Also I’ll explain the importance of SSH keys. I’ve learned to name things thru standards, conventions used in frameworks and long time industry-experience.

I’d like to start with this infamous and very good quote by Phil Karlton:

There are only two hard things in Computer Science: cache invalidation and naming things.

General rules about naming

  1. Never ever use special characters, other than ASCII letters in your file and folder names. Regardless of what Operating Systems claim there will be problems as soon as you move files around between different platforms and systems. I guarantee that. I’ll buy you a beer if you can prove that you’ll never had any problems with file/folder names with special characters 🙂 It’s especially important in non-English countries like Estonia (we have õ, ä, ö, ü), Germany, Sweden, Russia… Basically anywhere outside US and UK. (Side note – regardless of file names your application, your code, your files etc must be in / support UTF-8. That’s a standard.)
  2. Be very careful with case of names, especially when you’re working between case sensitive (all Linuxes), partly case sensitive (OSX) and case insensitive systems (Windows). Always prefer lower case where possible but as you know – Magento’s and Zend’s standards state some rules about class names etc. So just be careful and consistent.
  3. Avoid spaces in file and folder names.
  4. www-prefix is so-20th-century. My suggestion is to phase it out and let it go …

Development folders

Magento development folders/repositories/virtual hosts are kept under /srv/vhosts. Under that folder there are project folders. Usually one project has one, main domain name and it makes sense to name your development folder according to that. It’s easy to remember and it’s unique. Let’s say your customer is So your folder structure would look like this (explanation is below):


conf – virtual host configuration and other configuration files are in this folder

database – database change scripts, temporary dumps and other database-related stuff this is here

doc – here is project and code documentation (for example generated by ApiGen). Don’t hesitate to use external tools like Google Drive and a WIKI for documentation!

design – here are working PSD files of the theme, HTML templates etc, bought themes, generated/exported graphics, icons etc.

keys – keep SSL certificate keys and other keys in this folder. Here you can also keep project-related passwords in an encrypted file if you’re old-fashioned;)

public – this is the document root of your Magento. In other words this is the public folder that is served by your web server to end users. There are lots of other names that are used for this folder like html, pub, htdocs and so on. I decided to stick to public because it’s used in Zend Framework 2 and it says what it is. Always do remember that this folder is public, publicly accessible!

util – utility and helper scripts are kept in this folder.

Development hostnames (virtual hosts)

Most developers are working in local development machine and this tutorial assumes this way of working. In some cases people use hostnames like or example.local in their local development machine and these names are pointing to i.e localhost. There are reasons to do like this but this is not good when you need to test integrations like Oauth. Google’s API Console does not support .local domain names. That’s why I suggest usage of following naming structure: – point it to in your /etc/hosts file. – point it to your test server in DNS.

However usually the DNS is under customer’s control and making changes there is time consuming or impossible. To overcome that you need to use YOUR domain for development and your own / your ISP-s DNS. If that’s the case you could use common naming scheme for development and test: – point it to – point to to your test-server’s IP-address – staging is also called pre-live. It’s an exact copy of live environment but usually it’s using less hardware / virtual servers. It’s the server where content and changes are staged before deploying these to production system (which is or

If customer is having problems with DNS configuration then you can use your own DNS for the staging site also: – point it to the staging server’s IP-address

Usernames, passwords

My recommendation is to use e-mail addresses as usernames everywhere where possible. It’s not possible in most Linux shells but it’s possible in Magento’s frontend and backend. People, I mean – nerds and hackers, use all kinds of nicknames but it’s kind of … childish. Isn’t it? So use your e-mail as username in all your Magento solutions (BE and FE) and you and your colleagues know that and they don’t have to ask you every time. Easy to remember and easy to use!

About passwords. Try to avoid them as much as possible. They are just so insecure. Implement Oauth for Magento’s FE and BE login. Ask me if you need help with that.

If you need to create a password for a user for any reason then:

  1. make it complex (at least 12 characters, uppercase, lowercase, numbers and special symbols in it).
  2. make it expired so user must change it at next login and you don’t need to know it.
passwd -e username

This command would expire password for username  and she will be prompted for password change at her next login.

Another useful command is

passwd -d username

That command would remove password from the user’s account so that user can login with SSH key’s only (see below).

In Magento backend create a random password for your colleagues, forget it right there and ask your colleagues to use “Forgot password?” link to reset their password. You’ll test e-mail functionality of your Magento server this way, too 😉

SSH keys, logins, aliases

SSH keys are an excellent way to login without passwords. There is one very important thing to be remember about SSH key pairs:

SSH private key MUST NEVER leave the machine where it was created.

Translation to English: use SSH private key only on that machine where it was created. If you need another one, generate it and distribute another public key.

SSH key pairs can be generated with a simple command:


The default values are good in most cases. After you generate the key pair you will have 2 keys in your ~/.ssh folder:

  1. private key
  2. public key

The public key is “inherited” from the private key. Public key as the name says is public. After generating keys you need to distribute the public key to the servers where you want to log in. Usually the public key must be appended to the file ~/.ssh/authorized_keys. In Linux systems there is also command ssh-copy-id that is meant for distributing your public key. Use your password for the last time to distribute your public key and forget/delete your password:)

How to create headless virtualbox machine with Debian Wheezy

I’ve created a small helper script for those who want to be able to create VirtualBox virtual machine from command line via SSH and RDP.


As a prerequisite you need to download Debian’s network install CD image.

The script

Here’s the script and I’ll explain it below line by line:

How it works?

In short it works so that you run this script in your existing Linux and you give virtual machine name as the only parameter. It creates a new virtual machine with pretty safe values that all can be changed later (e.g amount of memory).

First we do initialization, check the scripts arguments and assign the first argument as VMNAME variable:

if test $# != 1; then
echo "Usage: $0 vm_name"
exit 0

Then we create and register new virtual machine of type 64bit Debian:

vboxmanage createvm --name $VMNAME --ostype Debian_64 --register

Then we allocate RAM, set power management, set DVD as first booting device, set network in bridged mode and we also specify that the machine would have 2 CPU-s with possibility to hotplug CPU-s:

vboxmanage modifyvm $VMNAME --memory 512 --acpi on --boot1 dvd --nic1 bridged --bridgeadapter1 eth0 --nictype1 virtio --cpus 2 --cpuhotplug on

After that hard drive image is created with size of 4 gigabytes. Make it larger if you have plenty of disk space handy.

vboxmanage createhd --filename ~/VirtualBox\ VMs/testvm/$VMNAME-disk01.vdi --size 4096 --variant Standard

Then we create 2 controllers, one for harddisks (SATA) and the other for CD/DVD (IDE):

vboxmanage storagectl $VMNAME --name "SATA controller" --add sata
vboxmanage storagectl $VMNAME --name "IDE controller" --add ide

Then we attach the newly created hard disk to the controller:

vboxmanage storageattach $VMNAME --storagectl "SATA controller" --port 0 --device 0 --type hdd --medium ~/VirtualBox\ VMs/$VMNAME/$VMNAME-disk01.vdi

As a last thing we attach the downloaded Debian 7 network installation CD image:

vboxmanage storageattach $VMNAME --storagectl "IDE controller" --port 1 --device 0 --type dvddrive --medium /mnt/raid/soft/debian-7.2.0-amd64-netinst.iso

… and we start the virtual machine:

vboxheadless -s $VMNAME &

You’ll be displayed a message similar to this one:

VRDE server is listening on port 3389.

Open a Remote Desktop Client and connect to your host machine’s IP and port 3389. You will see Debian’s installation screen. Install it and off you go!:)

Later you may want to set the default boot device to harddisk instead of DVD:

vboxmanage modifyvm $VMNAME --boot1 disk