Frustrated by Magento? Then you’ll love
I’ve been doing a bit of cleanup and archiving, and realized I’d never written a proper article for the Magento Tar to Connect project.
Consider that oversight sighted.
What is Magento Connect
Magento Connect, for those not familiar, is Magento’s extension directory. Users browse extension listings and either
- Grab keys they can use to install extensions into their Magento systems
- Follow links to commercial extension homepages where they can buy extensions
Within Magento itself, the Connect installer accepts keys from Magento Connect, and uses those keys to identify, download, and install an extension.
For developers, Magento Connect is a way to package extensions for easy installation. In addition to uploading the package to Connect, extensions may be installed manually via an upload form in the store owner’s Magento Connect UI.
The file format is a tar archive with a package manifest, and heavily influenced by PHP’s PEAR format (older versions of Magento actually used PEAR). On the surface, it’s straight forward. Unfortunately, the realities of business software development means the Magento Connect developer experience is less than ideal.
Magento Connect Gripes
Packaging a Magento Connect extension, while not rocket science, is a bit of a hassle. There’s a UI in the Magento Admin for this, but like much of Magento the simple C.R.U.D. interface is thwarted by a non-simple task. What do these fields mean? What’s required, and what’s not required? What’s this opaque error message mean? Why does it let me package an extension that’s rejected by the Magento Connect website?
All that, of course, is surmountable. Since Magento Connect is just a tar archive with a package manifest, it should be easy to script. Right?
Unfortunately, software reality strikes again. Magento’s packaging code (used by developers) and un-packaging code (used by store owners), is completely implemented in PHP. This includes code to tar and untar the Magento connect archives.
Rather than rely on the presence of command-line tar on the system, Magento’s core team developed their own version of tar/untar. The win for them was full control over the Magento Connect experience, and never needing to tell a big client a tar-less system couldn’t run Magento. This is a common pattern in self-hosted PHP applications/systems.
The downside, unfortunately, is compatibility. The tar/untar in the Magento Connect PHP files is (mostly) internally consistant within a version of Magento. An archive created by the code can be unarchived by the code. However, over the years this code has proven inconsistent with all versions of the tar command line tool in the wild. This meant many extensions developers who scripted their own Magento Connect packagers using the command line version of tar ran into some weird, hard to reproduce bugs. The most common of these was Magento Connect creating folders with names like PHP files
app/code/community/Package/Namespace/Model/Modelname.php
These were the worst sort of bugs — system specific, hard to track down and hard to reproduce. (To their credit, Magento’s support and bug-meisters have worked hard over the years to track some of these down and eliminate them)
Magento Tar to Connect
All this led me to create the Magento Tar to Connect shell script. This project allows you to create a tar archive manually using standard *nix tools, and then pass this archive off to the script. Then, the script will untar your archive, create the Magento Connect package manifest, and then retar the extension files using the internal Magento archiving code.
Usage is simple —
$ php magento-tar-to-connect.php path-to-config.php
The path-to-config.php is a simple PHP include that contains the configuration information for your build. This includes the path to the current archive, export path, and the bare minimum meta-data needed to get a package into Magento Connect. The GitHub project has a sample configuration file with an explanation of each field.
Like most of my shell scripts, this was born out of a need, quickly programmed, and then left in place. I wouldn’t point to it as an example of elegant code — it’s just useful code that solves a problem. Improvments and suggestions are more than welcome.