George Stephanis

February 7, 2015

Frameworks: It’s dangerous to go alone.

Filed under: Coding, Javascript, jQuery, Ramblings — George Stephanis @ 9:22 pm

I get the feeling, quite often, that frameworks get the short end of the stick in the popular mindset.  You’ll often hear things like

  • “Yes, they’re useful for a beginner maybe, but if you’re a professional developer, you shouldn’t need them.”
  • “They’re sluggish.”
  • “They add bulk to a project.”
  • “You clearly haven’t optimized enough.”

Honestly, it’s a choice that needs to be made on a project by project base — both whether to use a framework, and how large of a framework to use.  Regardless of these choices, it’s never a question of whether you’ve optimized your project — it is a question of what you’ve chosen to optimize your project for.

As a case study for this question, let’s look at: Do you want to use jQuery (or some other established project — Prototype, Backbone, Underscore, React, whatever) in your project or not?

Well, if you do use jQuery, it can smooth over a lot of browser inconsistencies (most of which have nothing to do with old IE versions), and give you a more reliable output.  It can keep your code more readable, and more maintainable, as all of the browser fixes are bundled into jQuery itself!  Keep your version of jQuery current, and many future browser inconsistencies or changes in how browsers handle things will be handled for you.

If you want a lighter weight webpage, and you’re trying to optimize for faster performance, you may prefer to use vanilla javascript instead.  A friend of mine remarked on Twitter that he prefers to handle browser inconsistencies himself, because he can get faster performance:

The downside of this is that by optimizing so heavily for performance, it can make it far more difficult to maintain your project down the road.  When another developer picks up your project in a few months or a few years down the road, is the optimized code going to make sense?  Are your ‘code around’-s still going to work, and has someone (you?) been actively maintaining it (and all your other disparate projects) to account for new browser issues that have cropped up since?  If the application is expanded by a new developer, will they have the same level of experience as you, and properly handle cross-browser issues in the new code as well?

So, there’s always tradeoffs.  The final judgement will often depend on the sort of project and the sort of client or company that the project is for.

If you’re launching an Enterprise-level website, a HTML5 Game, or something that will have an active team of developers behind it, you may well find that it’s worth doing something custom for it.

If you’re an agency building client sites that — once launched — may get someone looking at them every few months for further work or maintenance … jQuery probably makes a lot more sense.  It will keep your code shorter and more readable, and if you keep jQuery up to date (which WordPress will do for you if you use its bundled version — and of course, keep WordPress updated) any future browser inconsistencies will be handled as well.

If you’re a freelancer or commercial theme/plugin vendor, using jQuery rather than something custom has always struck me as a common courtesy.  By using an established, documented library, you’re leaving the codebase in an understandable and tidy state for the next developer who has to step in and figure out what’s going on in order to make modifications down the road.

So in the end, the answer is always going to be that it depends.  The trade-offs that one project can make without a second thought may be inconceivable to thrust upon another.

January 31, 2015

Why Jetpack isn’t a Collection of Plugins, Part the First

Filed under: Coding, Jetpack, Plugin, Ramblings, WordPress — George Stephanis @ 12:14 am

In keeping with a previous post I’d made a couple months ago explaining the oft-discussed rationale of why we do things the way we do with Jetpack, I’ll be doing it again today, on a different — but related — topic.

I may as well make a series of it.

This is the first of two posts (in theory, I’ll remember to write the second) explaining why Jetpack is a big plugin with many features, rather than many individual plugins.  This post will be looking at the primary technical reason.  The abundance of other reasons will be in the subsequent post.  (So please don’t read this post and think it’s the only reason — it’s not)

tl;dr: Dependency management sucks.

Jetpack, as you may be aware, is structured as a bunch of modules.  Many — but not all — require a connection to WordPress.com to function.  This isn’t for vanity purposes, it’s because they actually leverage the WordPress.com server infrastructure to do things harder, better, faster, stronger than a $5/month shared host is capable of.  To do that, they need to be able to communicate securely with WordPress.com, and WordPress.com must be able to communicate securely back to your site.

