I have just released a major update to the Jejik/mt940 library. The new 0.3 version allows you to easily extend and override the built-in classes with your own implementations. This makes it possible to easily integrate the MT940 library into your application using a database abstraction such as Active Record or ORM like Doctrine 2. As usual, you van install it through Composer.
Using the new functionality is quite straight-forward. The Jejik\MT940\Reader class now also acts as a factory for creating the various objects that make up a parsed MT940 document.
I am working on a new project and I needed to parse some MT940 files. MT940 is a pretty common exchange format for bank statements. Most banks will allow you to export your bank statements in this format. I had a look around but I wasn't quite happy with the existing parsers so I decided to implement one myself. This also gave me an opportunity to try out travis-ci and composer/packagist, both of which I haven't used before.
So, Here is jejik/mt940 on github. You can install it using composer and check the build status on travis-ci. At the moment four banks are supported: ABN-AMRO, ING, Rabobank and Triodos bank. I'd be happy to add support for your bank as well. Just send me a Pull Request on github with your parsers.
Jejik/MT940 is licensed under the MIT license. Have fun with it!
A couple of days ago Nikita Popov gave a nice overview about the discussion about type hints for scalar types in PHP called Scalar type hinting is harder than you think. He came up with his own alternative called Strict Weak Type Hinting. It does weak type hinting with strict validation. From the options in his article it seems by far the most sensible, but I think it can do with one improvement. I would prefer that the Strict Weak Type Hint also cast the parameter after it passes validation.
I have been playing with Phing quite a lot lately. Phing is a build system that looks and acts a lot like Apache Ant, except that it is written in PHP. That's a great thing for PHP developers like me, because it makes it much easier to extend the system with custom extensions.
I am going to write several useful extensions, the first of which is a YuiCompressorFilter. Phing already has support for a JavaScrip minifier in the form of the JsMinTask, but the yui-compressor is more useful. Not only does it usually compress better than JsMin, it can also compress CSS files. Also, because my YuiCompressor extension is implemented as a filter instead of a task you can do fancy things like minifying and concatenating files in a single step.
A short while ago Ty W posted an interesting question on StackOverflow. Apparently, most graphics software cannot scale images the right way. Usually it's hard to notice the flaw but the linked article does a great job of explaining the problem.
PHP's GD library suffers from the same issue, but Ty discovered that the sample PHP program provided with the article did not work on partially transparent images. After a couple of hours of fiddling I managed to get a working solution.
Apparently, the imagegammacorrect() function in PHP deals badly with images that have an alpha channel. I suspect that it tries to apply the same calculation to the alpha channel that it applies to the red, green and blue channels. To work around this, my solution splits the aplha channel from the original image. The alpha channel is resampled regularly while the red, green and blue channels are resampled using gamma correction.
One of the requirements for the upcoming public release of Officeshots.org is that all uploaded files are run through a virus scanner before they are made available. Picking a virus scanner for this job was easy. ClamAV is open source, well supported, actively maintained and comes pre-packaged for Debian Lenny which we use for the Officeshots servers. Finding a PHP library to interact with ClamAV proved harder though. The 3rd party library page for ClamAV points to two different libraries that provide PHP bindings for ClamAV but both appear to be dead and expunged from the internet. So, I created my own using the clamd TCP API, and because Officeshots is built using CakePHP I implemented it as a Cake plugin.
You can download the clamd-0.1.tar.gz plugin or check out the source from my Subversion repository with the following command:
~$ svn checkout https://svn.jejik.com/cakephp/plugins/clamd/trunk clamd
Or you can browse the repository online. In the rest of this article I will show you how you can use this plugin.
When working on the beta of Officeshots.org I ran into an interesting problem with file type and MIME type detection of OpenDocument files. When a user uploads an ODF file to Officeshots I want to determine the MIME type myself using the PHP Fileinfo extension. Windows user who do not have any ODF supporting applications installed will report ODF files as application/zip which is of no use to me. In addition, a malicious user could attempt to upload an executable file and report the MIME type as ODF file.
On Linux, the PHP Fileinfo extension relies on the magic file that is provided by the file package. The magic file contains a series of tests that can determine the file type and MIME type of a file by its contents. I found out that the magic file is incomplete for OpenDocument files. Below I will show you what is wrong with the magic file and how you can fix it.
Update 2009-06-29: I have now also created a patch against the original upstream file-5.0.3.
CakePHP has rapidly been gaining mindshare as a powerful and easy to use MVC framework for PHP. Mimicking Ruby on Rails, it allows developers to quickly prototype and build database driven websites and web applications. With increased popularity books usually follow. “Practical CakePHP Projects” by Kai Chan and John Omokore is one such book. It is aimed at advanced PHP developers who have some experience with CakePHP and builds on books like “Beginning CakePHP” (Apress, 2008). The book promised to show how to build practical, real-world web applications using the CakePHP frameworks.
Unfortunately “Practical CakePHP Projects” only partially succeeds in that. It is refreshing to see how applications are built that are different from the proverbial “blog” or “store” example (though both are used in the first chapters), but I find myself disagreeing often with how these applications are built. The chosen solutions often seem to work against the framework instead of going with it.
This article was originally posted at LXer Linux News.
The standard edit views for your custom modules are workable, but with a few additions and modifications you can make them a lot more powerful. In my last article “Add grandparent fields to your SugarCRM modules” I showed you how you can relate your modules to grandparent modules and even great-grandparent modules by following the chain of one-to-many relations upwards. This works very well to enhance your list views and detail views.
In this article we are going to use those grandparent fields on the edit view and use them to add filters to the other relate fields on your custom module. I will be building upon the invoicing module I created in the last article. It contains an Invoices module which relates to Accounts, and an InvoiceLines module which relates to Invoices. Suppose you want to edit an invoice line and move that line to another invoice. I will show you how to add functionality to the edit view so that, when you click the “Search” button on the Invoice field, the popup will only show you the invoices for the same account. This makes it much easier to find the right invoice, or any other related module.
When you build custom modules in SugarCRM and you create one-to-many relations between them, you can put a link to the parent module the various views. But what if that parent module has a one-to-many relation to yet another module? By default SugarCRM does not support adding links to grandparent modules on your views. For example, suppose you have a custom Invoices module which relates to Accounts and you have an InvoiceLines module that relates to Invoices. When you look at an invoice it will contain a link to the account. When you look at an invoice line then you will see a link to the invoice. But you cannot add a link directly from the invoice line to the account.
In this article I will show you how you can add links and fields from grandparent modules to your own custom modules. I will build on the invoicing package I created in my article “SugarCRM many-to-one relations to standard modules”. That packages has an Invoices module that relates to Accounts, and an InvoiceLines module that relates to Invoices. I will add fields to the InvoiceLines module that directly links to the account.
The module builder in SugarCRM allows you to create one-to-many relations between one of your custom built modules and a standard module. However, it does not allow you to create many-to-one relationships. This means that it is not possible to create an Invoices module for example, where one account relates to many invoices, but each invoice only relates to one account. While you can create such a relationship by using the “Relate” field, you will not get a subpanel on the Accounts module that shows all the invoices that relate to in.
In this article I will show you how you can create a many-to-one relation between your custom module and a standard module. This relationship works the same way as the one-to-many relationship with full support for searching and subpanels, only the other way around. My setup is based on my previous two SugarCRM articles: “Keeping SugarCRM under Subversion control” and “Build custom SugarCRM modules in Subversion”. That means that I will be working inside the installable zip package that is generated by the SugarCRM module builder.
You can download the full invoicing package that I created in this article. It has been tested on SugarCRM 5.1.0b.
In “Keeping SugarCRM under Subversion control” I showed you how I maintain the base SugarCRM in the face of changes to the core code. The setup described in that article allows me to make changes to the core code without running into (too much) trouble when SugarCRM ships a new version. It does have one downside: You cannot use Studio to make any changes. Instead, I keep all my customization work in a separate installable package, together with any custom modules I develop.
In this article I will show you how I develop my custom modules, how I keep them in Subversion and how they work together with the base SugarCRM from the previous article.
I have been mulling a long time how I am going to keep track of SugarCRM, the custom modules I build and and changes to the core code that I need to make. The latter is sometimes unavoidable because some functionality cannot be built any other way. Also, sometimes you run into a bug that you need to fix, but you cannot wait for the next Sugar release. Of course, all of this needs to be done in a way that is easy for developers to work with. I think I have finally found a way that is workable and keeps everything under version control.
I will present my workflow in two articles. This article shows you how I keep SugarCRM itself under version control, how I deal with deployment and how I do upgrades in the face of changes to the core code. In “Build custom SugarCRM modules in Subversion” I will present how my custom modules—which are also under version control—fit into this system. Hat-tip to Leonid Mamchenkov for his work and insights.
Thanks to the taglist vim plugin, vim users have access to a decent tag browser. A tag browser allows you to view a list of all variables, functions and classes and quickly jump to their definitions. Taglist is built on exuberant ctags so it support a large amount of languages. Unfortunately however, when the exuberant ctags people replaced their old PHP lexer with a brand new regexp-based parser the quality of parsing PHP code decreased dramatically. Ctags suddenly could not distinguish real class and function declarations from mere mentions of the words “class” and “function” in multi-line comments. This is because the ctags regular expression parses is inherently line oriented.
In this article I have two patches that greatly improve PHP support in exuberant-ctags. I will also show you how you can apply these patches on a Debian-based system.
Update 2009-07-07: David Mudrak has written an updated patch for Gentoo. I have ported his improvements back to my patch here. It fixed a problem with old-style functions without a visibility declaration and it applied the same trick to interfaces as well.
Updated 2008-12-12. With the release of SugarCRM 5.0 came the new Module Builder that allows administrators to easily create new custom modules. But it was quite buggy and there was no way to create one-to-many relationships between custom modules. Then came SugarCRM 5.1 that promised to resolve the issues. Besides the Relationship Editor in the Module Builder there are also the “Relate” and “Flex Relate” fields. Two different (and incompatible ways) to create relationships. Not to mention that the Relationship Editor in the Module Builder works differently from the same editor in Studio. The former creates relationships in code, the latter in the database. And there are still heaps of bugs*.
The biggest problem I have had is with one-to-many relationships, the most common relationship type when you’re creating modules. If you use “Relate” fields then no real relationship is created and you won’t get a subpanel in the parent module. If you use relationships created in the Module Builder then the related fields show up badly in the Edit and Detail views, and you cannot use them at all in the List view, subpanel or search panels.
After much agony, hair-pulling and cursing I have finally found a way how to resolve the latter issue: Here is how you can repair your layouts when using one-to-many relationships.
Updated 2009-01-07. One of the projects I am working on at the moment at my day job is customizing SugarCRM. We want to start managing all changes to SugarCRM using subversion, so we need to know which bits should be under version control and which bits should not. During my analysis I came across the ill‐named and infamous cache directory.
SugarCRM’s cache is anything but that. I already knew that uploaded files and e-mails were also stored in the cache directory, but I needed to know exactly what was in the cache so I can make some informed decision on what to put under version control and what bits of a production system should be backed up. I found my answer, after a whole lot of searching, reading the SugarCRM source code and asking around. It turns out that the cache directory contains a hodgepodge of user data files, configuration files and—oh yes, there are some real cache files in there as well.
If there is one thing to take away from this article it’s “Don’t mess with the cache unless you know what you’re doing”. That bears repeating:
“Don’t mess with the cache unless you know what you’re doing”
With that firmly burned into the back of your eyeballs, here’s an overview what the cache directory contains.
Updated 2008-28-10. Proper version control is a must for everyone who programs more than a few lines of code. Even if you develop your applications all by yourself it is very handy to be able to branch and merge your code, be able to roll back to previous versions or undo changes you made in the past. It works great for regular applications, but managing web applications or websites is a tad harder for two reason: You need a webserver to get your application going and you usually have to manage database revisions as well.
Keeping database revisions in sync with your code revisions is a complex subject that I will leave until another time. In this article I will show you how you can configure your own computer or development server in such a way that checking out or deploying a web application is just as easy as any other piece of code.
First I will show you how to configure Apache on your development server so that it picks up your checked out working copies as separate subdomains. Using this, you can simply make a checkout of your project and it will automagically be up and running. No need to touch the Apache configuration. After that I will show you how to use dnsmasq so you can achieve the same effect on your own development machine. That way you can develop your web applications locally and you won't need a central development server. In my examples I will be assuming you use subversion for your version control, but it works virtually the same with other version control packages, such as git or bazaar.
For the past few days I have been looking for a proper i18n (internationalisation) and l10n (localisation) method for PHP. PHP has quite a few locale aware functions such as strftime and sprintf. In combination with gettext this can work quite well. The major downside is that you need to install all the locales that you want to support on your server. Want to serve your websites in Russian? Then you need to generate a Russian locale system-wide. That won’t work when you’re on a shared hosting account somewhere.
PHP6 is promising to solve that problem with the intl functions. Even better, the intl functions are also available as a PECL extension and works on PHP 5.2.4 and newer. Debian Etch currently packages PHP 5.2.0 which is too old, but Lenny—Debian’s upcoming version—is up to PHP 5.2.6. There is no package (yet) for php5-intl in Debian Lenny but building and installing the extension yourself is really easy. Here’s a short tutorial.
Lone Wolves is happy to announce the ODF-XSLT project. The ODF-XSLT Document Generator is a library written in PHP 5 that brings the full power of XSLT to your OpenDocument files. It enables you to use ODF files as if they were plain XSLT templates. It also includes a few extra parsing options that allow you to edit the XSLT parts of these ODF from within your favourite office suite. ODF-XSLT is developed by Tribal Internet Marketing and is released by Stichting Lone Wolves as Free Software under the GNU General Public License, version 3.
The first release of ODF-XSLT is odf-xslt-0.4 and can be downloaded from our download section, together with a nightly snapshot of the subversion trunk. You can also check out the latest version directly from our subversion repository. The manual and API documentation are available from the project website.
The longer I program, the more structured my programming methods have become. Gone are the days of editing live spaghetti code directly on the server or frantic FTPing files after each tiny change. Today I not only stuff everything in Subversion just to keep track of changes, I also use it as a deployment mechanism. But I want more and I want it automated too! Currently I am busy playing with generated documentation and unit testing. Generated documentation is an all round great idea, but it has a drawback: You need to generate it all the time. So I set out to use Subversion’s post-commit hook to generate fresh documentation for my PHP projects using phpDocumentor.
I have written a little Python script that you can call from Subversion’s post commit hook. This script scans your subversion project for files that have the phpdoc property set. If any of these have changed, then it regenerates your documentation using phpDocumentor. It can also deal with files that are not kept in your Subversion repository and supports anything also supported by phpDocumentor.