Blog

MAMP Pro on Yosemite Beta 5

Update: The developers of MAMP recommend the following workaround:

Workaround for the 10.10 Preview 5 bug: Rename the file “envvars” located in into “_envvars”

If you’re running MAMP Pro 3 and you installed Yosemite preview 5, you’ve probably noticed Apache won’t start anymore, with the following error:

dyld: Symbol not found: _iconv
Referenced from: /usr/lib/libmecabra.dylib
Expected in: /Applications/MAMP/Library/lib/libiconv.2.dylib
in /usr/lib/libmecabra.dylib

This is some kind of library error because of an updated library in the newest preview. You can fix this by forcing your own version of libiconv onto your computer, though you have to replace the system default version of libiconv, which in theory could cause bad things to happen – i’ve not noticed anything, but your milage will vary – and you should make sure you’ve got a system backup of everything incase the worst does happen.

Hopefully you’ve already got homebrew installed – if not, grab it from brew.sh and follow those instructions, then:

1) Allow homebrew to install duplicates of system software: brew tap homebrew/dupes
2) Install libiconv: brew install libiconv
3) Force it to link (replace) the system default: brew link libiconv --force
4) Delete the MAMP version of libiconv:
rm /Applications/MAMP/Library/lib/libiconv.2.dylib

Then everything should start properly.

Using UnCSS and grunt-uncss with WordPress

Following on from my last blog post about modernising WordPress development with grunt, we’ve been using the process for a few months at Storm and have been slowly making it better.

This week, while working on pretty heavy project, we noticed that our compiled single CSS file was a huge 6,500 lines and ~180kb. This is still better than loading a bunch of different CSS files, but still less than ideal.

The problem is, we use Zurb Foundation, and not using a bootstrap/foundation/grid isn’t an option for us – You get way too much stuff for free, and I call BS on the usual argument that “all sites look the same” – that just means you’re not using it properly, or you’re throwing something together lazily.

Zurb is awesome – this site is built in it – but, by it’s nature, it contains probably 75% more stuff than you’re actually going to use, and there is really no point in making the browser download and parse the 75% of stuff you’re not actually using. This is where UnCSS comes in. Continue reading “Using UnCSS and grunt-uncss with WordPress”

Modernising WordPress theme development

Last October, I spent two days at #fowa in London. One of the most common themes that came out of it was how far automation tools have come in the last few years.

Where I work at Storm, we have two groups of devs, I’m lucky enough to lead the WordPress and PHP team while upstairs sit the ruby guys. They’ve spent the last few years writing with modern cool stuff like CoffeeScript and Sass/Less and deployment things like capistrano. They also like to write tests, which as a long term PHP guy, I’ve really never understood, and hey – I’m a WordPress developer, so I have to write everything the way WordPress lets me, and that means using this cool new complicated stuff is even more complicated.

Since last October, i’ve been slowly working to move our WordPress development to a modern workflow of grunt and Sass. I decided to use my website redesign as a way to expand what I had already done at Storm to include CoffeeScript, bower, compass, and composer.

Grunt is a task automation tool, and already it’s started to fall out of favour with the web geeks (with people moving towards gulp), but seeing as Zurb Foundation uses it as their SASS compilation automation tool, and the vast majority of the code I write sits on Zurb’s grid, it made sense for me to use it.

Bower is a “package manager for the web” – it lets me specify a list of “things” I want to use in the project (or, in this case, the WordPress theme) and handles downloading and updates to them. For example, for this theme, it is handling Zurb foundation, the Compass core Sass library, jQuery smooth-scroll, animate.css and jack-in-the-box. It also handles dependancies, so by including Zurb, i’m automatically given jQuery and Modernizr too.

Compass is actually a ruby tool to handle Sass compilation which would replicate part of grunt’s functionality, but it has a nice open source library called Compass Core which provide mixins that come in handy when writing Sass. I use it to give me browser prefixes and older browser support for modern CSS3 features.

Composer is a PHP package manager. In recent times, the majority of common SDKs have added composer support, meaning just like bower, it’s possible to just “require” Facebook, or PayPal, or any other supported library, and have it available inside your project.
Sidenote: Notice how the PHP tool has the ugliest website out of all of them?

Adapting a WordPress theme to use these tools is a surprisingly complicated task, at least it was for me after many years of working in the traditional development way. While WordPress is moving towards these kinds of technologies (3.8 includes Sass compiled admin colour schemes, and there is discussion of moving over to include much more Sass and a compiler in a future release) it’s still a very manual process of enqueuing every script and stylesheet you want to use in your functions file, and writing simple css. There are then after deployment plugins that will handle minification and concatenation of your scripts and styles.

I replaced that with a local system of compilation and minification; that way you can easily detect errors before you go live, and you only need to enqueue one style, and one script – minified app.min.css and app.min.js for production, and expanded but concatenated app.css and app.js for development. I also remove the default version of jQuery from WordPress, leaving Zurb’s default (current) one to take over. This has some potential for problems, but I’ve not noticed anything yet. WordPress are pretty good at keeping their third party libraries up to date, or at least compatible with the latest versions.

Grunt watches for anytime I modify any of the files in the theme and rebuilds everything it needs to, reloading my browser in the process to save me needing to leave my IDE to see the changes to the code I just wrote. If anything goes wrong, I get a growl notification giving me details of where my syntax errors are, before I even reload the page. This has already saved me so much time and made my workflow significantly faster, and that’s good for everyone.

Grunt also handles making sure every image I use on the site is compressed as best as it can be – stripping any meaningless data, essentially doing a “save for web” in photoshop (but actually getting about ~6% smaller filesizes than that).

Anytime any library I use is updated, a simple “bower update” takes care of dropping the right files in the right place without any interaction from me, while the semantic version numbering means it won’t ever update to anything likely to break anything in the theme (too badly, at least).

I hope to release the base theme we use at Storm open source later this week – that’ll give you everything you need to get going in this exciting world of modern web development.

MAMP Pro under OS X Mavericks

If you’re a developer and you got access to use Mac OS X 10.9 Mavericks earlier this week, you’ll notice that it’s actually mostly a hassle free experience, apart from changes to the code signing and authorisation model that mean non-signed applications can no longer elevate permissions to root level.

Now, this shouldn’t matter to most people – but if you use MAMP Pro, you’ll find this isn’t signed at all, and means it’s unable to get access to write to the important system files. You’ll get an error about not being able to write to /etc/hosts.

I’m sure the next version of MAMP will fix this, but for now, you can self sign the app to give it permission to modify system preferences.

You just need to open keychain access, click on it’s menu bar item “Keychain Access”, then “Certificate Assistant”, and “Create a Certificate”. For Name, enter your name, Identify Type should be kept as Self Signed Root, and Certificate Type should be code signing. You can pretty much click continue on everything else until your certificate.

Finally, open terminal, and run:

codesign -s “Your Name” /Applications/MAMP\ Pro/MAMP\ Pro.app

That’ll sign the application as you and let you execute it.

Obviously, it goes without saying you’re telling your mac you trust any app you sign – so only do this if you’re confident MAMP Pro (or any other app that has issues on Mavericks with this error) is trustworthy.

Update:

If you still have issues, that probably means the signing didn’t take properly, you can run: codesign -v /Applications/MAMP\ PRO/MAMP\ PRO.app -v

Once signed, that should tell you that MAMP is “valid on disk” and it “satisfies its Designated Requirement” – anything else and the signing didn’t work properly and you should try again!