Multiplay Labs

tech hits and tips from Multiplay

Archive for July, 2013

Rails 2 to Rails 4 Basic Upgrade Tips

without comments

We’ve just had the “pleasure” of upgrading a very basic legacy Ruby on Rails 2 app to Rails 4 and the following where the basic steps needed.

1. Create a new app
2. Import the old code /app and /lib into the new app
3. Update the models
3.1. Update custom table name declarations

set_table_name 'table' -> self.table_name = 'table'

3.2. Update custom primary key declarations

set_primary_key 'primary_key' -> self.primary_key = 'primary_key'

4. Updated configuration removing any config.gem as this is maintained in Gemfile now
5. Migrate old app/controllers/application.rb -> app/controllers/application_controller.rb

In our app we use a custom path to log to for Rails 4 changing this is simply not documented, we found howere the following worked for us:-
Add to config/application.rb

# Use logs directory not log directory for logs
config.paths['log'] = File.join('logs', "#{Rails.env}.log")

Finally one of the plugins we used was validates_as_email which errored on startup due to a UTF8 error this was easily fixed by switching from // syntax to specifically:

--- validates_as_email.rb.orig       2013-07-22 12:53:11.360404644 +0000
+++ validates_as_email.rb      2013-07-19 08:36:52.969805090 +0000
@@ -25,7 +25,7 @@ module RFC822
     domain = "#{sub_domain}(?:\\x2e#{sub_domain})*"
     local_part = "#{word}(?:\\x2e#{word})*"
     addr_spec = "#{local_part}\\x40#{domain}"
-       pattern = /\A#{addr_spec}\z/
+       pattern = "\A#{addr_spec}\z", nil, 'n'

Written by Dilbert

July 22nd, 2013 at 9:47 am

Posted in FreeBSD,Rails

Rails 4 Javascript Dependency Failure on Boot

without comments

Rails includes a package manager which does on demand javascript packaging, this depends by default on node under FreeBSD which installs its binaries into /usr/local/bin which shouldn’t be a problem however the this isn’t in the path for services started at boot.

Because node can’t be found in the PATH passenger will fail to start the app.

We fixed this by adding the following to config/boot.rb

# Ensure /usr/local/bin is in the path
ENV['PATH'] = (ENV['PATH'] || '').split(/:/).push('/usr/local/bin') * ':'

Written by Dilbert

July 22nd, 2013 at 9:33 am

Posted in FreeBSD,Rails

Integrating Legacy PHP applications with WordPress

with 2 comments

Recently we wanted to integrate some existing legacy code into a new wordpress site we were developing. Obviously, we didn’t want to have to reimplement all the code for the wordpress theme separately in a standalone way just to make the two codebases visually consistent, so we looked into how to integrate the two, allowing us to make use of the wordpress theme within the new code.

This turned out to be surprisingly simple, albeit with a few caveats.

First of all, we made sure the legacy codebase had access to the wordpress installation. Next, in our main include in the legacy code (a setup/config script known to always be included), we added the following code:

require( "{$_SERVER['DOCUMENT_ROOT']}/wordpress/wp-load.php" );

This causes all pages in the legacy app to load the wordpress framework. Contrary to instructions on the WordPress Codex (which direct you to require wp-blog-header.php) this serves the page correctly, rather than as a wordpress 404 page. Obviously, you should adjust the require path to match your own environment.

Once this was done, in the legacy applications header and footer includes, we could use wordpress functions such as get_header() and get_footer() to include the parts of the theme we needed.

However, there are some caveats to this approach when integrating with legacy codebases. We found that the database connection of wordpress was overriding the database connection established by our legacy application. Since they had different permissions, the legacy application failed to perform any of it’s queries. A quick hack of resetting the connection back to the app after rendering the header, then restoring the wordpress connection prior to rendering the future fixes this. Obviously the correct solution is to update the legacy app to use a specific database connection object rather than the default of the last connection established, but this isn’t always feasible for some projects due to the time/resources involved.

Written by Andrew Montgomery-Hurrell

July 11th, 2013 at 8:19 am

Posted in PHP,Wordpress

Tagged with ,

GeoIP C interface isn’t all thread safe

without comments

It’s documented that GeoIP C interface after v1.3.6 is thread safe, with the exception of GEOIP_CHECK_CACHE, however this is not really the case.

A large number of the C API functions such as: GeoIP_new, GeoIP_open_type, GeoIP_db_avail call the internal _GeoIP_setup_dbfilename function which statically initialises the GeoIPDBFileName global pointer without any locking.

This means that if several threads call any of these methods to gain a geoip handle then its possible to trash the memory structure while its being read and hence result in a crash.

So if your using the GeoIP C interface in a threaded application ensure that you use locking around the use of these methods.

Written by Dilbert

July 4th, 2013 at 2:11 pm

Posted in Code