Unexpected Errors On Customer Systems

The past few months we’ve been heads down in a major new release for our MailChimp and SugarCRM integration. We’re beta testing now, and will be releasing it to everyone soon (contact us if you’re interested in being a beta tester!).

After writing and refactoring lots of new code, at some point you have to say you’re finished and get it into some customers’ hands and on some live systems. This can be a scary process no matter how many unit tests you have passing or how much testing you do on your own servers. Here are some of the possibilities of customers’ Sugar setups:

• Operating systems: Unix, Linux, Windows, OSX
• Web Server: Apache, IIS
• Database: MySQL, MSSQL
• PHP Version: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 6, 7
• Do they have all the libraries installed your add-on requires? (such as curl)
• Which Sugar Version? Sugar 6, 6.5, 6.7, 7.*, SuiteCRM 7.*
• Which Sugar Edition? Community, Professional, Enterprise, Ultimate
• Is it an On-demand instance? Or self-hosted?

It is impossible to test all possible server stack variations that Sugar instances can run on. So as it goes with most software, something unexpected will always come up.

As we pushed through customer testing, here are a few of the issues we encountered in the wild, not found in our development systems.

Case-sensitive File Systems

If you develop on Mac OSX or Windows, this one can be really easy to overlook and throw you for a loop when you’re emailing back-and-forth with a customer who is running into this issue. Mac OSX and Windows operating systems have case-insensitive file systems. Casing does not matter. For example, say you have a module file that is named the following: modules/mymodule/mymodule.php (notice the lower-case letter ‘m’)

On Mac OSX or Windows, the following code would work without error:

However if you installed this code on a Sugar instance running on a unix/linux machine, as soon as this file runs you’ll run into the Sugar white-screen of death and a big 500 error.

There isn’t an easy way to identify this issue in your add-on code without testing everything. Even if you look at all of your code, this is something that can deceive your eyes easily. One way to avoid this would be to use underscores instead of camel-casing where you can.

System Constants Aren’t So Constant

We had a very specific use-case where we parse some file paths and handle file auto-loading. When doing something like this, we needed to parse and build our own file paths. To do this, we relied on the DIRECTORY_SEPARATOR php constant. For most systems this will be the forward slash “/” but it never hurts using a constant if you have one.

Something I didn’t expect to find was the DIRECTORY_SEPARATOR value in Windows was a backward slash “\”. But that shouldn’t matter, right? That’s the entire point of using the system constant.

It matters when you are not consistent using the constant. If you use the DIRECTORY_SEPARATOR constant in an important method, but then hardcode forward slashes throughout other parts of your code, you’re asking for trouble. If you are going to use a system constant, all data that is being passed into methods using the system constants need to also use the constant.

Supporting MySQL and MSSQL

In a perfect world, you shouldn’t have to worry about differences between MySQL and MSSQL because they should all be abstracted in the database layer and you should use the Sugar Bean all the time. When you’re supporting all versions and editions of Sugar 6, Sugar 7 and SuiteCRM, there are cases when writing queries is the most portable way to go.

When you’re writing your own queries for Sugar add-ons, you must make sure your queries work on MySQL and MSSQL. You can check which database type is being used in a Sugar instance by using the follow:

One of the most common mistakes I make is using && and || for my conditional statements in my queries. That works just fine in MySQL, but if you try to run a query with && and || in MSSQL, it will fail fast. You must use the written out words AND and OR.

The other common mistake is trying to use functions that exist in MySQL, but do not exist in MSSQL. For example, IFNULL() in MySQL allows you to provide an alternate value if a value is NULL, however IFNULL() doesn’t exist in MSSQL. You have to use ISNULL() in MSSQL.

If you look through Sugar’s database layer code, there are helpful methods for the function conversions (a good place to start is the include/database folder). Most of the time Sugar’s database layer will have what you need. The $db->convert() method has a lot of useful conversions methods.

I hope these tips come in handy. If there are any other common issues you run into when developing for the many possibilities of server stacks Sugar can run on, let us know in the comments.