Some of the modules that require a connection are things such as Publicize (which uses the WordPress.com API keys to publicize to assorted third-party systems, rather than making users register various developer accounts and get their own API keys), Related Posts (which syncs some content up to the WordPress.com servers and indexes it on a large ElasticSearch index more efficiently and accurately than could be done in a MySQL database), Monitor (which pings your site every five minutes and emails you if it’s down), Comments (which passes data back and forth behind the scenes to enable secure third-party comment authentication) — you get the idea.

We could bundle the connection library with each individual plugin.  However, we’d need to make sure it was namespaced correctly so each different plugin can use its own correctly versioned instance of the connection classes.  Which would then mean a user could have well over a dozen copies and different versions of the same connection class active at a given time.  Which will make things more difficult with respect to developing the plugins, as you can’t assume methods in one are necessarily in another.  And when you make a change in the master class, you need to scan each repository to make sure you’re not breaking anything there, and keep changes synced to well over a dozen repositories.  But I digress.

To avoid duplicate code, the modules that depend on talking back and forth with WordPress.com all use a common library that handles signing and verifying requests, API calls, and the like.

Because it’s all packaged in a single plugin, we can be sure that it’s all running the required version.  If Publicize needs a change in the core connection library, we can be sure that the version of the connection library in Jetpack has those changes.  If the core connection library needs to change structure, we can make sure that any modules that used the old methods are updated to run the new ones instead.  Everything is maintained so that it’s running smoothly and works properly with each other.

Now, if Likes, Single Sign On, After the Deadline, Post by Email and others were their own plugins, and connected to a separate Jetpack Core plugin, versioning gets tricky.  It could work, in theory, if every plugin is kept up to date, always and forever.  But the instant that the user is using, say, an outdated version of Subscriptions with an outdated Jetpack Core (which work perfectly together), and then installs the up-to-date WP.me Shortlinks plugin, things could break because WP.me Shortlinks expects a more up-to-date Jetpack Core.  So you go ahead and update Jetpack Core to current, but now Subscriptions — which used to work perfectly — now breaks because there was a method change in Jetpack Core, that is fixed in the up-to-date version of Subscriptions, but the user isn’t running the up-to-date version.  Horrible UX.

Plus, if the user doesn’t have any Jetpack stuff, the installation flow for their first Jetpack Plugin that needs the core would be something like this:

  1. Install Stats.
  2. Activate Stats.
  3. Get error saying you need Jetpack Core for Stats to function.
  4. WTF is Jetpack Core? I just want Stats!
  5. Okay, install Jetpack Core.
  6. Activate Jetpack Core.
  7. Wait, what was I doing?
  8. Stats!  Okay, right.
  9. Connect the Jetpack Core to WordPress.com.
  10. Drink Scotch in celebration.

Compare this to the status quo of:

  1. Install Jetpack.
  2. Activate Jetpack.
  3. Connect Jetpack to WordPress.com.
  4. Stats is already active (unless you’re Mark Jaquith, in which case you activate it in this step)
  5. Drink Scotch in celebration.

As I said, dependency management is hard, and there’s not really a good way to manage it in WordPress.  There have been some very worthwhile attempts made, but none that can have a sufficiently solid user experience for an average user to compare with our current system and flow.

Any questions or suggestions about dependency management and Jetpack? Ask away!

October 16, 2014

Better handling of RTL stylesheets in plugins and themes

Filed under: Coding, Plugin, WordPress — Tags: , , , — George Stephanis @ 10:14 am

Or, How I Learned To Stop Worrying and Let Core Do The Work For Me.


If you’ve ever done something like this, we should have a little chat:

if ( is_rtl() ) {
	wp_register_style( 'example', plugins_url( "css/example-rtl.css", __FILE__ ) );
} else {
	wp_register_style( 'example', plugins_url( "css/example.css", __FILE__ ) );
}
wp_enqueue_style( 'example' );

Now, don’t worry. I’ve done it too! It’s not that big of a deal. But there is a better, tidier way. Just compare the above code blurb to this:

