Tag: coding

Managed Themes Have A Place
This post is dedicated to Helen Hou-Sandi, who donated to help me get to WCSF. Helen and I like to Pass the Hat, to the amusement of my former firewall team. She also encouraged me to apply for the WP job I got last week. Thanks, Helen!

I’ve been using a managed theme on my main site (ipstenu.org) for the last few months, and I’ve decided I really like it. I’ve also started to sort out the kind of people who should be using it, and it’s not everyone.

Let’s start by breaking down themes into their logical types:
- A Theme – These are things like TwentyEleven, that you simply use as-is.
- A Child Theme – These are for tweaks you can’t make via plugins or css.
- A Parent Theme – This is a theme you know you’re going to extend.
- A Theme Framework – Similar to a parent theme, this is a theme you build off of. It may, or may not, be a parent, however. See ThemeHybrid’s themes, or the Bootstrap theme.
- A Managed Theme – A theme that acts like a framework and a child at the same time.
The differences between these types is slim and sounds like I’m arguing semantics. The weird magic of it all is that themes are themes, and there’s not a whole lot of difference between everything. So maybe I’m looking at themes wrong. The point of themes is that you should be able to make your site look how you want to, no matter your skill level. The problem is that with a low skill level, you don’t know how to do the things you want to. This is where managed themes come in.

A managed theme holds your hands, and takes the burden of knowing ‘code’ off of the user. While I’m not a fan of lowering the bar too much, there’s a point when we need to make the software easy enough in all aspects and not just some. WordPress isn’t perfect, and while it’s amazing a lot of things, there’s really too much going on in others. This is why there’s room for something like Tumblr, where it’s very easy to post (if hard to make your site look ‘right’). I see WordPress needing some improvement on posting, making it much easier for people to just write, and somehow separating that from the ‘managing a website’ part.

But at the same time, managing the website, making it look right, is crazy hard. There are a lot of options and a lot of possibilities. Anyone who’s tried to make a site for someone else knows how much like banging your head on a wall it can be. So when you’re new, and you can’t afford to hire the big guys to make a site, but you want flexibility without having to learn code, where do you go?

Managed Themes.

Look, I love a sexy Theme Framework. I’m a huge fan of ThemeHybrid. But part of why I love it is that I can get into the nitty gritty code, tweak functions, and go to the races. I spend a lot of time tweaking backends and testing layouts and messing with functions. But not everyone likes to do that, nor should they. I’m not a super snazzy theme designer, they’re not super awesome writers, it’s differences that make the world go around.

For the last few months, I’ve been using Genesis Theme and I have to say, if I was going to make a site to turn over to someone who I knew was somewhat savvy but not super technical, I’d pick that. It’s not ‘easy’, but this is something that a middle-of-the-road person could pick up, make their way through, and grow and advance as needed. It’s a perfect way to make your site not look ‘standard’ while still not meaning you have to be all action/hook/function skilled. After all, it takes a while to grow into that.

Managed themes aren’t for ‘me’ most of the time. I know that’s weird to say when you note that I’m using one. I’m really a framework sort of girl. I love the nuts and bolts. But when I don’t want to spend a whole day (like I just did) tweaking a child theme into submission, and just pick up and go and not look like an out of the box site, a Managed Theme is the way to go. I don’t have to worry about telling someone ‘Just edit the functions.php…’ when they want to change something. There’s a nice GUI for them.

I’ve played with a couple, but I have to say the only one that impressed me enough to give them a second chance was StudioPress’ Genesis Theme. Part of why I gave them a shot was because one of my best friends works there. But after half an hour of using it, I thought “This is easy.”

Who are Managed Themes for? They’re not for the newbies, and they’re not for the masters of all they survey. But if you, like me, don’t really like designing themes, and you’re not always wanting to pick apart code, grab a managed theme. I may still lean towards the Parent Theme Templates for myself, but right now, looking at a site my father wants, I’m looking at those managed themes.

They’re pretty darn cool.
13 August, 2012
Mountain Lion and SVN
Caveat: You need root access on your Mac to do this!

Ages and ages ago, when I first was using MAMP and all that fun stuff, Apple didn’t include a version of SVN. I had installed, and promptly forgotten about, my 1.4.4 install sitting out there. Now, I know I upgraded it to 1.6.something at some point, but I only found out that was wiped out when I went to svn up some code on my site and it all died. My version of SVN was too old.

svn --version was coming back as 1.4.4 and I knew that was wrong. I complained on Twitter, and Eric Hitter pointed out that Xcode has SVN (and Git) so I went and installed that. It didn’t work, I was still stuck on 1.4.4.

After checking that, indeed, svn was located at /Applications/Xcode.app/Contents/Developer/usr/bin/svn, and that ran the right version, I deleted 1.4.4 manually by removing the following folders:
```
/opt/subversion
/usr/local/bin/svn*
/Library/Receipts/Subversion*
```
Then I made a fast alias ln -s /Applications/Xcode.app/Contents/Developer/usr/bin/svn svn over in /usr/local/bin/ to redirect my scripts, and finally I followed the directions from Panic to fix Coda, and changed the Subversion tool path setting in the Files pane of Coda’s Preferences to /Applications/Xcode.app/Contents/Developer/usr/bin/svn. I also changed git to /Applications/Xcode.app/Contents/Developer/usr/bin/git and made a fast link for that too, since I can.

Have a happy weekend!
27 July, 2012
The Perception of Security

This post is dedicated to Frederick Townes, who donated to help me get to WCSF. I use his rock ’em sock ’em W3TC plugin on this site, as it happens.

The TSA is a funny thing. They make us go through all these hoops and ladders to make it look like we’re safer. They check us for weapons, they check us for bombs in our shoes, and essentially they check for everything they know about. And we call it ‘Security Theater’ because it actually doesn’t make us one inch safer.(If you’re really interested, go read Bruce Schenier‘s books. The security methods in place pre-9/11 are the ones that have caught the bad guys. None of the new stuff has.)

At work, I have a product from a vendor that has pretty insecure passwords. I can’t make them expire, I can’t make them require special characters. In fact, you can pick a blank password if you want. There’s no security and most people use the same password (123456) because of it. It was up to me to invent something more secure, and I sat and studied the login form for the app. This was a locked down product, so hooks and actions, like we use in web apps, were unknown. But there was a hidden option, down in the bowels of an ini file, that was for ‘advanced username options.’

Unlocking that option gave me rules for usernames, just like you’d think. But how is that going to make things safer? We already used login ids of our initials plus a number, so if I could leverage that somehow, maybe I could do something. My idea was that if the login name was always pre-filled, and uneditable, with the same ID you logged into the computer with, then in order to ‘hack’ into someone’s account, they would either need their LDAP password, or the person would leave their PC unlocked. I thought it was genius, and after some fiddling around, found how to extend the settings to allow that.

Months later, the Auditors come around and say it’s not secure enough. We need to change the passwords more often. Even though the desktop password is the most secure of all passwords we use, and even though leaving your PC unlocked is a fireable offense, they said that since someone could gain access to your PC, the bad password was a problem. I remarked that they had a lot more to worry about in that case, and pointed out the vendor didn’t have a fix. They’re still arguing that one.

The problem is the auditors want to be able to feel safer. They know and understand LDAP security, ergo all things must comply. It is a benchmark of safety which, in many cases, isn’t going to make things safer. If you got my LDAP password, you now have access to everything I log into at work. That isn’t safe at all, is it? It’s a single point of failure.

Recently, someone asked why WordPress doesn’t let you move the wp-admin folder around, and that doing so would be safer. Actually they accused WordPress of being egotistic for not letting you move the folder, and for putting meta info in the source code. But let’s not get into where they’re wrong on that end. Why doesn’t WordPress let you move wp-admin? Certainly they could put the effort into decoupling the various places where it’s hard coded, put in a define you could override, just like we do for wp-content. Then you could move it where ever and you’d be happy. I cannot speak for the developers, but looking at the code (not insurmountable, just annoying), I see it as security theater.

Moving the wp-admin folder simply cannot make your site safer. It just can’t. Look at it logically, you still have to be able to get the folder, ergo people will still be able to figure it out. The rule of the web has always been ‘If it’s on the web, people will take it.’ Normally this applies to pictures and text, but when we extrapolate it to include source code, like for open source code, which is there for the taking, we reach a point where anyone can look at WordPress’s code and determine how to quickly figure out where the admin folder has been moved to. We have now put in extra work for a very teeny tiny benefit, that can easily be circumvented.

But isn’t that benefit worth it? Not when you look at the costs. Computers do what we tell them to, every time, every day, repeatably. When we go in and complicate our code, we introduce more human errors. The more possibility for errors, the more likelihood that we’ve missed something. So by adding in a way to move wp-admin, we run the risk of screwing it up and making things less secure. Would you rather have the brains staring down WordPress and trying to make things actually more secure, like by preventing XSS vulnerabilities, or locking down nonces and cookies, or would you like them to make you feel better?

Furthermore, there are the themes and plugins to consider. Now we have to update all our themes and plugins that are doing_it_wrong() in the first place, and get them to join the new world order of right. Yes, they should have done things right in the first place, but some don’t because the old way still works. What happens when they don’t update? We’ll have to leave some deprecated code in there so the old wp-admin still works and … oh. Well that didn’t do you any good, now, did it?(NB. I’m certain there is a way to do this. I just don’t care enough to verify it, as you’ll see in a moment.)

This has everything to do with the fact that open source software is open source, and ‘hiding’ anything means it’s always going to be easily reverse un-hidden. Moving wp-admin is called ‘Security by Obscurity’ and it’s a waste of time. It’s just not effectual in the long run, it doesn’t protect anything, and the only time someone knowing my WP version or where it was installed would worry me is if I didn’t upgrade and there was a known hack on the older versions. Even then, Hackers will just try the same attack even if I’m protected (which I know from the TimThumb debacle, where my server was scanned for the file exploit – I don’t use timthumb, but they scanned me all the same).

When you make me draw the line between where I’d want ‘my’ developers spending time, and the options are ‘feel good security’ and ‘make the damn product actually more secure’ … I think you know where I stand.

What about you? What aspects of ‘security’ do you feel are just window dressing?

26 July, 2012
Forever Alone No More
A lot of us work on projects by ourselves. We’re the ones who build a website, alone. We write a plugin, again alone. When we do colaborate with others in the making of our site and codes, it’s often a cumbersome, kludgy, thing at best. The advent of code management systems like SVN and GIT make the actually coding process easier. Now multiple people can make changes, branch and fork, merge and combine to fix all sorts of problems.

But web-development, for your personal site, is still in the dark ages.

Here’s my workfolow:
- Review changes
- Open Coda2
- Edit file
- Preview changes
- Push file
Now that’s a huge improvement since the old days, when I would edit, FTP, and so on. I still use Transmit to run a sync/backup every day before I start editing any files, but that just goes back to my paranoia. It gets harder when you use something like WordPress, because the old days of being able to easily preview your site and how it looks doesn’t exist anymore. That’s part of why the totally incredible Theme Customizer is totally incredible.

It’s also a little problematic if you share a site. Let’s face it, maintaining a website with other people is a pain. When my fellow site-folk want a small change, they can make it, but I have no way to easily roll that back without comparing my personal backup with the new one, and go make a diff. Sure I can do it, but it takes time, and it’s a hassle. A lot of the time, too, my fellow admins aren’t as good at certain things (like CSS, or tables, or PHP) as I am, and I have to bail them out. In and of itself, that’s okay. It’s why they keep me around and fee me brownies, after all.

Have you ever had someone else make a change while you’re on vacation and call you in a panic, even though you’re on Bora Bora and have no internet, because this ‘one small tweak’ to the sidebar caused the site to go white, and they closed their file-editor, so they can’t control-z?

A lot of us cowboy code. I sure do. I’m often banging away on my sites in vi when I want to make a fast CSS change. Clearly sustainable for a professional environment, this is not.

But… What if? What if you had a way to update the code on your site, like your personal mu-plugins or the theme, and make the changes ‘live’ but still have a way to roll back when you accidentally blow it all up?

And what if I told you that a WP dedicated host has an answer. Yeah, WP Engine figured it out.

Upfront disclosure: I don’t use WP Engine. I have a lot of non-WP sites on my servers, and many of my sites aren’t using just WP. I have a VPS and I’m very happy with it. But if you want a good host to run your WordPress site that’s the step between your own VPS and WordPress.com, I strongly recommend them. Yes, it’s more expensive than many other hosts, but I am a firm believer in ‘You get what you pay for.’ With WP Engine you get hosting, upgrades, backups, and support for $30 a month. And now you also get Git. They’ve come up with a Git-push-to-deploy method for their hosting platform.

Did that sound like gobbledygook? Hang on. This actually isn’t something ‘new,’ as the technology’s been around for a while, but this is something new for webhosting and WordPress hosting. WP Engine’s applied it to their servers, making version control possible. It’s like how we’ve always combined version control and staging to make a ‘development platform’ and now you get that in WP.

Okay, if you’re like me, and a total raw rookie at Git, you sat here and went ‘What the hell is this ‘push to deploy’ stuff?’

At it’s heart, push-to-deploy and push-to-live is really a fancy, buzz-wordy way of saying this: I have a git branch that is the dedicated to my site version of my code. If I edit that branch by pushing my changes to it, I have created a version-controlled update of my site, which is beneficial in case you need to roll back a change, or pin-point a specific change.

Okay, maybe that’s still unclear. You’re going to have to take a look at git.wpengine.com to really see how they’re applying the technology. Git, like SVN, is one of those things that makes a lot more sense once you sit down and use it a few times.

Really, my biggest hurdle is always wrapping my head around git’s application of branches and merging and a decentralized database. It’s complex and powerful. Vincent Driessen wrote a brilliant explanation of a successful Git branching model, complete with diagrams, that explains all this way better than I could. His examples will show you exactly what’s going on, and that a ‘push to deploy’ is really just another sneaky way of using git to manage your changes in a controlled way.

Don’t get the wrong idea. There’s nothing wrong with being sneaky to control all this, when you get down to it! It’s the perfect-world a lot of teams have been looking for, for many years. Having this built into your webhost, so you don’t have to come up with your own solution, is going to be amazing for small companies that will, over time, have a slew of developers. Someone new comes along? Hand them your primer on naming conventions and merge rules, let them fetch the repository, and off they go. Everything is right there, as safe as your backups.

I can’t say if this will revolutionize things, but it’s a harbinger of change which web dev has sorely needed.

Check out WP Engine’s Git FAQ (where they explain all the nitty gritty about handling version control, so if you’re a nutjob like me and want to run aortic, you can), or just read their getting started guide. The directions are clear enough for a Git newbie like me to understand.

Unlike Capistrano or RAMP, this hasn’t been released outside of WP Engine, but that makes sense as it’s all homegrown and built to their servers. This should be interesting to watch how other WP (and non WP) managed hosts handle the next wave of support.

Related:
- WP Engine: Announcement
- WPCandy: WP Engine launches seamless integration with git
24 July, 2012
ZenPhoto and ColorBox
I use ZenPhoto for a gallery on a site that has a pretty hefty (gigs) gallery with many albums and subalbums. It’s too big for WordPress, in my experience, and so I picked up ZenPhoto as sort of the WP of the gallery world. Not knocking WP, it’s great for text, but sorting and organizing images are a hassle. The flip side to this is that getting straight directions on how to do anything in ZenPhoto makes me bang my head on the wall.

See, WordPress has a lot of people involved, so the forums are filled with people who’ve been there before. And these people come from a varied array of talents, so some are designers, some programers, and some users. This means the documentation, while lacking in many respects, is actually a pretty awesome display of crowd-sourcing when you compare it to other web apps. The worst part is there’s no perfect way to replicate this dynamic. ZenPhoto is still relatively young, even though it’s only a year younger than nine year old WordPress! MediaWiki (at 11) is older than both, but ‘behaves’ more like the middle child, if you really want to break your head on things.

It’s a lot to do with goals, and you can’t knock any one tool for the other. They have their places. I would never try to blog on MediaWiki, nor would I put a seriously hard-core gallery on WordPress. ZenPhoto has branched out into ZenPage, a simple CMS, but personally I’d rather see them optimize the hell out of their back end, which could use some UI love. Still, a lot of its simplicity is why I chose to use it instead of, say, Gallery or Coppermine.

But the help is still lacking, so today was a bit of a wrangling and head bashing.

What I want is, you’d think, straightforward: How do I edit the default theme of ZenPhoto to include ColorBox? If you ask this on the ZenPhoto forums, you get an understandably annoyed mod saying ‘This has been asked before.’ I feel for them, but as a mod and a user, I look at that and think ‘If people keep asking and you can’t give them a link to how to do it, something’s not right.’

The directions I found in the forums never worked, but it wasn’t long before I realized why. There were simple typos. So here’s how you can turn on ColorBox for ZenPhoto.

1. Activate the Plugin

This is a duh moment, but go Admin -> Plugins and check ColorBox. You do not need slideshow.

2. Make sure ColorBox is on for your theme

Go to Admin -> Options -> Plugins and click on ColorBox. Then find your theme and make sure that the pages you want to run ColorBox on are checked. I only wanted it to run on albums, so that’s all I checked.

3. Edit your theme

This is where everyone’s directions fell apart for me. Since I only want it on albums, I went to my default theme copy and set my image section to look like this:
```
        <div id="images">
        <?php while (next_image()): ?>
		<div class="image"><div class="imagethumb">
		<a href="<?php echo html_encode(getDefaultSizedImage());?>" rel="showcase" title="<?php echo getBareImageTitle();?>"><?php printImageThumb(getAnnotatedImageTitle()); ?></a>
		</div></div>
		<?php endwhile; ?>
```
Make special note of your classes and rel here! In specific, notice how that I have two divs for image and then imagethumb? While either one will work, I made a note of imagethumb, since it was a little more specific. Also I made a note of the rel in my image itself, in this case rel=”showcase”

Then back up before I close my head section, I added this:
```
	<script type="text/javascript">
	// 
	</script>
```
See how I’m using the showcase and the imagethumb? That’s why I needed those.

4. Customize

Everyone says ‘Read the directions!‘ but when you look at them, they’re written for people who know jQuery. I don’t. So when I don’t know what I’m doing, I make a list of what I want. By the way, yes, it irritates me when directions are ‘too techy.’ You can’t know where people are in their understanding of things, and you can’t expect everyone to be amazing at everything. I was very close to appealing to anyone who owed me a favor for help before the end of this.

No set height

That’s as easy as removing height:700 from my js.

Force colorbox to treat my cached image as an image

Just add photo:true to the js. I had to do this because my server renders the images via a php file (to redirect to cache) and this was causing funny problems. It’s a known issue, though, so one I figured out how to search for ‘ColorBox is making my images show up as gibberish!’ I found the answer.

Put a link to the full sized image

And here began my headache. If I put in this (where I used to have the height code):
```
title:function () { return "To view full size, " + "click here!".link(this.href);}
```
… then my link goes to the getDefaultSizedImage() size (which is a max width of 540px for my theme) and that isn’t what I want. I could change it to getFullImageURL(), but then colorbox loads the fullsized image, and that’s just a little silly and bad for bandwidth. I spent the next hour reading up on jQuery to understand that I really wanted to pass data through. Finally I struck about the notion that I could make a new variable in my href.
```
full=<?php echo html_encode(getFullImageURL()); ?>
```
This makes a link to the full-sized image. And then I changed this.href to $(this).attr('full')

In the end, it really wasn’t hard, but nowhere were all the pieces laid out in a way I understood. I’m happy with how it all turned out and the site now behaves like it’s 2012.
10 June, 2012
You Can’t Be Everything

There’s no app out there that does everything.

A lot of you just said ‘I know.’ but did you ever stop to think about why that’s the case? After all, some applications do everything you need them to do, and some you don’t, so who gets to decide what is and isn’t needed? When I talked about how WordPress was just fine on it’s own, without any plugins, people stepped up and said “But Ipstenu, I really need XYZ.” Heck, Lorelle said she needed Akismet.

Learning how to separate your personal needs from the needs of the masses, when writing software, is a full-time job, and many of us come at it from a slant-wise point of view. In fact, writing core code for WordPress is in diametric opposition to why we write plugins! While I’m going to talk about it from a WordPress point of view, the concept holds true to any application that has ‘add ons.’

Plugins are written, by in large, to solve a specific problem. They’re not ‘fixing’ WordPress, they’re expanding. Remember, your iPhone wasn’t broken until it had Angry Birds, nor was your iPad incomplete without Twitter. Those are things you wanted, and solved a problem for you. The base tools, in and of themselves, address a broader group of people, with a diverse set of needs, and have the option of being everything or nothing.

The best tool, WordPress, your computer, etc, are built to be extendable. They’re built with the innate knowledge that the users may want things they can’t forsee. Five years ago, how many of you thought Google+ or Twitter would be a ‘thing’? Let’s take that further. You know how when a new video game comes out, sometimes you can’t play it on your older computer? That’s because it wasn’t built with the new game in mind, so it’s just not capable. And that’s why computers generally let you upgrade memory, CPU, and hard drives. They are built to be extendable becuase they know they can’t know the future.

Bringing it back to WordPress, it was built to meet a need. People wanted to blog, they wanted it to be easy and they wanted it to just bloody work! So the Matts said ‘This is what we want’ and built it. Thankfully, they understood that people wanted to extend WordPress. But not at first. Oh you didn’t know? Back in December 2003, a ‘new feature’ was introduced called my-hacks.php, which let you put a file by that name in the root of WP, and it would treat it like a functions file. In fact, that’s why I call my non-plugin code ‘hacks.’ Heck, we didn’t get pretty permalinks until January 2004 (then called ‘cruft free’ URLs).

The point of this is not to expose the funny looking beginnings, but to demonstrate the nature of the software. As it grew, people had needs, and instead of writing everything into core, they cleverly changed WordPress so it was extendable and let people grow as they needed. So when we talk about things like needs and wants, we do it in the understanding that we write our software to fill a need, and we make add-ons to fill wants. Sounds like double speak, I know, but that’s why I said plugins and core development are in direct opposition.

When I want to add things to core, I want them to be useful to everyone, so I’m forced to remove my ego from the equation. Looking at the (few) core submissions I’ve made, I carefully thought them out beforehand. I looked at places were the user experience was inconsistent or diminished. When I make suggestions or offer commentary to what I think could be better, I try to show my passion without acting like a teenager’s first big crush, or a screaming fangirl meeting her heroes.

This isn’t to say I don’t think passion is a part of the driving force of any product, but that it must be tempered and controlled in things like WordPress core. We know that we can’t make WordPress core do everything, and we know we shouldn’t. When things are extendable, we utilize that and demonstrate our fire. When they’re difficult to extend, or kludgy to implement, we come back and say ‘You know, it would be nice if we could…’ But at the end of the day, when WordPress tags your trac ticket ‘wontfix,’ it’s because they know, being unable to be all things, that they must limit the things they are.

If you haven’t yet, take the time to read WordPress’s Philosophy.

When I usually talk about divorcing my ego from a project, what I mean is that I don’t let my passion cloud my better judgement. One of the lessons I’ve learned in nearly 20 years of active fandom is that when you love something, you get fired up about it, and you tend to view peoples opinions and actions as a personal attack when, in fact, they often aren’t. Yes, there are idiots and trolls and people who hate-monger, but in general, people actually aren’t dicks. They’re selfish and self-centered, but that’s just human nature. Part of designing a project means you have to let go of your personal attachment to your baby, and understand that haters are just gonna hate, and there’s nothing you can do about it.

This also applies to using a tool, though. People mock the evangelists, and we all hate the extremists, and certainly no one actually supports those who are outright malicious. But all those archtypes come part and parcel with a system, and are all aspects of the simple problem that no one product can do all the things. We want things to be a silver bullet, to fix everything we, personally, have a problem with, and we’re totally unrealistic in wanting that.

Mark and I were talking recently, and he pointed out that WordPress was once 230kb. It’s now 3.8megs, even zipped up. Part of this is because it all grew and became more, but if you ask the old-timers, some will complain that around the 1.5 days, WordPress just became too big. It does too much! And those people say we should pull things like the importer out of WordPress. After all, you’re going to use it once, if at all. Core plugins would get pretty big too. Jetpack is 2.4megs on its own, zipped up. By trying to be everything, maybe we’re making things a little worse.

So the next time someone gets their panties in a bunch at you for not doing everything, tell that it’s by design. Do what you want with your code, make it easily extendable for the next guy (or forkable), and carry on. They’re not getting that unicorn.

30 May, 2012

Tag: coding

Managed Themes Have A Place

Mountain Lion and SVN

The Perception of Security

Forever Alone No More

ZenPhoto and ColorBox

You Can’t Be Everything