SugarCRM – Git Version Control Strategy

git-logo
I’ve found SugarCRM an utter pain to work with in terms of version control for a number of reasons, but the most annoying is simply that certain critical elements of the SugarCRM configuration are stored on the database.

Over time I’ve worked out a system that circumvents this and I’ve managed to create a very useful gitflow based workflow.

I won’t go over what gitflow is or does, there’s a great explanation here and if you need a more visual explanation this cheatsheet is a terrific reference.

Example Problem

Say you’re in the middle of developing a new feature in SugarCRM. You’ve used something like.

Someone realises a new urgent fix is required to go live now, you’re not going to want to deploy your half implemented feature along with the new urgent fix. That’s okay, you’re using git flow. So you’d commit your half finished feature. Then create a hotfix, like

The problem is that you’ve made a bunch of changes to the sugarcrm database, specifically fields_meta_data. Even if you swap branches the fields_meta_data won’t update back to the master branch, which is where the new hotfix will create it’s branch from. What you need is a way to keep fields_meta_data in sync with the branch you’re currently working on.

The Solution – Git Hooks

Using git hooks you can automatically run commands when certain events occur. The two hooks of interest to us are pre-commit and post-checkout.

Tracking all database changes
What pre-commit does is run everytime you commit code. So, if you could dump your fields_meta_data everytime a commit is made, you can be sure your branch is tracking all database changes you’re making via the studio. So in .git/hooks/pre-commit add code that looks like so:

Note that I’m not compressing these database dumps, they should stay in plaintext with each line representing a database insert. The reason for that is when it comes time to merge two branches, say you’ve made changes to studio in a master branch and also to a feature branch you wish to release, you can merge the fields_meta_data in with branched changes very easily via any mergetool.

Keep Sugar up to date with your branch
Finally when you swap between branches you’ll want to automatically apply that branches fields_meta_data because your likely to forget to do this step. So say your swapping from a feature branch to master. You’ll want to revert your studio changes back to where master was. You can do this in the post checkout git hook. So in .git/hooks/post-checkout add something like this:

This will automatically execute your fields_meta_data database dump on your SugarCRM install.

Deploying
In the end, whether a hotfix or a feature it’ll always get merged to master when I’m deploying. So what I tend to do is finish my release/hotfix, merge to master then apply a data sync to fields_meta_data on live so I can manually review the db changes before deploying. Navicat has a really nice tool to handle this.

Going further
As you can see all I’ve written is two simple bash scripts and they’ve made my Sugar workflow much cleaner. You could go far further than this, a few examples I can think of would be to track db changes on the saved_reports table or have the scripts automatically run a command line variant of the Quick Repair/Rebuild. The other thing could be to track the entire structure of the SugarCRM database if you felt like it, but since all db fields are tracked via fields_meta_data I thought this wasn’t necessary but I’m sure there’s ton of other things you could add to make your development life easier.

Let me know if you think of anything!

Better PHP Debugging with Emacs

Emacs-icon.sh

Recently I came across an app called CodeBug, a really nice PHP debugger for Mac. I find debugging PHP really painful within editors such as Vim or Emacs, so up until now I’d been stuck using the incredibly bloated PHPStorm.

On Emacs you can currently use Geben for debugging but I find it’s install really painful and it’s usage even more so. I figured it was worth knocking up an Emacs plugin that allows you to set breakpoints in Codebug.

You can find the repo here and it’s been accepted to Mepla, so it can be installed via the package manager. MELPA

Update: Codebug have very nicely featured this plugin on their homepage. Awesome!

 

Shellshock – Am I vulnerable and what do I do?

bash_history

Shellshock is the latest Heartbleed level vulnerability to be discovered. It’s a pretty long running exploit in how bash handles environment variables. It’s a good thing to fix asap, especially if you’re running any old services like telnet, ftp or an old version of apache.

Is my server vulnerable?

Run this.

If you see:

You should patch immediately.

However if you see.

You should be okay.

How to fix?

Centos/RedHat

Debian/Ubuntu

OSX

Unless your running OSX as a critical server somewhere remote, I’d hold off the solution for now and wait for Apple to distribute an update. If you need to update.

  1. Install homebrew
  2. Run
  3. Then run
  4. Backup your existing vulnerable bash
  5. Then symlink to the new brew installed bash

Finally reboot!

Note: These patches are coming out fast and… incomplete. So keep an eye on these solutions as time goes on as I fear these patches might not solve the whole problem.

SugarCRM 7 – Fix to re-enable ElasticSearch on custom modules

elasticsearch_logo-600x123

I had an issue in Sugar where some custom modules refused to appear in the Global Search settings, meaning I couldn’t index them in ElasticSearch.

When I checked the module oddly enough unified search would be enabled in this file:

1. Re-enable the module

To force it to be re-enabled update/create this file

and add this setting.

2. Re-enable a field

You’ll also need a field using the unified index before SugarCRM will pick up the unified_search setting. So under:

Enable unfied_search as a setting.

After a quick repair/rebuild. My module appears in the Global Search Settings and I can poll it as normal through ElasticSearch.

SugarCRM 7 – Enable Importing on Custom Modules

importdata

 

I’ve been wracking my brain trying to get this guide to work with SugarCRM 7. Add to the fact that it “looks” like this is also how it’s done in SugarCRM 7, if you peruse the code under Accounts or Contacts. However it isn’t. This is how I’ve added importing support to custom modules.

Set Module as Importable

Under modules/<ModuleName>/<ModuleName>_sugar.php set

Add Menu Item

Under modules/<ModuleName>/clients/base/menus/header/header.php you should have something like

If not create the file with that array. Next add the import action to the array.

Add language setting

Under /modules/<ModuleName>/language/en_us.lang.php add into the $mod_strings array(if it’s not already there):

Finally

The inevitable quick repair/rebuild.