My project for the coming months is for Daniel Schlusser, better known as our man in berlin, though he isn’t. In Berlin, I mean. Theatre director and rather talented to boot, and perhaps other things to write of with him shortly.

A new website. Excitement of jQuery, some ideas for typography. Matthi is a typographer and genius in FontLab and Illustrator, so I ask him how to dismantle a font, remove various bits that make up a letter, all of which have names I don’t know. I thrill for beautiful typography, and it’s what I enjoy possibly the most in design, but actual making of fonts is deeply unfamiliar to me. So this is a story of how I learn about fonts.

The two things I wanted to do were convert a font into an outline (not to be confused, I think, with a outline font), and chops bits off. My approach, as Matthi laughed, was very Photoshop. Much messing around ensued, and without his help, I’d have been doing it for months in my awful untrained way.

So…

Using the serif font, Tenderness from dot colon and opening in FontLab Studio, which to be uncharitable strikes me as an application ported to OSX without much thought towards standard user interface behaviour. Then opening a single letter or glyph in its own window and exporting as .eps. Now for playing.

Opening the .eps file in Illustrator and first hacking away bits (which I haven’t done in my test glyphs as I was more interested in workflow possibilities), and then turning it into an outline. The process is quite simple, once I learnt it, but I wouldn’t have stumbled onto it on my own.

Selecting the entire glyph and then setting the fill color to transparent and stroke to black, gives a one pixel outline. Opening the stroke pane and setting the weight to 6 pixels gives it some width. Then the important bit, selecting from the menu – Object – Path – Outline Stroke makes the vector path the width of the new 6 pixel outline. Saving as .eps again finishes the work in Illustrator.

Copy-Paste, back into the glyph in FontLab, aligning with the original, then shift-selecting to select the original before deleting (fixing up the mess, I called it), and saving the results…

First to export as something useful, .ttf, though it seems to not preview properly in FontExplorer… nonetheless! My first attempts at font stuff. (I’m not sure it will even be used, and there’s more work to do yet…)

Earlier this year supernaut got hacked. Many other of my WordPress installs did also, perhaps because they occupy the same shared hosting space. I learnt a lot about website and WordPress security very quickly – even to the point of inadvertently vanishing all but my index page for quite some time. Nothing if not clever, I am.

Because I am doing all my projects in WordPress at the moment, and also seem to have turned quite a few people over to using it also, I thought to document my approach and methods. The first thing I do then, is read. A lot.

I have a subjective and not-too carefully analysed approach to learning, especially when it comes to finding out information on a topic I know nothing about and need to know much quickly. It applies to everything, not simply limited to web design or computer stuff. I search and read and search and read and keep repeating until the same stuff starts to come up over and over again. Then I start to think I might be on the right path. So I might try a few things then. The key here is easiness. Anything requiring more than a few clicks, a few lines of text or modifications is not a reasonable solution.

Things that break this early get thrown away. A plug-in that asks for stupid things, or doesn’t perform without me rewriting some line in php.ini is not going to stay installed long. I wondered often if this was the wrong approach, but really, basic, effective security should be as simple to understand as a household door key. You shouldn’t have to build a lathe in order to cut the key yourself.

So, having done some research and playing, I slowly put together something useful. This is a mix of things I’ve been using for a while, and new things I’m adding at the moment, in response to pissy annoying php exploits, sql injections and other clever irritations.

Installing WordPress.

The first thing to change during an install is the database table prefix wp_. If you’ve already installed WordPress, it’s possible to also change this either using a plugin, or by editing wp-config.php and changing the table prefixes in phpMyAdmin.

Once logged in, make a new user with administrator privileges and suitably complex password (OSX Keychain Access has a very good password generator), log in with the new user and delete the user, ‘Admin’.

Now is also a good time to delete the default theme (after uploading your new one of course). As with the user named ‘Admin’, the wp_ table prefix and other defaults, botnet code injection methods look for these defaults as an easy place to start.

To avoid messiness, I think it’s better to leave installing plugins till last, though because information is sent in the clear unless using SSL or SSH, it’s probably a good idea to change the password again when it’s all finished.

Get rid of install.php

After your installation is finished, you don’t need this file, located in wp-admin. Delete it, or change the name, or even better log attempts to access it with this (just change the email address to receive notifications):

Dealing with wp-config

