Category: How It Is

Making philosophy about the why behind technical things.

Long Term Vision
Say what you will about Jetpack, the plugin serves a great purpose in a few major ways.
1. Once you register for the API, you never have to again.
2. Everything is easy to find to update and configure (Menu -> Jetpack).
3. New Features are added and you don’t need to install a new plugin.
Now look at something else. A company released over a dozen Facebook plugins. All the plugins required you to connect via their API (a separate connection in each). All the plugins required you to use their admin panel to set up a per-plugin configuration. All the plugins deleted those settings on deactivation. Or how about a WooCommerce related set of plugins that all required the use of their API (legitimately) but all the plugin did was connect you and send you to where that specific plugin part was configured?

Got that in your head? Good. Now what if Jetpack did that? What if to enable aspect of Jetpack you had to install Jetpack Stats, Jetpack Comment Form, Jetpack Subscriptions, etc etc etc.

You’d hate Jetpack. And worse, the Jetpack developers would too. They’d have to work extra hard to ensure all the suite of plugins conformed to style and protocol. Shared libraries? Gotta update them in all of the plugins. Oh and don’t forget to make sure they’re all backwards compatible in case someone updates one but not another. Figure out which one takes priority, make sure someone else’s changes on Stats doesn’t break Comment Form, and on and on and on.

There’s a reason Jetpack works as well as it does, and it’s not just because Automattic is behind it. Jetpack has one sign up, one registration, one setup for the connection. Each sub-app is toggled via Jetpack. New additions, when the main plugin is updated, are all easily checked for backcompat and everyone tests together before pushing out.

So why do I call this the long view?

Because the long view considers not just adding new users to your system, but keeping them in a way that makes them happy. The long view looks at the reality that your developers will leave. The long view thinks about the easiest way to maintain a lot of code. The long view makes sure that introducing old users to new things is easy.

And that means, the long view would look at your 15 or 20 plugins that all use the same ‘base library’ and tell you it’s a shitty plan. It’s more hours on more code with more potential conflicts. It’s less cross-code checking. It’s more testing. It’s more unit tests that have to be repeated over and over.

The biggest reason I see people argue that 18 plugins is better than 1 is ‘SEO.’ The quotes are there on purpose. Because it’s bullshit. Anyone who thinks 18 plugins will net you better SEO than one, well written, well curated document file on the master plugin has failed at SEO school and needs to meet Ted. Ted is a 12 inch lead pipe that the boss keeps in the top drawer of his desk at DreamHost. No, not really. But the point remains, they’re not an SEO Expert.

Content is king. Remember that? Duplicate content is bad.

However, in some cases, content is deliberately duplicated across domains in an attempt to manipulate search engine rankings or win more traffic. Deceptive practices like this can result in a poor user experience, when a visitor sees substantially the same content repeated within a set of search results.

That applies to your code too. Duplicate code, duplicate functionality, is bad.

Now there is always a time and a place for multiple separate plugins. I only want to use Easy Digital Downloads extension for Stripe, not any other payment gateway. So I don’t need the extra plugins in a ‘payment gateway suite.’ But there, EDD cleverly has all the base code in their plugin and the add-ons just enable more features. Yoast’s Video SEO is similarly an add-on. They didn’t waste time making a dupe of their main SEO plugin just to add in videos.

I hope the point is made. You can make your code simpler, easier to maintain, and easier for your users to find the new things if you keep it all in one. And that is a win.
1 August, 2016
Balancing Information and Monetization
One of the many ways in which newspapers are failing online is in monetization. We have very few options, when you get down to it.
1. Ads
2. Subscriptions
3. Donations
No company can really survive off donations, so the question really becomes how do we balance ads and subscriptions? Many newspapers have tried the simple tracking method of allowing people to read X number of articles before informing the reader they have to pay. Others throw up splash ads before the article is posted. And another one shows only some of the article before requiring registration.

They’re all problematic.

Users ignore the ads, they don’t register, and they walk away instead of reading. The issue for the user is that they want as few barriers as possible between themselves and the news. They want to pick an article, click the link, and read. To be inundated with ads and signup popups is annoying, and I suspect the attrition rate is abysmal.

This only gets worse when ads get ‘clever’ and make it hard to find the X to click out and get away from them. They trick users into clicking the wrong thing, which only annoys them more. Plus ads can slow things down on mobile, which is increasingly the way for things to go.

