Troubleshooting Tutorials

Ruby/Homebrew breaking with OS X 10.10 Yosemite Upgrade

Warning: I’m assuming if you have homebrew installed then you are familiar with the command line. If you aren’t familiar, don’t attempt this or ask someone that is.

Apple updated Ruby from 1.8 to 2.0 in Yosemite, so homebrew might not work and you’ll see an error like this:

/usr/local/bin/brew: /usr/local/Library/brew.rb: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby: bad interpreter: No such file or directory

If you haven’t upgraded to Yosemite yet, run brew update first, and I think that will patch the Yosemite/2.0 issue.

If you have already updated, you’ll need to cheat a symlink to trick home-brew into thinking you are using 1.8 still. Run these commands:

$ cd /System/Library/Frameworks/Ruby.framework/Versions
$ sudo ln -s Current 1.8
$ brew update

Once that’s done, you should remove your symlink:

$ sudo rm 1.8
Scripts Troubleshooting

SVG Wonkiness in Safari 5.1

I had a client who was still rocking an old school iMac that was running OSX Snow Leopard. That’s the latest version you can install, and as a result, can only upgrade to Safari 5.1. As I was using SVG in <img> tags on this site, they were rendering really oddly.

<img src="" onerror="this.onerror=null; this.src=''" alt="Superior Campers">

It was as if the browser was adding padding: 50px 0; to the <img> but I couldn’t override it. I found a quick and dirty jquery fix for this. This works assuming you have an PNG fallback for your SVG’s, which you should for IE8 (at least as of the time of this writing).

//safari 5.1 polyfill hack
$(window).load(function() {
  //all images with .svg
  $('img[src*=".svg"]').each(function () {

      $self = $(this);

    //If rendering really tall
    if ( $self.height() > 900 ) {
      //go to IE png fallback
      $self.attr('src', $self.attr('src').replace(/.svg/, '.png'));

Because Modernizr showed this browser as supporting SVG, the hack is to look at the .height() of the <img> after all resources are loaded, and if it’s over 900px, fallback to the PNG. Not pretty, but it fixed the issue. Let me know if you found a better fix.

Troubleshooting Workflow

Ugh. Checking out files with Perforce

If you are one of the unfortunates that have to use Perforce version control (I prefer Git), you may have the same annoyance I do:

File Not Readable

If you are like me and used to Git, where you don’t have to check out files, try this little ditty:

  1. Checkout your whole folder you are working on (for me, it’s the WordPress theme I’m writing).
  2. When you are all done with your changes, right-click that same folder and click revert unchanged files ($ p4 revert -a) and that unchecks out the files you didn’t touch.

Not as great as just using a version control system that doesn’t require checking out files, but better than getting this alert on every file you try to edit (or every file sass or uglify tries to compile).


Using CMS Made Simple with Nginx

I am pretty much a WordPress guy these days, but I do have one legacy site on CMS Made Simple. I was migrating it over to my new Ubuntu server running Nginx, and was having issues.

The Issue

CMS Made Simple was thinking for some reason that the site was using SSL. I’m guessing the test for SSL wasn’t compatible with Nginx. I pinpointed it down to the fact that CMSMS was adding a <base> tag at the top of the site that contained https://.

The Fix

After a few hours I figured out the fix. You can tell CMSMS to disregard this <base> tag with one line of code in your config.php file:

$config['showbase'] = false;

That’s it. I didn’t see this specific fix out there at all, so I thought I’d make this quick post. I’m not sure why this tag is there to begin with.

Tvenge Design