Every time I open this file and see the database name, user, password and host all in plain text, I get a little queasy. There are several ways to make this less painful, firstly using htaccess, which I’ll cover later. A quite elegant solution is to put all the sensitive information in a separate php file outside the root web directory, and make a call to that in the wp-config file.

First make a new file, config.php stick it (on Dreamhost) in the /home directory, chmod to 644, and cut-paste the following from the original wp-config.php:

Then in the original file, just put:

For those lucky enough to have SSL on their server, using FORCE_SSL_ADMIN is an excellent idea. Changing permissions to 640 also is a good idea.

Adding Unique Authentication Keys takes about 30 seconds, and gives four separate keys to be used with your password. Copy-paste from the Secret Key online generator, it will look like this:

Functions.php

Most themes have a functions.php file which does all sorts of exciting things, writing bits to the theme templates, interacting with WordPress admin interface… A couple of extra lines provide a little obscurity. WordPress puts its version number in the header in wp_generator, and also a link to xml-rpc.php, which for most people is unnecessary – unless they are using a blogging client like Marsedit – and a risk. This quickly removes both, as well as hiding information about failed login attempts through the browser:

htaccess

.htaccess is a joyous little world unto itself, like finding a hole in your backyard that leads into a vast cave system. mmm spelunking.

Much of my learning about security has revolved around what can be done with htaccess, and in particular Perishable Press and their 4G Blacklist. And much of what I do for security takes place here.

Starting with denying access to all to read the htaccess file itself. Then there is the WordPress hook that allows the install to exist in a different directory location to the site url. For those again who have SSL on their server, forcing SSL can be done here for admin and login. Then there are a bunch of protections to stop access to certain important files, install.php, wpconfig.php, and the WordPress readme.html.

Using gzip compression to deliver files and adding content expires information doesn’t strictly have much to do with security, but really, the difference in load times the former can make to a site, and the general usefulness of expires tags make this one to automatically add.

For those on Dreamhost, the DH-PHP handlers is automatically added when using the site-specific php.ini installer, something I’ll cover a bit further down.

Hotlinking prevents leechers sucking images and other content off your site, one of the first things I ever learnt how to prevent, when supernaut suddenly had massive bandwidth use as my images turned up in all manner of places.

The no-referrer section is specifically to thwart spammers circumventing your site altogether and trying to inject comment spam directly into the comments php. It’s also possible to block access to xml-rpc here, and use login passwords via httpasswd for extra security on the login page, both not included here.

Then comes the Perishable Press 4G Blacklist, a cornucopia of amazingness, which I left out for sake of brevity (haha). I have included two lines that need to be commented out in order for the browser-based file manager AjaXplorer to function ok.

robots.txt

Equally effective, and probably overkill, using robots.txt can grant or forbid access to a slew of places, particularly directories that you don’t want spidered, as well as any and all WordPress directories, using Disallow: /wp*.

php.ini and phpsecinfo

Getting deeper into the system still and further yet from WordPress, modifying php.ini, the file that sets up what php can do is another essential. Dreamhost doesn’t make it easy to edit the php.ini, but fortunately there’s a script which installs it locally. More excitement ahead.

As with htaccess, much can be done in php.ini to prevent messiness. The following seem to work rather well. I’ll leave this uncommented upon except to say AjaXplorer needs fopen to be on, and shall devote a future post to elaborating on php.ini security.

In addition to editing php.ini, and making sure there isn’t a file lying around called info.php with phpinfo() inside, phpSecInfo is an invaluable tool for assaying the security of your website, the results from which can be directly used to edit php.ini.

FTP, or rather SFTP.

As with passwords being sent in the clear, so too is FTP on its own not so great. Dreamhost allows for shell plus SFTP access with FTP disabled, which is both sensible for using desktop FTP clients (such as the amazing Transmit), and for searching out code injections. Time to open Terminal.

Commandline access is essential for a number of reasons, and instead of using the username/password combination, create passwordless login using private keys.

Why might this all be useful? Going back to when I was hacked earlier this year, I could have gone though all the files on all my sites looking for base64 code, instead I opened Terminal, SSH’ed in and sent this command:

Which searches through all files with the extension .php for the string base64 and dumps the results on screen. I found every instance of the hack in a matter of seconds.

Plugins for security.

Leaving aside all that code now…

WordPress is amazing because of its plugins and the community around its development. The problem though, for any plugin is twofold. Which one does the task you want the best (while integrating with the rest of your setup), and is updated frequently enough to not become a liability?

After the initial hack, I had many installed, which I then uninstalled because of small irritations and annoyances. After changing all my passwords to 16+ characters, including as many of type !@£$%^&_ as allowable, WordPress File Monitor has become an installation standard.

Rather than provide security, it lets you know when any modifications to files and folders have occurred, and in which. Notification via email and/or Dashboard alert, alterable scan intervals and directory path exclusions for me make this indispensable. When a new exploit emerges, instead of panicking and manually scanning all my installs for changes (which I do anyway out of nervous boredom), I can be fairly secure they will show up here. Of course, the idea is not to get hacked in the first place.

I’ve read a lot of good things about AskApache Password Protect, but I’ve never got it working, despite adding all the .htaccess files and even chmod up to 666. I would at least play with it otherwise, but for now don’t want to spend the time on it.

In general though (and said with a caveat that I don’t really know WordPress very well), much or all security that can be done with plugins can be done in other ways – .htaccess, robots.txt. php.ini, wp-config, sql changes and so on. Also, so many of the plugins haven’t been updated recently, which for me is worse than no protection due to the false sense of security.

During the course of the last two days, while I went through all the security stuff I could find, websites, pdfs, my own archives, I came across a couple of other plugins which I think are useful.

Semi Secure Login Reimagined provides about as good public and secret key encryption for passwords as possible if you don’t have access to SSL.

WP Security Scan I found useful for a post-install check to make sure all the settings were as minimally tight as could be. In the interests of not having hundreds of plugins, I uninstalled it after.

404 Notifier does just that, though I suspect getting off my ass and reading the logs (or ssh and then grepping them for 404s) would be a better idea.

Sources

Much of my information for this comes from a few places.

The WordPress Codex itself is a good place to start, and the Plugin directory also worth spending time in.
Perishable Press is invaluable, and not just for security.
Digging into WordPress, both the website and the book are the fundamental step-by-step guide for all things security and WordPress.
The WordPress community, across many blogs, forums, books, comments and bits and pieces.

Oh, and while this applies also to WordPress 2.9.x, I’m currently running the 3.0 beta on thingswithbits.info where I tested all this. (hopefully this all doesn’t add to confusion.)

Two big problems emerged. Firstly was the pain of updating static HTML. Even though I write my blog posts in this way, and have no difficulty screening out code from in front of my eyes, this way of managing a site is painful. The second big problem was the conflicts between how the content on the page was loaded and both video and images. The plan had always been to put the site into WordPress, and so I did.

The idea for using Daniel as his own background image was a fairly inevitable one, remembering when I first saw him, all piercings, blue mohawk, tattoos. I first tried supersized for this, but found it slightly heavy for just a single image. Lucky then CSS-Tricks had the perfect, all-css answer, which has become one of my favourite bits of code, being fond as I am of huge background images.

First though, I had an idea for the menu, coming from jQueryTools’ accordion tabs, with much eviscerating of CSS and some slowing down of the slide effect. This though, I could never get to work in WordPress. Much messing around in jQuery, dynamically adding classes and divs and removing them from elsewhere, I could even get it to work using an identical sidebar HTML structure to WordPress, but when I tried to use it in WordPress, weirdness ensued. I really wanted to use this though, because it’s the only accordion I’d seen with different times for the sliding effect.

But WordPress has almost everything, and I fell upon jQuery Accordion Menu for Wordpress, which has very similar code, taking a couple of hours at the most to get the CSS right and working rather nice.

Of course when I added the page crossfade eyecandy, it broke again. My fault for using redirectPage.

supernaut still uses the Flash-based sIFR method for using nice fonts, but the last couple of sites I’ve been rather enjoying the combination of open-source fonts and @font-face. Not one of those beautiful new CSS3 adventure like opacity or rounded corners, even Internet Explorer 5 supported this, and lately with a deluge of options for pretty typography, it has become increasingly popular. And far easier to implement that sIFR also. Oh, the title font is Anonymous Pro, which I think is one of the most elegant monospace fonts around (also important that is has Unicode-based character set, important for things like ü and ß).

Being dance, video was always going to be lurking. I wrote about my fun with Flowplayer and WordPress earlier, and still finishing this, with bandwidth check, pseudostreaming and the inevitable full-screen option shuffling this way. I’d rather be doing this all in HTML5 though, and shall come up with a graceful degradation from that to this in my next project.

A bunch of small plugins helped me along the way also. Add From Server let me add video to the WordPress Media Libary after I’d uploaded via FTP – perfect for large file sizes, and modifying allowable upload file types meant I could get the f4v there also.

pageMash made structuring the site and reordering projects as they move from ‘soon’ to ‘now’ to ‘then’ so much nicer than blah-ing around editing the pages themselves, and PHP Execution made it possible to do the Flowplayer video cludge.

Elsewhere, Lightbox Plus for a not-overpowering image gallery, though I am still working on this. DB Cache Reloaded and Hyper Cache for the necessary site caching, as long as I don’t forget to disable them when I’m busy working. PHPEnkoder, based on my favourite Hivelogic anti-spam email encoder. And WordPress File Monitor, which is about the most useful anti-hacking plugins I’ve found.

Oh, and page crossfade! I know it’s a bit Flash 2001, but I really did want to recreate the page fade-out/-in from the original site. (Not so good if JavaScript is turned off though.)

On another project I did recently, bedrohtevoelker.de (a simple transfer into Wordpress using a template to make updating content easier), I used FV Wordpress Flowplayer, but like all the plugins, and all the other players I’ve seen, there was little or no possibility to customise the controller or other background aspect.

I’ve been working on bringing Daniel Jaber’s website into Wordpress in the last week. The original site, hand-coded falls apart in three quite important areas. Firstly, being html it’s a pain to update. Secondly, the combination of site structure and function make it a pain to get video and images to work properly, and thirdly, it breaks in the standard browser that things break in.

I thought I’d begin by first uploading all the text content, using Blueprint CSS again, which I’m customising more and more with each project, formatting this, and the general site structure and layout, deal with the image overlays, and then move onto the accordion menu and perhaps AJAX-ing the page loading after I’d done the video. The last couple of days have been video.

Much searching and trialling of plugins led me to think it was not going to be easy to recreate the video player as I’d coded it using this approach, so I started to look for both another workable option, and a fallback (ugh) in case there wasn’t.

My first serious approach was Manually Adding Flowplayer to a Wordpress Theme, a step in the right direction, but not so manageable also. So then I started thinking, well it’s just a clump of Javascript with some specific HTML on the end, why can’t I just paste that into the HTML editor in Wordpress? Because when you do things like that, Wordpress breaks them. My next idea was, well, is there anyway to not-break them? Somehow my feeble brain stumbled back towards inserting PHP into a post.

Hallo Wordpress PHP Execution Plugin. Though I did try the highly downloaded Exec-PHP first, it only allows pages to be written in HTML mode, not so good for people who just want to upload content. PHP Execution semi-allows this. in Visual mode, the PHP sits behind an image, so doesn’t get converted into junk. The semi-part is that if you edit a page in Visual mode, it breaks, but there is a cludge-ish workaround.

I started first by following the original article, adding the Flowplayer code to my page template, to make sure it worked and where it broke, then transferring it into a test-page and seeing the same. In the end, very little went askew. The plugin handles indented code formatting without letting Wordpress stick a p or br tag between every new line, and respecting for the most part spaces as spaces, and the occasional addition of \ escapes was all the extra I added.

The only place it really gets affected is a matter of styling, where any line breaks between divs and other html markup, i.e. the last lines which create the player and controller have a br added between. Running all these lines into one fixed that, and the css I used in the original layout largely carried across to the new site – though I cleaned it up a little and took advantage of some CSS3 rounded corners.

Once this was all done, I decided to add a little pleasure for Daniel while editing a project page. The standard PHP Execution plugin covers the code in a small purple-ish ‘PHP’ graphic. I thought it’d be nicer, as the idea is for him to do everything besides the video in visual mode, to replace that graphic with a corresponding one representing the splash image for the player. A couple of minutes in Photoshop and then changing a couple of lines in the plugin’s css and happiness ensued.

What’s left to do then is get this working with multiple players on the same page and add in some of the other good features such as bandwidth streaming. With all of Flowplayer contained in the JavaScript or in a couple of lines of html and only making calls to either the player’s JavaScript or .swf files, this method seems to be the best I’ve come across that allows for both the abilities of the player and the simplicity of Wordpress to work together. The only place it seems to break is if you edit the page in visual mode, but at least visual mode isn’t ruled out entirely, and copy-pasting the player code with edits for the correct file paths in html mode as a last step is an acceptable-ish compromise.

Oh and the code below, using the CodeColorer Plugin, which works fine from ecto also.