Recently I caught myself thinking that one way to encourage registrations in WordPress would be to have the post content ‘disappear’ after X days, unless the user was a member. Of course, that wouldn’t work for all sites, as not everyone wants to register on People.com. Also the old, archival news on The New York Times are things that really only the deep diving researchers (and weird net denizens) are after. Considering we can all go to the library and look everything old up on Microfiche, why do we have to pay for everything old?

So what should be limited?

How about we start with that cesspool of the internet: Comments. This is a double edged sword. If you allow open comments on a news site, consider requiring registration for them. This will allow you to more easily track and ban assholes. Sure, they can make new accounts, but in doing so you can follow them and block them. A win for everyone. Also you can track people who false-report bad people. Spam catchers will stop most bots from signing up at all.

In addition, you can turn off comments for older posts to non-paying users. After 45 days, only paid up members can comment. And make sure you don’t offer refunds if the guidelines are violated. If haters are gonna hate, make ’em pay for it.

Aaron Jorbin – Haters Gonna Hate (by Helen)

As for what content to restrict, it has to be more granular than just time. Take an election year. All articles about Hillary Clinton and Donald Trump should be readable. But read-only. No comments on any of them. Be realistic. Someone famous dies? Unlock all their posts so everyone can read all about them. The Olympics should have historical, important, events unlocked, but at the same time you don’t need every little detail.

This would be a tremendous amount of work, don’t get me wrong, but the days of assuming the internet is free money are long over. If we want people to pay us for content, we have to make it worthwhile.
29 July, 2016
The Need for Mobile Speed
I took the train from NYC to Montreal, which I will never do again. It was too long, too uncomfortable, and customs actually made the TSA preferable. But while you ponder that in your back brain, I want you to consider this as well. The internet on the train sucks.

For the first time in years I was back on pre-smartphone speeds. And the problem with that is I was in a world that expected 3G or faster speeds. Here’s what would not load:
- Twitter
- Facebook
- Tumblr
- Most news webpages
- Anything with video
Here’s what I could do:
- Text
That was a pretty shitty smartphone experience. As I sat on the train, I wondered why it was so shitty. Didn’t we build everything to be mobile first? Wasn’t the point of the responsive systems to make it faster? Turns out we didn’t.

One of the things we do well in the modern web is device detection. If I’m on a mobile device, everything’s cool and perfect and my sites will load for that device. There are PHP libraries like Mobile Detect and Detect Mobile Browsers], but what they’re really doing is device checks, not mobile. Knowing what kind of device someone’s on lets us customize a web experience to that device, and that’s all we tend to do. We put in the hours to check “Is this a mobile device?” but not where we should be.

Of course, that’s really hard to do. Apps like SpeedTest and TestMy.net work alright, but when you’re traveling by rail, your speed is incredibly variable and confusing. One minute I’d have 4 bars, the next 1, and then I’d drop from LTE to 3G and worse. Oh, and don’t bother asking about the WiFi. It was a joke.

Somewhat related, I travel a lot for work. I recently did a 12 day run to NYC and then Montreal, where I was in hotels most of the time. Hotel Wifi is a spotty thing. Either they charge you up to $40 a day for the privilege of their shiternet, or they give you free wifi that loads everything but images. Trying to work from hotels is a hit and miss proposition as well. I can connect, but as soon as I hop onto my VPN, everything drags.

Then we have conferences. I’ve yet to go to a tech conf where we didn’t kill the Wifi, or nearly so. While that’s kind of our faults for leaving on our various automated updaters and DropBoxes and the like, there isn’t a ‘Conference Wifi’ mode on laptops to say “Hey, I’m on a bandwidth so don’t do the automated background things please and thank you.” This is, by the way, why my presentations are always on my local box as well as online. I assume the wifi will die.

In all cases, as soon as the internet quality drops to slow, our experience online crumbles. We simply haven’t built most tools to work in a one-bar world. And much of this isn’t a solution we can easily grasp. Even the big guys, who have servers built for stress and speed, are slow in these situations. Because we assume too much. We assume minimum connectivity.

The race for faster wireless service is on, but we should step back and look at the simplification of our sites. If we can make a low-speed version that is as fully featured, we should.
27 July, 2016
WordPress Multisite: Block Site
This came up when I was looking at WordPress.com, where one has the freedom to post anything within their ToS, and I saw someone’s moronic blog about how specific people were evil. Pick whatever you want, it doesn’t matter except assume it was something offensive to a minority.

The Terms of Use says this:

In particular, make sure that none of the prohibited items (like spam, viruses, or serious threats of violence) appear on your website.

This was not a serious threat of violence, it was just ignorant, offensive, and stupid. I looked at the site and thought “What I want most in this moment is a big ass button to block this person from posting on my .com site, and to prevent them from ever being able to comment on any blog I own.”

It doesn’t exist. (I will note I found BuddyBlock but I have no idea how well that would work, and it’s for BuddyPress only.)

Part of the cool thing about WordPress Multisite is that you can run your own social network. With that power comes responsibility though. Users should be able to protect themselves while remaining on your network, allowing them to block other users they just don’t want to talk to.

So why don’t we? Well effective blocking is hard. As I mentioned in my post about how (most) contact forms fail at this, the biggest issue is people can just fake who they are are try again. This is a little harder on a Multisite, where a legitimate email and account can be required to comment, but by default all members of a network can comment on any blog on the network. This means we’re opening ourselves up to the potential to more abuse.

How would that big block work? There are a few approaches and I think the best route would be two fold.

Blocking Users

Everyone should have the ability to mute or block a user. As an end user, if I never want to see comments from John Smith again, I should be able to press ‘block.’ Then I would just see a note like [comment hidden] whenever I run into a comment from him on any blog on the network. On a non Multisite, I’d actually like to see that for any site that requires registration. Allow users to mute each other.

As an admin, if I block John Smith, then his comments are immediately discarded. If you wanted to get fancy, then you’d hide his comment from everyone who isn’t him, so he thinks he’s still talking to people and just being ignored. A silence mode. Use some JS so an admin has to click to expand and see what’s going on, so if John Smith is escalating, he can be banned.

That would be the other thing. Banning users from your sites on a Multisite should be totally possible. And on .com a way to report “User X keeps working around my blocks.” would help a lot.

Also for admins, perhaps they should be able to see “X people have blocked this user” on the Dashboard. That said, I can see a massive possibility for abuse with that. If John Smith was an admin of his own blog and saw ’10 people blocked you…’ it could cause problems. It would be trivial to hide it from the user, so you could never know how many people blocked you, but I can think of a few fast workarounds. Easiest is to add a second admin account to my own blog on the network and check.

Blocking Blogs

This is mostly an issue on WordPress.com, since it’s one of the few places I know of that has a ‘reader’ that shows you blogs that you might be interested in. That’s how I found the offending blog, by the way. A friend runs a religious blog on .com and the one we both found appalling was a recommended blog to her. I’ve already talked to some people behind the scenes of .com about that and how the algorithm may need some turning. But even if she had stumbled on to it via a search, should she not be able to say “Ew! Block!”

I would write it so that if someone clicked ‘block blog’ the following things happen:
1. The owner of the blog is blocked from commenting on any blog I own
2. The URL of the blog is placed on my blacklist
3. Optionally, all admins of the blog are added to my blacklist
Now I don’t have to see anything anymore.
18 July, 2016
Looking Back at MovableType

For the first time in years, I looked at Movable Type.

I walked away, like so many people, in May of 2004 when the restrictions and pay requirements were too much. I’d played with b2 before and WordPress, but that was when I fully moved to WordPress. While I’d remembered that the Open Source version had been fully restored in version 3.3, I forgot that when they released v6 in 2016, they ‘terminated’ the Open Source licensing option. Again.

In doing normal research of things, I ended up on MovableType.com, and was struck by how modern and out of date the site felt.

The site isn’t mobile friendly. Or at least not iPad friendly. It does this peculiar zoom in where the content is focused but it still has a sidebar. This means flicking down to read can causes my screen to wobble side to side as well. The zoom also didn’t work consistently, making me have to fix it over and over.

That said, it has a much nicer design and layout than I expected.

I have to say, that’s a much more modern front page than WordPress.org and less cartoony than the current WordPress.com pages. The same can’t be said of navigation, which was a little confusing. If you don’t know you have to purchase to download, seeing the Software License section without clarification is weird. That should be even more obvious, I think. I shouldn’t have to click on “Release Notes” and then see Install MT on the sidebar.

Once I ended up in the documentation, I poked around and had a laugh at the software requirements.

PHP 5.0 or higher (5.3 or higher is recommended)

Sounds familiar, doesn’t it?

The rest of the install direcrions are incredible weird and hands on. It has none of the simplicity I’ve come used to with WordPress. And please remember, I think that WordPress is far too complex for a new user, still, because WP’s NUX sucks. MT’s is worse.

What interested me the most is that, while you can’t get MT for less than $900, they have a public GitHub repo available.

Still, I didn’t install it. Instead I read the documentation to see what using it would look like, and was rather startling to read the author page on creating entries and see an interface that looked old.

It reminded me of WP 2.5. Which I guess is understandable since the documentation on how to import from WP to MT is very old. No, I’m serious, it has screenshots of what looks like WP 2.5 as their documentaion.

While I still think that MT lost out big time when they decided to separate from the Open Source community, their product doesn’t draw me in. It doesn’t look fun or nice to use, and that’s probably a reason it’s not as popular as it could be. The GitHub page has 22 contributors. WordPress 4.5, led by my coworker and friend Mike, had 298. Even the official, but not really used like that, WP GitHub repo has over 30 contributors.

I wonder how the web would have looked if Six Apart had never made the license changes.

I wonder would power 26% of the Internet in that world.

15 July, 2016
Not Mailbag: Where Contact Forms Fail

My friend Andy, reading last Friday’s post, remarked no one should have to put up with crap like that. He’s right, and I mentioned that most contact forms don’t allow you to filter via your WordPress blacklists or comment moderation settings.

Surprised?

You should be.

Back in March 2014, I raised this with Jetpack, saying that the Feedback ignores Blacklists.

You have a moderation list and a blacklist.

You have a user you want to block from commenting forever. You add them to the blacklist. Surprise! They can still use the feedback form!

This should behave just like the blacklist on comments: It blackholes them. Done and gone. After all, you didn’t want them around.

Logically I can see why it doesn’t use the comment checks. If you have a check to only let users who have an approved comment, leave more comments freely, this would be a problem. There’s no ‘pending’ value for feedback.

And the first reply … Well it made me mad back then. I say this as someone who is good friends with the fellow who commented, but back in 2014, I wanted to smack the back of his head.

This would be super easy to get around, just changed the alleged from email address. Besides, blacklist tends to be things that shouldn’t be displayed publicly automatically, allowing contacts would let them appeal the blacklist.

I could see grounds for adding a filter to have grunion follow the commenting blacklist though. Less sold on an admin option.

Now go back and read last week’s post. I have not blacklisted the rather vile word used in that comment because I have a friend who is dyslexic and often says ‘cuntry’ instead of ‘country.’ It’s an honest mistake on her part. We added in an autocorrect to her phone and tablet. But blocking short words is hard. Still. The IP address? You bet that hit my blacklist.

If I still had a comment form, that moron could still harass me.

As I replied to George:

Sure, and it’s just as easy to get around the current blacklists in WP. The point is, though, if you’ve put someone’s email on your comment blacklist, the assumption can be made that you have a good reason. You DON’T want this person commenting on your site, so why are you making it easy for them to harass you? And yeah, I used ‘harass’ intentionally.

Certainly I can and do block their emails on the server, but I still have to go in and clean out the messages in feedback once and a while, and I for one get a lot of pretty vile garbage from people. So having one less place to have to read their BS would be beneficial.

It’s always been relatively easy to work around if you’re a dedicated troll, but if the blacklist just blackholed their contact messages, it does a lot for your mental health.

Because he’s right that a dedicated asshole will work around the blacklists. They do it today. Still, I feel there’s no reason to make it easier for them. And while I can block from a server level, not everyone has my skills. And for those people, should we not introduce Akismet level scans on feedback forms?

You see, the reason I was mad at George back then is his argument felt like he was saying “since it can be worked around, this is a bad idea.”

That is absolutely not what he meant.

Even if I didn’t know George well, I have simple proof he didn’t think this was a stupid idea, he thought it was an idea that begat caution. What proof? He didn’t close the issue. In fact, he gave it a milestone to review.

Now, sadly, it’s been two years with no traction. Every so often someone bumps the milestone, which means it’s among the 600+ tickets that need attention. But it lingers. It’s not a priority.

Jetpack and Akismet are both owned by the same company. If you have the Akismet plugin installed and activated, and have an active subscription, every form submission will be checked for spam.

They need to take it to the next level. So do all forms plugins. From what I can tell, Ninja Forms has a field simple spam prevention but no blacklists. Gravity Forms has an old, not-updated, 3rd party plugin for a Gravity Forms Email Blacklist.

In fact … the only contact form plugin I could find that actually uses WordPress’ built in blacklist would be Takayuki-san’s Contact Form 7.

Let us protect ourselves from abuse.

8 July, 2016