Zurmo CRM administrators and developers often need access to Zurmo’s built-in console commands in order to perform common maintenance and upgrade tasks. This can often be problematic in a shared hosting environment where shell access is often restricted and/or the applications are auto-installed using tools like Softaculous.
In this article, you will learn how to tweak your Zurmo instance that was auto-installed using Softaculous via cpanel in order to run the zurmoc command line utility and execute maintenance scripts against your Zurmo application instance and database.
If you intend to try these techniques, Arvixe personal hosting customers need to obtain ssh shell access to their account by calling or emailing tech support, as shell access is not enabled by default on shared hosting plans. Simply contact tech support and let them know you need terminal ssh access to your account. You can find instructions on how to install and configure a vt100 terminal emulator PuTTy in a previous post. Nothing could be easier.
zurmoc is a shell script located in the zurmo/app/protected/commands directory. Its purpose is simply to bootstrap the terminal command line environment so you can use the terminal to execute php scripts that are custom built for Zurmo maintenance.
When would you need to use these maintenance scripts? One example – let’s say you, or your developer, made a customization change to a model in a Zurmo module. You can think of a model as a blueprint or schematic, it represents the plan for a software object, which can be stored, or persisted, in a database. Hence, any changes to Zurmo model files must always be synchronized with the database.
Manually updating the Database is out of the question, there are simply too many interrelated database changes which proceed from your code change. This is partly due to the fact that Zurmo is built on top of RedBeanPHP ORM which hides much of the database plumbing from the programmer. The tradeoff in this arrangement is that the database tables are often highly abstracted from the programming object(s) which they persist.
Zurmo provides an UpdateSchemaCommand.php script to resolve this predicament.
After any object metadata changes are made in the model code you essentially have two choices:
- Re-install the application, which will wipe out the database and all of your data, and then automatically rebuild the database according to the model metadata (code blueprint).
- Run the UpdateSchemaCommand.php script using zurmoc from the command line in a terminal window, preserving the existing data in the database.
Here is the syntax for the second option:
#change to the Zurmo commands directory cd zurmo/app/protected/commands #update the database from code changes ./zurmoc UpdateSchema super
Note the dot before the forward slash in the last command. It tells the shell to look for the command in the current directory.
The astute reader will also notice that the token ‘super’ has been appended to the command. This parameter indicates the Zurmo username.
As of this writing, the Arvixe Softaculous installer does not, by default, grant execute permissions to the zurmoc bootstrap script. So, in order to avoid any “permission denied.” errors you will need to make a quick permissions change.
#change to Zurmo command directory cd zurmo/app/protected/commands #grant owner execute permission on zurmoc chmod 744 zurmoc
Now when you run the UpdateSchema command from a terminal window you should see the autobuild process kick off. A sequence of info messages will rapidly scroll through the terminal screen and ultimately complete with a success message and some benchmark timing.
At the time of this writing, the screenshot above reflects benchmark times for an autobuild of Zurmo version 2.2.5 against a nearly empty MySQL database. You will, no doubt, be pleased to learn that – as of the upcoming Zurmo version 2.5 – the autobuild process was completely refactored. My advance testing shows a drastic performance increase and clocks-in at around 6 seconds compared to 115 seconds that you see here.
(c) 2013 Windsor Wallaby. All rights reserved.