wp_register_style( 'example', plugins_url( "css/example.css", __FILE__ ), array(), '1.0' );
wp_style_add_data( 'example', 'rtl', 'replace' );
wp_enqueue_style( 'example' );

which will output something like this in rtl locales:

<link rel='stylesheet' id='example-rtl-css' href='http://domain.com/path/to/css/example-rtl.css' type='text/css' media='all' />

Simpler, right? It reads more easily, and as an added bonus, if something is to toggle RTL after you’ve registered the path to the asset, it handles it gracefully! As it doesn’t determine which asset path to serve up until it’s actually outputting the tag.

Now, this is assuming that your rtl stylesheet is just a replacement for your normal stylesheet. Which most are — it could be automatically generated with some tool like CSSJanus or CSS-Flip. But if you’ve got an add-on css file, that you want to load in addition that just contains overrides for RTL languages, you can handle that just as easily!

wp_register_style( 'example', plugins_url( "css/example.css", __FILE__ ), array(), '1.0' );
wp_style_add_data( 'example', 'rtl', 'addon' );
wp_enqueue_style( 'example' );

which will output something like this in rtl locales:

<link rel='stylesheet' id='example-css' href='http://domain.com/path/to/css/example.css' type='text/css' media='all' />
<link rel='stylesheet' id='example-rtl-css' href='http://domain.com/path/to/css/example-rtl.css' type='text/css' media='all' />

For the curious as to how Core actually does it, read here:

https://github.com/WordPress/WordPress/blob/809baf442b/wp-includes/class.wp-styles.php#L88-L104

Detailed explanation (with bonus examples for handling minified versions of both regular and rtl css as well):

/**
 * If you're supplying a pre-minified version of the stylesheet, you'll
 * need this, and to add the `suffix` data, so that core knows to
 * replace `example-min.css` with `example-rtl-min.css` -- handling
 * the suffix properly.
 */
$min = ( defined( 'SCRIPT_DEBUG' ) && SCRIPT_DEBUG ) ? '' : '.min';

/**
 * The normal registration. You're familiar with this already.
 */
wp_register_style( 'example', plugins_url( "css/example{$min}.css", __FILE__ ), array(), '1.0' );

/**
 * I set the value to 'replace', so it will replace the normal css file if rtl,
 * but it could also be 'addon' for a css file that just gets enqueued as
 * well, rather than replacing the normal one.
 */
wp_style_add_data( 'example', 'rtl', 'replace' );

/**
 * Finally, if we are replacing the existing file, and there's some sort of
 * suffix like `-min` as mentioned earlier, we need to let core know about
 * it, so that it can keep that suffix after the added `-rtl` that it's adding to
 * the path.
 */
wp_style_add_data( 'example', 'suffix', $min );

/**
 * Then we just enqueue it as we would normally!  If it's going to always
 * be enqueued regardless, we could just call `wp_enqueue_style()` rather
 * than `wp_register_style()` above.
 */
wp_enqueue_style( 'example' );

September 30, 2014

My daughter is adorable.

Filed under: Uncategorized — George Stephanis @ 3:17 pm

image

September 26, 2014

News Flash: The FBI doesn’t want you to encrypt your data.

Filed under: Ramblings, Security — Tags: , , — George Stephanis @ 8:55 am

So, yesterday FBI Director James B. Comey criticized Google and Apple for deploying encryption on smartphone operating systems that they wouldn’t be able to bypass, even when presented with a valid warrant by police. (source)

Does he not grasp that the reason people want this extra security is because of government surveillance overreach and secret warrants?  They’ve literally brought this upon themselves.  When you deny people their privacy in everyday things, they feel it necessary to go to further extents to maintain it.  Were it not for NSA overreach, lying before congress, secret FISA courts and the like, this recent push to encryption likely would never have happened.

So, well done. I’m personally delighted that folks are opting to encrypt things.  Thanks for giving them that push towards it by being something of an overly attached significant other.

nsa-memes-2

August 13, 2014

On Jetpack and Auto-Activating Modules

Filed under: Automattic, Coding, Jetpack, Plugin, Ramblings, WordPress — Tags: , — George Stephanis @ 11:56 am

Hopefully, this is the last time that I’ll have to answer this question.

Frankly, it’s been answered dozens of times before. Now, I’m hoping to use this as a canonical ‘Answer Link’ that I can refer people to.  I’ll keep up with comments, so if anyone would like to ask

So, why does Jetpack auto-activate features?

Well, to start off, I should probably clarify what we currently do on this. We don’t auto-activate every new module that comes in.

We never auto-activate features that affect the display or front-end of your site — or at least not unless a site administrator explicitly configures them to.

So, for example, something like Photon, which would swap all your content images to CDN-hosted versions, doesn’t auto-activate. Our comments system doesn’t auto-activate either, as that would swap out your native comment form. Our sharing buttons do, but they don’t display unless you take the time to drag down some sharing buttons to the output box under Settings > Sharing.

However, modules like Publicize, Widget Visibility, and the like — they just give you new tools that you can use, with no risk to affecting your everyday visitors. When users upgrade, we give them a notification of what just happened, and point out some new features we’ve built in that they may want to activate themselves.

One thing we’ve recently expanded on, perhaps six months ago, is a ‘plugin duplication list’, for lack of a better phrase. These aren’t plugins that have an actual code-based conflict with a module, they’re ones that may be … duplicating effort. Previously, we were just scanning for plugins that would output OG Meta Tags, and short-circuit our own provider. However, since Jetpack 2.6, which shipped in November 2013, we’re actually doing it via a filter for all modules. For example, if you’ve got Gravity Forms or Contact Form 7 installed and active, our internal Jetpack Contact Form won’t auto-activate. If you’ve got AddThis or ShareThis active, our sharing buttons module won’t even kick in.

Now, obviously, we can’t catch every single plugin that may be similar enough to one of our modules to give cause to negate auto-activation. So there’s a filter, `jetpack_get_default_modules`, that can be used in any plugin to cancel auto-activation on any module.


add_filter( 'jetpack_get_default_modules', 'my_jetpack_get_default_modules' );
function my_jetpack_get_default_modules( $modules ) {
    return array_diff( $modules, array( 'module-slug' ) );
}

But I don’t like auto-activation of new features!

Okay.

You’re totally allowed not to.

We’re going to continue using our discretion to auto-activate select modules by default, but if you’d like to turn it off permanently for yours or a client’s site, we’ve made it ridiculously easy to do.


add_filter( 'jetpack_get_default_modules', '__return_empty_array' );

That’s it.

We believe that judiciously enabling new features is a win for users, especially considering 1) how low-impact most features are when ‘active’ but not actually implemented by a site owner, 2) how awkward it is for a site owner to have to enable something twice — for example, enabling the Custom Post Formats bit, and then having to visit Settings > Writing in order to actually enable the Portfolio custom post type.

We’ve spoken to many, many users who find a default feature set convenient, and resent having to make a bunch of ‘decision points’ if they had to manually activate each and every module. Good software should run well out of the box. So we’ve set up the defaults as we have. Yes, some people disagree and are vocal about not wanting anything to auto-activate. That’s okay. We try to design for the majority, with the best user experience we can provide.

If you have clients, that you’d like to be active in the relationship with, and customize the Jetpack experience for — that’s terrific. You’re the type of people that we add bunches of filters for. We’re all about empowering you to override our decisions, we just prefer to keep the default user interface free of a thousand toggles.

Decisions, not options — no?

June 4, 2014

A sample of things to come

Filed under: Uncategorized — George Stephanis @ 12:19 am

George Stephanis:

Press This has a much needed refresh coming. Major, major props to Stephane Daury and Michael Arestad who have cranked out the bulk of the work thus far.

Originally posted on Press This Working Group for Core:

Old and busted: blogging a web page with a picture in WordPress, through the bundled Press This bookmarklet (7 steps, 9 if you include having to select some text for a meaningful description, and in-popup scrolling):

