Pat Shaughnessy

Ribadesella, Spain

Problems Installing the Cutline Theme in Mephisto

September 27, 2008 · 1 comment

My next step was to switch away from the standard “simpla” theme to another more interesting one. Once again I expected this to be a very easy task but ended up spending hours debugging and troubleshooting Mephisto and my blog setup on HostingRails.com. I started by downloading the theme onto my server:
cd themes/site-1/
mkdir cutline
curl http://mephisto-themes.nanorails.com/download?theme
	=cutline.mephisto-themes.nanorails.com > cutline/cutline.zip
cd cutline
unzip cutline.zip
Now when I logged into the Mephisto console and viewed Design->Manage Themes I saw the new theme. The first problem occurred when I clicked on the new theme and selected “Use Theme." I expected to see the new theme or a message in the admin console, but instead got a page full of text:
$("dialog-box").update("\u003Cdiv id=\"theme-info\" class=\"clearfix\"\u003E\n  \u003Ch3\u003E\n    Cutline (rhtml) (v1.1)by \u003Ca
href=\"http://cutline.tubetorial.com/\"\u003EPearsonified\u003C/a\u003E\n    \u003Ca href=\"#\" id=\"close-dialog\" onclick=\"Dialog.close();
return false;\"\u003Eclose\u003C/a\u003E\n  \u003C/h3\u003E\n  \u003Cdiv id=\"screenshot\"\u003E\n    \u003Cimg
src=\"/admin/themes/preview_for/cutline\" alt=\"Theme preview\" title=\"Cutline (rhtml) (v1.1)\" /\u003E\n    \u003Cp\u003EToday, you can put
an end to boring default styling and step into a world where your posts will become more artistic, more engaging, and more
compelling!\u003C/p\u003E\n  \u003C/div\u003E\n  \u003Cdiv id=\"theme-options\"\u003E\n    \u003Cul\u003E\n          \u003Cli\u003E\u003Ca
href=\"/admin/themes/change_to/cutline\"\u003EUse theme\u003C/a\u003E\u003C/li\u003E\n      \u003Cli\u003E\u003Ca
href=\"/admin/design?theme=cutline\"\u003EEdit theme\u003C/a\u003E\u003C/li\u003E\n          \u003Cli\u003E\u003Ca
href=\"/admin/themes/export/cutline\"\u003EDownload theme\u003C/a\u003E\u003C/li\u003E\n          \u003Cli\u003E\u003Ca href=\"#\"
onclick=\"if (confirm('Are you sure you wish to delete this theme stored at \\'themes/site-1/cutline\\'?')) { new
Ajax.Request('/admin/themes/destroy/cutline', {asynchronous:true, evalScripts:true, method:'delete'}); }; return false;\"\u003EDelete
theme\u003C/a\u003E\u003C/li\u003E\n        \u003C/ul\u003E\n  \u003C/div\u003E\n\u003C/div\u003E");
Dialog.current.layout();
It looks like the parent window from the admin console was redirected to “/admin/themes/show/cutline” and the meta data/contents of the theme dialog box intended for some javascript was displayed as plain text to me. After staring at this for a while I started looking for help on the Internet and eventually found an article explaining that I needed to make a code change to app/controllers/admin/themes_controller.rb near line 5:
before_filter :protect_action, :only => [:export, :change_to, :rollback,
 :import]
...should be changed to:
before_filter :protect_action, :only => [:export, :rollback]

One to do item here is to check whether the latest, edge version of Mephisto contains this fix already or not. I’m sure it does. Even after making the change on hostingrails.com I struggled for some more time before realizing that I had to kill any dispatch.fcgi processes running on the server before a code change would take effect. This wasn’t a problem in my local, development setup. Passenger must load and cache Ruby code after the first request. This would be interesting to explore further.

I tried again and this time: success! Finally I was able to switch to the new theme. Excited, I quickly took a look at my new site and saw... nothing! More troubleshooting revealed this error in my production.log file:

SystemExit (Define INLINEDIR or HOME in your environment and try again):
...ruby/gems/1.8/gems/RubyInline-3.7.0/lib/inline.rb:93:in 'abort'
...ruby/gems/1.8/gems/RubyInline-3.7.0/lib/inline.rb:93:in 'rootdir'
...ruby/gems/1.8/gems/RubyInline-3.7.0/lib/inline.rb:107:in 'directory'
...ruby/gems/1.8/gems/RubyInline-3.7.0/lib/inline.rb:277:in 'so_name'
...ruby/gems/1.8/gems/RubyInline-3.7.0/lib/inline.rb:317:in 'load_cache'
...ruby/gems/1.8/gems/RubyInline-3.7.0/lib/inline.rb:653:in 'inline'
...ruby/gems/1.8/gems/image_science-1.1.3/lib/image_science.rb:84
...ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in 'gem_original_require'
...ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in 'require'
...rails/activesupport/lib/active_support/dependencies.rb:496:in 'require'
...rails/activesupport/lib/active_support/dependencies.rb:342:in 'new_constants_in'
...rails/activesupport/lib/active_support/dependencies.rb:496:in 'require'
...plugins/attachment_fu/lib/technoweenie/attachment_fu/processors/image_science_processor.rb:1
...ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 'gem_original_require'
etc...
Some further searching on the Internet revealed that the problem here was that an image library called ImageScience requires something called RubyInline. Looking at the stack trace, it seems that the “attachment_fu” plugin uses the ImageScience library. Probably this is used by Mephisto to produce the thumbnail preview images in the Admin->Assets page. The solution in this case is to create a folder on the server for RubyInline, and to set this value near the top of Mephisto’s environment.rb file. Along with my change from last week to force the production environment, the top of config/environment.rb looks like this:
# Uncomment below to force Rails into production mode when
# you don't control web/app server and can't set it the proper way
ENV['RAILS_ENV'] ||= 'production'
ENV['INLINEDIR'] ||= 'inline'
I tried again to see my site, and this time still saw a blank page. View->Source revealed that the Ruby code in the view was not being executed. Finally I installed the “mephisto_erb_templates” plugin as instructed by http://mephisto-themes.nanorails.com/2007/3/21/cutline-theme.
script/plugin install http://svn.nanorails.com/plugins/mephisto_erb_templates/
Now the theme worked properly. I made a few cosmetic CSS tweaks, picked my own image and ended up with this page.

1 comment Tags:·

Mephisto Setup on HostingRails.com

September 09, 2008 · 0 comments

In the past I’ve setup blog sites using B2Evolution, WordPress and other PHP frameworks and had no trouble at all. Last week I setup this web site using Mephisto on a Rails hosting service (hostingrails.com), and expected to get it up and running in just a few minutes; after all, if installing and configuring a PHP blog site in 2005 was easy, certainly doing the same in 2008 with better technology (Rails) should be even easier.

Wrong!

First I created a MySQL database on my production server and called it “mephisto”. Then I set the char set and collation settings using the command line:

# mysql -u myusername -p
mysql> ALTER DATABASE mydatabasename DEFAULT CHARACTER SET utf8
  COLLATE utf8unicodeci

Since I’m not ready to write my own Rails blog site, I decided to download and setup the latest version of Mephisto (0.8 “Drax”). When I tried to download the TAR file from the 0.8 Drax link using curl I got HTML that redirected me to a different location:

# cat master.tar.gz
<html><body>You are being <a href="http://github.com/tarballs/technoweenie-
mephisto-90e2cc253d94e2e544bc8b21f361c7360c1e9baa.tar.gz">redirected</a>.</body></html>

Probably this is standard behavior by github and I should have used that directly. I need to stop thinking like a PHP developer! Regardless, it wasn’t much trouble to download the actual Mephisto TAR file:

# curl -O http://github.com/tarballs/
  technoweenie-mephisto-90e2cc253d94e2e544bc8b21f361c7360c1e9baa.tar.gz
# tar xvf technoweenie-mephisto-90e2cc253d94e2e544bc8b21f361c7360c1e9baa.tar.gz
# mv technoweenie-mephisto-90e2cc253d94e2e544bc8b21f361c7360c1e9baa mephisto

No big deal; so far this was a very similar experience to setting up a PHP web site: create the database, download the code and you’re almost done. Next, I entered the proper values in database.yml and tried to initialize the database:

# rake db:bootstrap RAILS_ENV=production
(in /home/myusername/mephisto)
Your config/boot.rb is outdated: Run "rake rails:update".

It was at this point that my problems started. First I wasn’t sure why I received this error message at all. Next I tried to use rails:update to fix it as instructed and ran into further trouble. A couple of hours and 5 or 10 blog posts later I discovered the solution here in this great write up. It turns out that Mephisto 0.8 does not work with Rails 2.1 and I needed to downgrade to Rails 2.0.2. Since I’m using a shared server on hostingrails.com I used rails:freeze:edge to get the proper version of Rails installed in my app’s folder:

# rake rails:freeze:edge RELEASE=2.0.2
Downloading Rails from http://dev.rubyonrails.org/archives/rails_2.0.2.zip
Unpacking Rails
Updating current scripts, javascripts, and configuration settings

At this point I tried to initialize the database again but this time got a different error:

# rake db:bootstrap RAILS_ENV=production
(in /home/myusername/mephisto)
rake aborted!
undefined method 'install_gem_spec_stubs' for #<Rails::Initializer:0xb7c652e8>

As explained here, I still had to manually copy one file from Rails to my application which rails:freeze:edge didn’t handle properly, using this command from my app's folder:

# cp vendor/rails/railties/environments/boot.rb config/boot.rb

Finally I was able to run rake db:bootstrap successfully! The last bit of configuration I had to do was to add this line to config/environment.rb in order to insure hostingrails.com used the production configuration:

# Uncomment below to force Rails into production mode when
# you don't control web/app server and can't set it the proper way
ENV['RAILS_ENV'] ||= 'production'

After creating a symlink and doing some other standard configuration for hostingrails.com, I was finally able to get my site up and running. It was a lot harder than configuring a PHP site and ruined a whole evening, but in the end wasn’t all that bad.

0 comments Tags:·

Why to use TDD with Drupal

September 02, 2008 · 4 comments

Drupal is a very popular Content Management System (CMS) developed using PHP. It’s a great way to get an interactive, community web site such as a blog or discussion forum up and running quickly without writing any code. But Drupal is a poor choice for general, complex web application development for a few simple reasons:

  1. It doesn’t use a standard, general software architecture such as Model-View-Controller (MVC) like Rails or Struts.
  2. Drupal doesn’t employ or support modern development best practices such as Test Driven Development (TDD) or automated testing more generally. (Exception: the SimpleTest module can provide some automated integration testing using HTTP without opening a real browser.)
  3. While the module API does allow for some customization, it can be easy to get into trouble if your target application is outside of Drupal’s design center. Specifically, you may end up having to modify Drupal’s core code or database schema when Drupal doesn’t behave the way you would like.

A better choice for more general or complex web development would be Ruby on Rails.

If you do need to develop a custom web application using the Drupal framework, you can avoid problems #2 and #3 by using a test driven approach. Instead of simply implementing your custom logic by writing PHP code to the Drupal module API, try pulling your custom code out of Drupal entirely and running it independently of the framework. This will insure that your custom code could someday be run with another web framework and also help you avoid the temptation of modifying Drupal’s core code directly. Of course, you will also get all of the normal benefits of TDD: better design oriented around business requirements, live documentation through executable code, etc.

How to do this? Write tests first using PHPUnit (which fail), then get your tests to pass by implementing the desired behavior using PHP 5 objected oriented code. Lastly, write a “shell” module that calls out to your test driven object oriented PHP code from Drupal. This means your code will be run twice: once from the command line by PHPUnit during development and from your CI process, and again from Drupal to process end user requests in production.

In a series of future posts I'll write a Drupal module using TDD, using a few tips and tricks along the way to get PHPUnit and Drupal to play together nicely.

4 comments Tags: