Aside

I say this from time to time in conversation, thought I’d drop it here:

I love WordPress. I develop using it for my job and for my own projects, I write (occasionally) using it, and I suggest it as a tool for content-based websites all the time. I also hate it. If I thought WordPress was perfect just the way it is, I wouldn’t work on core. It’s the love that gets me through the ಠ_ಠ moments and drives me to want to see if I can do something about it beyond idle complaints. ∞

Why I don’t have a problem with Jetpack

Want that magical tl;dr? Jetpack is for users, not developers.

I don’t know if I’m madly in love with Jetpack, or if I’m ever madly in love with a plugin, but with all the negative things I see from the WordPress development community on a regular basis, and some genuine interest in this topic, I figured I’d write about why I don’t have a problem with it. To be honest, I roll my eyes a little bit when I see yet another round of abuse from my fellow developers. I use it, my husband uses it, WordPress.com uses it, and so long as I remember to be a user, it’s great. My frustrations, like many of those of others, only come when I start approaching it like a developer, much like how I get frustrated with my MacBook Air only when I realize that 4GB of RAM wasn’t, in fact, enough at all and I can’t replace/upgrade it myself. If I really want to care about that above all else, then maybe I better not be an Apple user

Jetpack is not made for developers, and I don’t think it pretends to be. With that line of thinking, I believe it’s just a bit silly of us to get all affronted as developers so long as it’s secure and the codebase continues to mature, just like with any other project. It’s the kind of plugin that’s made for people who almost don’t know what a plugin even is, and have no concept of what others mean or disagree when we throw out our beloved “plugin territory” line when looking for something they want their site to do. Try reading some feature requests on core Trac sometime, and those come from people who managed to figure out to come to Trac! Anyway, as I always say, these users just want it to “clicky-clicky-worky”. I think Jetpack does just that the vast majority of the time, and technical annoyance points like some new modules auto-activating or having to connect through a WordPress.com account are a part of that successful behavior. We’re a vocal minority, you guys, and we should recognize that.

Most users, especially ones just getting started with the web, have a pretty standard set of things that they want their site to do, and it’s smart to put those common desires together in a one-stop-plugin. If Jetpack claims to be for everybody ever, then maybe-probably I’d have a problem with that. I’d also be surprised if a plugin started claiming anything at all I don’t think Jetpack exists to make your life as a developer easier, and while I’m sure/know that there are myriad ways in which it could be better for developers, I think it does need to be recognized that there is a focus on user-facing features and that time spent by Automatticians tends to go there. Maybe we can get in the spirit of open source and contribute back as developers when we find pain points (especially those of us who have to use it in replicating an environment), or maybe we can expect more for free, or maybe I don’t know what, really.

Getting my more technical complaints out of the way just so nobody feels as though I am criticizing them for being a critic (because I’m not – criticism is healthy, even when I personally might think the volume a little silly): I think some parts of the UI could be better, I’m not a big fan of the consolidated top-level menu because I think users think about and look for labeling suggestive of the features as opposed to Jetpack as a bundle, I hate the slippy-slidy-earth-moving-hidden-UI method of deactivating a module just like everybody else does, and no, local development is not always easy, although there is a way for modules that don’t rely on a connected account.

For the record, I deal with Jetpack on local and restricted staging development environments just about every day, as it’s a part of how we set up to do .com VIP development, and find that there are often equal annoyances like dummy Twitter accounts for testing things that we’ve hooked in to, say, shortlink generation, whether or not we use a .com/Jetpack feature to tweet that link in the end. Or, I mean, oAuth, or SOAP, or lots of other things, especially in PHP. There’s always something annoying or difficult in development, Jetpack or no, and to me one plugin doesn’t deserve an exaggerated share of complaints. Complaints, sure, but it seems pretty lopsided, at least in the public arena, and especially from those who aren’t really forced to deal with it as a part of their client development. Yes, I hate that we don’t have a perfect replicated environment to develop on, and abuse it soundly in our IRC channel, but I do the same for anything we can’t exactly replicate internally and stab at blindly.