Upcoming new hotness: blogging the same page with a picture in WordPress, through our in-development Press This tool, in bookmarklet mode (2 steps):

:D

View original

May 22, 2014

Twitter oEmbed is Leaking Data

Filed under: Coding, Javascript, Security, WordPress — Tags: , — George Stephanis @ 11:50 am

oEmbeds are fun.  They make it easy to embed third-party content on your site, like tweets, status updates, videos, images, all sorts of stuff.

Unfortunately, to do this, third-party code gets injected into your page.  Don’t worry, this is by design, but it does mean that you should only oEmbed from reputable sites.  WordPress Core is very picky as to the providers that it chooses to accept as oEmbed sources.

Twitter is one of these oEmbed providers.  Here’s an example of an embedded tweet:

Neat, isn’t it?

Now, hover over my name.

See that little url that shows on the bottom left corner of your browser (probably)?  It probably looks just like http://twitter.com/daljo628!

Now, click it.  Don’t worry, I’ll wait.

Did the page you landed on have a bunch of extra cruft appended to the end of it?

Maybe it looked something like https://twitter.com/daljo628?original_referer=http%3A%2F%2Fstephanis.info%2F2014%2F05%2F22%2Ftwitter-oembed-is-leaking-data%2F&tw_i=469505591946129408&tw_p=tweetembed?

If you right-click and inspect the element, the URL is just what you expected! If you right-click and open in a new tab — same thing! But if you click normally and let it trigger a Javascript event, it modifies the link before your browser actually processes it.

After you’ve clicked on it normally once, you can come back and re-inspect it, to see that the URL on the link has now changed to the one with the referer data on it — they’re rewriting it inline and intentionally delaying it so when you first click, you wouldn’t realize that the data was being appended.

This can be a problem because some sites employ concealers for the referer http header (No, I didn’t misspell referrer) like href.li for example. By embedding this in a get parameter forcibly, it’s leaking data in a way very difficult to block, by taking advantage of the trust offered via accepting Twitter as an oEmbed provider.

April 22, 2014

One Year with Automattic

Filed under: Automattic, WordPress — George Stephanis @ 4:29 pm

Well, it’s that time.

One year ago today, I started full time at Automattic.

Best. Job. Ever.

I get to work with some of the most brilliant minds I’ve ever known, all of whom, in addition to co-workers, I am proud to call my friends.

I get to contribute to open source software, and still have free time in the evenings for my family.

Each team meetup, company-wide meetup, and WordCamp I attend feels more like a family reunion than a work function.

I have the privilege of leading the team that develops Jetpack, and the ability to improve the workflow and capabilities of millions of users, every day.

For all this, to all my colleagues friends at Automattic and in the WordPress community at large, thank you.

And by the way, we’re hiring.

April 5, 2014

The ABC’s of Travel for Techies

Filed under: Ramblings — George Stephanis @ 9:37 am

Always Be Charging.  A mantra that I held to long before I heard it codified in a catchy A-B-C slogan.

For me, it’s about efficiency.  If I’m sitting near a power outlet, and I have a cord handy, there’s not much of a reason to not plug in.  It’s there, I’m there, let’s top off.

Think about it this way — how often do you hit the critical low battery light on your devices when traveling, and think “Gah, life would be so much easier, if only I had an extra (10 minutes|20 minutes|hour) of battery life!” — well, you can!  Just charge, even when you don’t need it.

Sure, it’s a minor inconvenience to be tethered to an outlet instead of milling about with your phone, but even that can be negated with a travel battery.  The Anker Astro line has some terrific models to pick up, normally for under $50.  With a single Micro-USB cable, I can charge my tablet, my phone, my Karma wifi hotspot, and even HP’s Chromebook 11.

In the end, it’s a hedge.  Will it be needed?  Not every time, no.  But is the minor inconvenience of charging better than a major inconvenience of your battery dying on you?  Well, that’s up to you.

Older Posts »

The WordPress Classic Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 2,444 other followers

%d bloggers like this: