Lone Wolves

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.

Officeshots.org has finally gone into Beta this week. It took a lot more work (and time) than expected but we made it nonetheless. At the moment the beta is a closed beta, available to current contributers and members of the OpenDoc society. But we hope to start with public, free availability within a month. Joining the OpenDoc society is free for FOSS projects, so if you are interested in the beta, please join them.

Read more for the full press release.

In the weekend of 7 and 8 February, the 9th Free & Open Source Developers' Europe Meeting (FOSDEM) took place at the Université Libre Bruxelles (ULB) in Brussels. Your editors Sander Marechal and Hans Kwint attended this meeting to find out for you what's hot, new in the area of the Linux environment and might be coming to you in the near future. This is our report of the second day covering the talks about Thunderbird 3, Debian release management, Ext4, Syslinux, CalDAV and more. Coverage of the first day can be found in our previous article.

This article was originally posted on LXer Linux News.

A week ago, the 9th Free & Open Source Developers' Europe Meeting (FOSDEM) took place at the Université Libre Bruxelles (ULB) in Brussels. Your editors Sander Marechal and Hans Kwint attended this meeting to find out for you what's hot, new in the area of the Linux environment and might be coming to you in the near future.

Here is the blow-by-blow of the first day with talks about Mozilla's future, the role of Debian, two OSI talks, Reverse engineering and much, much more.

This article was originally posted on LXer Linux News.

Yesterday the OpenDoc Society, the NoiV (Netherlands in Open Connection) and the NLNet Foundation announced Officeshots.org, a new webservice where you can upload ODF documents and compare their rendering and output in different office suite applications. We here at Lone Wolves are happy to announce that we are the lead architects of this new webservice.

Over the coming days I will announce a couple of things regarding Officeshots.org on this website, like how it works, where to get the code and how to contribute. The plan is to start a closed beta by the end of February and go public by the end of March, but if we want to make this deadline then we need contributers. In the upcoming days I will explain exactly what we need, but if you want to help then you can already join the officeshots.org mailinglist.

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.

I have recently been writing some documentation in DocBook XML format that I wanted to convert to PDF. Debian has a really useful package called xmlto that you can use for this, but it did not work for me. The xmlto tool converts DocBook to PDF through LaTeX and I was getting all kinds of errors. Instead I opted to use the DocBook-XSL stylesheets to convert DocBook to fo and use Apache fop to convert it to PDF.

DocBook-XSL and Apache fop work wonderfully well but there were a couple of bumps that I had to sort out before everything worked as it should, especially regarding the Java setup and getting images to work correctly. Here is how I set up my DocBook toolchain on Debian Lenny.

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.