There are also things like plugin conflicts, which happen to everybody. I don’t think anybody can claim to have never written a plugin without a mistake or possible conflict, even people who ostensibly deal with WordPress all day every day. I know I can’t, have no idea if I could even test for conflicts against all 22,942 plugins in the .org repo as of this writing (my fault or not), and it would be ugly for me to judge the people (yes, they are people, and as far as I’ve met, wonderful people) who work on Jetpack as a part of their job at Automattic. If we want to point the Automattic-should-know-and-do-better finger, all I can say is that I don’t believe much in statements like that – the only thing I believe in is getting better via hard work and owning up to mistakes, which I find the team (is it a team?) does when actually communicated with rather than reading negative comments second-hand like we “accidentally” dropped a note we were passing in grade school. Developers are always going to have opinions, and it’s not an easy task to ignore what you may actually completely agree with as a fellow developer in favor of your true or proclaimed audience, and I would rather respect that focus while encouraging forward motion. Basically, I don’t want to bash; I want to suggest something that might be better, because that’s how I’d like to be treated. I’m also prone to telling people how I feel as directly and exactly as I can, so I think it can certainly be said that I am projecting some of my own personal preferences and personality here. I mean, it’s my blog!

Let’s take the Publicize module as an example of one that is on by default. There are all kinds of things that I find myself wishing it would or wouldn’t do, but those things I wish are things I’m only aware of because I’m specifically internet-tech-oriented and with other non-Jetpack integrations going on, like IFTTT tasks set up that sometimes create conflicts or feedback loops and my own YOURLS domain. So, maybe Publicize isn’t the feature for me, or I need to take the time to dig into its hooks for my own site, or discover that it doesn’t have hooks I need and find the right person to nag about it if I want to commit to my complaint. Complaining that it exists and is turned on (with nothing connected) is sort of like complaining that OSX ships with a color picker that no longer gives out hex values, minus the earlier-feature-that-got-taken-away part. Yes, it’s lame if that’s what you need a color picker for, and complain away, but there are better and more appropriate tools out there if you really have that specific need and as a power user, I’m perfectly happy to use them instead because it’s just plain better for what I need. It’s easy enough to not open the application, or in the case of Jetpack, either not authenticate anything or turn off that module (slippy-slidy-earth-moving-hidden-UI notwithstanding).

So what does Publicize do for your clicky-clicky-worky user? The biggest benefit I see, besides the whole broadcasting thing, is that it removes the intermediary step of setting up oAuth applications. I’m a developer, and I find that setup stuff almost impossibly confusing, especially on Facebook with all those Open Graph actions and whatnot. Have you tried setting up the Facebook plugin? Does it do what you want even when you make it past those hurdles? It didn’t for me or, perhaps more likely, I missed a hurdle. (Otto, I miss Simple Facebook Connect, even though I understand.) When it comes to Twitter, maybe it’s not completely true just yet, but as their API becomes more and more locked down and difficult to access, somehow I get the feeling that authenticating through .com may just come in handy.

Jetpack commenting, which some may know as Highlander from .com development, did not come turned on by default, but got its own share of abuse for routing through a .com site. I have no idea if it still does it, and to be honest, I’m not sure it bothered me even conceptually. If you’re noticing things like a redirect, then it should probably also be pretty clear to you that something external is happening to make social media logins and email notifications work out of the box. Social media login integration is approximately negative 17% fun, and potentially voluminous email across an unknown and crazy wide assortment of hosting environments is perhaps even less fun. Again, I’m not coming down on anybody for being concerned about the external routing, because I understand, but I think this is a case where it’s also pretty easy to understand why it works that way and to use something else if it is a deal-breaker or otherwise particular concern of yours. If it doesn’t do that routing anymore (seems unlikely), or it’s less noticeable, then great! They iterated and made it better. How much more can you really ask for, especially as a hopefully-empathetic developer?

As I’m trying to come up with a conclusion to this rambling post, I find myself worried that vocal critics are going to feel as though I am turning around and criticizing them. I’m really not trying to, I promise. I’m a huge critic, both of the thing that I work on the most and of myself. After all, why would you commit to working on WordPress itself if you didn’t want it to be SO much better slash hate it just a bit? What would my everyday motivation be if I didn’t constantly think I could be and do better? In any case, I find all the different perspectives quite interesting, and as somebody who has no interest in creating the next Jetpack, have no real desire to be loudly judgmental, as I don’t envy the task. I just feel it’s important to consider perspective. In this case, it’s the perspective of the clicky-clicky-worky user that matters the most, and I think in that regard, the only problems to have with Jetpack are those of when a feature is actually broken or perhaps being impatient to see what it will do next.

Can markup and CSS be backwards compatible?

Backwards compatibility, or back-compat, is a big part of what is taken into consideration in WordPress development, especially when it comes to core itself. It can be time consuming, and some consider it wasteful, but I would venture to say that it’s this dedication to preventing things like fatal errors on upgrades that helps WordPress be as widespread as it is. I know that when I started playing with self-hosted software on the web, I would never have chosen something that required manual updates and/or made it clear that if I chose to update I was absorbing all the risk, and I generally imagine that I’m not alone in something that I think or feel.

One of the things I’ve been thinking about recently is how back-compat works when it comes to my core comfort zone of UI, particularly markup and CSS. Within the WordPress admin, there is quite a bit of markup and CSS that derives from things that are added via API. Metaboxes are a prime example – you use the add_meta_box() function, and the containing markup is generated for you, with your callback function dictating the contents and markup of what appears inside the metabox itself. But what happens when somebody wants to use the current markup in the admin outside of that function, nevermind the reason why? Well, they grab it, copy-paste it into whatever they’re doing, and just like that it will utilize the existing CSS. I mean, it doesn’t sound like a tragic idea. But then, if/when we change the add_meta_box() function and the markup, or even the markup that surrounds a given metabox area, it breaks. So, developers understandably come asking questions, and fortunately are often understanding, but it’s frustrating for everybody involved. It sucks to have something just break, and it sucks to have caused it.

There are also areas where the API does not generate any sort of standardized markup as a wrapper – add_menu_page() is one of them. You provide a callback function, such as with add_meta_box(), but to get your admin page looking like the rest of the WordPress admin, you end up with this as a starting point (as of this writing):

function my_custom_page_callback(){
?>
<div class="wrap">
	<?php
		screen_icon();
		// won't show anything without adding CSS to specify the image if it's a top level menu!
	?>
	<h2>Test Title</h2>
	<p>Admin Page Test</p>
</div>
<?php
}

I think this poses a bit of a barrier to creating a basic admin page that provides a seamless user experience, and sort of undermines any wondering/complaining one might do about why developers don’t integrate their custom additions into the WordPress admin UI. It also means that if we change the structure of admin pages in the future, everybody who’s written a custom menu page will be left scrambling to make it match again. Luckily, in this case it’s not really ugly or non-semantic markup, so we may not have to worry about the “what if” of changing it, but it still begs the question.

Let’s say I were to advocate for having add_menu_page() output that typical wrapping markup (completely hypothetical, if you please). Well, I’d have to advocate for it being able to output that markup, not just doing it, and that ability to output the markup would have to be off by default for, you guessed it: backwards compatibility. It would be super bad to have a function suddenly start outputting markup that a plugin or theme author has probably already added themselves. But, that also means that developers have to turn something on rather than getting default good treatment. Would it have to stay that way forever? Could we ever have it become a default or will it remain tied to a legacy? I would not advocate for it being enforced, as the possibility of an admin page not needing some of the markup is there and should not be disallowed.

The other thing we have to worry about is just generally re-styling things. The thing I think WordPress’s giant admin stylesheet is most missing (besides sanity) is the providing and self-usage of what I refer to as reusable components – that is, provisions for form styling, a structural grid, etc. that can and should also be used by a developer adding on to the admin. Ideally, if we were to restyle something, anybody using the appropriate markup/classes wouldn’t have to do much of anything to stay integrated in the UI. As various admin UIs are added or revamped, we are certainly doing a much better job of heading in the direction of components (see: new buttons), but the legacy of what exists remains, and it can be very difficult to remove or rename anything. It’s also extremely time consuming to test possibilities and do things like search through the plugin repo to see who’s doing what.

In 3.5, Koop and I contemplated just adding the .wp-admin class to the media modal so that buttons could be scoped in when used on the front end and not impact themes. Too bad we found things like .wp-admin { margin-top: 0 }, or even better, JS that was using the .wp-admin class to detect whether or not it was being used in the admin without further specifying that it should be on the body element, as it is in the admin. Here again, we are talking about things that are not good practice, or even just straight up bad practice, but can we really go that route if it has side effects that are not the end user’s fault? Probably not. So we chose to add .wp-core-ui to places as a scope helper instead, and now I get to worry about usage/abuse of that class beyond its intention of scoping and declaring that the contained markup uses WordPress core styling, like the media modal or wp_editor() on the front end.

So, what happens if we just start removing CSS that core no longer uses and is not component-related? Do we move it to a back-compat CSS file and advise developers to enqueue it if they find it necessary? How ugly would THAT file get, and how quickly? When does something get retired from that file, or does it? Maybe it would just stay there forever, like deprecated.php, except that the size of a CSS file does impact the end user.

Also unlike PHP, we can’t designate markup or CSS as being internal/private use only. So long as it exists, it’s fair game for use. But, does that mean we’re now beholden to supporting these non-core but obviously currently working additions? Are we going to drive people away from building on WordPress if our answer is always “well you shouldn’t be doing that in the first place”, especially when we don’t (and perhaps can’t) explicitly say “don’t use this markup/ID/class”? What do projects like Bootstrap or jQuery UI do when it comes to updates? What differences and difficulties are encountered because WordPress is distributed, self-installed software that can be infinitely extended in infinite combinations?

At this point, I have more questions than answers (if I have answers at all), and would love to hear any experiences or opinions people have or have had when it comes to their additions to the WordPress admin and keeping it looking and feeling smooth. Who knows what I personally can actually do about it, but I love thinking and learning, it is open source software, and WordPress is all about the community

Helen on WordPress: now on WordPress․com

I’m a lazy user. I tell people this all the time, but I’m not sure anybody believes me. I prefer it this way – in fact, I think it helps my perspective when working on/with WordPress, whether for clients or core itself.

In any case, I’ve been letting this blog (and comments) languish for, well, quite a while now. Some of it is that I’m being lazy, and some of it is that I don’t feel like taking care of a separate installation of WordPress. I do lots of little development things to my personal blog, but when it comes to just writing about what I’m doing with WordPress, I want something that “just works”. Enter: WordPress.com.

Last night I managed to snag helen.wordpress.com, which I am super excited about, and thought would be the perfect new managed home for this little blog. At Matt Mullenweg’s State of the Word 2012 at WCSF this year, I was surprised to see myself on a slide, and entertained to be referred to as just “Helen”. I joked at the time that I really should just be able to have helen.wordpress.com, and maybe should change everything I have to just using “helen” as a username, and will enjoy that at least the first part doesn’t have to be a joke anymore.

So, welcome to my new little on-WordPress home! I’m going to be messing with this here Custom Design upgrade they have, seeing how far I can customize the look with CSS and fonts, so don’t be surprised if things keep changing for a while. I am also making a promise that by reviving this blog, I will look through all these comments that are pending or unanswered, and do what most of them are asking me about: updating one of my plugins on WordPress.org. Here’s to more WordPress-ing!

Using Chosen for a replacement taxonomy metabox

If you’ve ever created many taxonomies for a post type, you know that the add/edit screen can get very unwieldy with all of those metaboxes, especially with hierarchical taxonomies. And then sometimes you have something that is a taxonomy but doesn’t need items added very often, especially in client work where there are often predetermined options that may occasionally be added to by the client, which can be done in the taxonomy’s admin screen.

This is where we can use Chosen, a JS plugin to make multi-selects much more user-friendly, and just so happens to blend right in to the WordPress admin. You can take multiple taxonomies and put them into a single metabox. It’s not limited to taxonomies, either – you can use it for post meta (custom fields) as well. I’ve used it to select taxonomy terms for which a post is “essential” – optgroups came in very handy there. I actually would love to see tag selection look and behave more like this in core, but there would be more work to be done for adding new terms.

The basic idea is that you enqueue the script and style on the appropriate admin page (NOT all admin pages) and then initialize the field(s) based on a class or ID. I usually just put the initialize right in the metabox itself, but you could always be clean and put it in the admin_head if you want. From there, you show all terms in the taxonomy in a select field (including empties) and use the nifty selected() function to show which ones are associated with the current post. When saving, it’s as easy as wp_set_post_terms() after the usual checks for nonce, etc. You’ll also want to hide the original taxonomy metabox(es) as well, of course.

Full Github Gist (updated July 10, 2012):

Continue reading →

The perks of contributing

Behold this glorious little section of the WordPress 3.3 credits page:

WordPress 3.3 Recent Rockstars

I’m never in anything for the recognition or glory, but I have to admit: this is pretty exciting. As of this writing, WordPress powers 15.7% of the top million websites and at least 22% of all new active websites in the US. That is a mind-blowing number of times that the faces and names on the credits page might be seen, even given that it’s buried a little in the admin.

In 3.2 I was among the list of names under Core Contributors, which was more than enough for me, but this is kind of like a promotion for me in the (very awesome) WordPress community. I get a little bit of community time within my job at 10up and have been meeting some really cool people, like Chexee, above. I’m extremely busy these days, between continuing to play piano (performance in a week!) and all this work, but I feel very satisfied. I’ve been doing a lot with UI bits; notable in this release is semi-responsive work on the themes screens and the About/post-Update page. I also did a fair bit of color scheme, RTL, and IE work toward the end, as they tend to get neglected. That said, I love front-end and UI work, but being more of a developer than a designer, I feel like it’s important to both learn and contribute as much as possible in all ways, so I’m continuing to dive into the WordPress codebase as a whole and get more confident tracing and patching things. I also find myself helping out in IRC or the forums here and there and do a little bit of ticket watching and cleanup on Trac. Speaking of Trac… once 3.3 gets out the door, I need to start hassling somebody about whether or not that little reskinning project of mine is going to go anywhere.

Here’s to the imminent release of 3.3 and more amazing things in 3.4 and beyond! And here’s a full screenshot of the credits page (as of just now), because everybody involved deserves credit. Whenever you update to 3.3, make sure to check out http://yourdomain.com/wp-admin/credits.php. And please please please, do the update.

Blue Admin Bar 1.0

When we were making mockups for the refreshed admin bar in 3.3, I created a blue version to mix things up and ended up really liking it (yes, this line appears in the plugin’s readme). So, I decided to make a plugin for it for you all to enjoy that has slightly different versions for 3.3 (currently in beta) and pre-3.3 versions with the admin bar. I am currently using it on my local development sites so that I know where I am, but it’s also really pretty with the blue admin theme. I plan to add RTL support sometime in the near future.

Available in the WordPress plugin repository: http://wordpress.org/extend/plugins/blue-admin-bar/