Author: Ipstenu (Mika Epstein)

It’s Not Beer It’s Homebrew
If you’re a rookie getting your hands around all this webdev stuff, and you’re on a Mac, you may have already come to a rude awakening when you find out that, for reasons unknown to man, Mac decided we didn’t need wget.

That’s how I was introduced to Homebrew.

I love wget, because it’s a super simple and fast way to download something. wget http://wordpress.org/latest.zip is the fastest way for me to download a zip, and I use it regularly. So one day, when deving code, I realized I needed a plugin. I went to wget it and got a horrible message.

-bash: wget: command not found

After searching around, I was about to download, compile, and install wget when a comment on StackExchange said “Try Homebrew.”

Everyone’s dersive comments aside about how ‘real’ programers don’t install packages (seriously people), I said to myself “Ipstenovich,” I said. Yes, I call myself that sometimes. “You use yum to install packages on your server because it’s easier and safer. Why wouldn’t you use the same thing here?” Over to http://brew.sh/ I went and stared at the installer command like a fish.
```
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```
The call ‘ruby -e’ means “run Ruby and tell it to call this URL externally…” And then it clearly was calling github for an installer. It’s tough to decide to trust a new program but after some serious banging around, I trust the Homebrew.

Once installed, which doesn’t take long at all, I ran the check brew doctor which told me a couple things:
1. I’d installed SVN and Git on my own (truth) so I needed to change my .profile (with directions how)
2. I had a half-baked attempt at installing ImageMagick that needed cleaning (with suggestions how)
3. I had MacPorts still in my /opt/ folder, that needed removing (with directions how)
4. I needed to install xcode command line tools (with directions how)
5. xQuartz was out of date
6. I hadn’t updated my brew list in a bajillion years
Most people won’t have that last one. I did once have an older install of Homebrew that I’d never really cleaned up. However the other ones took me about an hour to clean up properly, because I was watching Fargo (the movie) at the time. Once installed and set up, I was able to install wget and upgrade it. Ditto OpenSSL (because Heartbleed, you know). It’s great.

Homebrew is pre-1.0 which means there can and will be issues. Don’t panic, for most of what anyone needs, this is perfect. It’s also good at upgrading when you need to:

The little beer mug is awesome.

One of the nice things about Homebrew is that it doesn’t use (nor advocate the use of) sudo. This is really good for security and makes me feel much safer.

Go forth, rookies, and install Homebrew! It will make your development much happier!
21 May, 2014
Review: Sitespeed.io
Let’s get this part out of the way first…

Like most people, I have a suite of websites I check when I’m trying to figure out how well a site does with regards to speed. Google PageSpeed Insights, ySlow, GTMetrix (which does both), Pingdom Website Speed Test, Bytecheck… The list goes on and on. We want as many checks as possible in understanding what’s causing sites to be slow and what is not.

When I added in nginx I wanted to test everything again, and as I made my way down my list I thought “Isn’t there a way to do this and go make a coffee?”

Sitespeed.io analyzes my site while I make coffee. It’s Open Source. It’s forkable. It’s easy to install. Since I’m on a Mac, I used Homebrew (which I’ll post more about in two days) but you can git clone, or download the zip, however you like.

Once installed, you run a sitespeed.io call:
```
$ sitespeed.io -u https://halfelf.org
```
This takes a little but creates a folder off your home directory: ~sitespeed-result/halfelf.org/2014-05-14-14-59/ and in there will (eventually) be a lot of files including an index.html. That one you open up in the browser. The scan definitely takes longer than a sitespeed check, but it’s also more in-depth in the ways I always wanted from sitespeed. Also since it’s HTML, I can toss it online and share with people.

What I noted first was a ton of errors. Sad panda.
```
phantomjs[88651:507] CoreText performance note: Client called CTFontCreateWithName() using name "Open Sans" and got font with PostScript name "OpenSans". For best performance, only use PostScript names when calling this API.
```
It also had a lot of crashes, which was when I wondered if everything was on the right version. Again, checked in with Homebrew, upgraded phantom,js, and tried it again. This time no errors (yay!)

But then the process finished and I looked at my score. 81.

So I dug into the results and looked at first my home page.

You have 2 javascripts in the critical path and 8 stylesheets using 0 extra domains

[…]

This page has 8 external stylesheets. Try combining them into fewer requests.

And it showed me what those were. Weirdly, I saw WP was calling jquery on it’s own, as well as the JS I minified and compressed with mod_pagespeed. Interested, I checked three other sites on my server, and they all have the same issue. It blows my mind that no other tool had pointed that out before. The stylesheets I knew were from my fonts. While I minified them all, I did not combine them because it made my font-icons break. I upgraded mod_pagespeed for Apache 2.4 and haven’t looked at that since, so I tried it again indeed, it worked now.

I slowly worked my way down the list, noting things that I could easily fix. One thing that would ding me hard was my use of webfonts. Also not using a CDN still dinged me. Still, by using Sitespeed.io, I was able to see more exactly what was slowing my site down and why, and what I could sacrifice. Some things are going to be unavoidable (like “You are using an old version of JQuery: 1.11.0 …” ) and the multiple domains (google.com, wordpress.com, etc), but really the fact that I can narrow in with specific issues is perfect.

There are a whole mess of options, like I can take screenshots with each page, restrict the scan to specific pages (or exclude others), check in mobile, test in specific browsers (note: this is more complicated!), and much more.

So welcome, Sitespeed.io, you’re in my toolkit now!
19 May, 2014
Mailbag: I want to make WordPress.com

Justin is not the only person who’s asked me this one, and it boils down to “How do I run my own wp.com?”

I wouldn’t. It’s insane, and if you want just an inkling as to how frustrating it is, spend 8 hours a day, for 2 days, doing free support in the WordPress.com forums. That’s going to be your life. If you hate it, don’t do it. And more to the point … I don’t feel we need more generic ‘Anyone can host here.’ sites. The most successful modern one is Medium, which doesn’t give you a site like ‘ipstenu.medium.com’ but instead just share-posts everything. I’m personally not sold on the efficacy of it, but my point is I feel these gateway blogs are less and less necessary, the better we make WordPress software. We’re lowering the bar for people to own their own sites.

If IF I was going to consider it, I’d be looking at it from the aspect of a small group of people. For example “A network for small town newspapers.” I take care of the servers and code, they just write. That’s a smaller, niche, market, but also one that probably can’t afford VIP WordPress.com. You can always expand, after all.

But Justin actually has a security concern. Let me share in his own words:

I want to build a service like wp.com, blogger.com but with free and commercial themes and plugins. Drag and Drop themes (Headway, Ultimatum), plugins (Visual Composer). If my site is feature-loaded, people will come, is’t that right? But I wonder why people don’t use all those nice software to build better than those companies. I want to ask, is it because people can insert malicious codes in css and javascript code editors?

Yes and no.

Its not the malicious codes in CSS and JS, though that is a concern. WordPress.com has a CSS editor that you can pay extra for, and the question many people ask is “Why isn’t that free?” The issue isn’t with security, it’s support. Frankly, people who need (note the word ‘need’) a managed site like that generally haven’t a clue what they’re doing in CSS for design. They need those baked and locked themes because they’re not ready for the rest without a conscious choice and a monetary investment. You’re paying more for something, ergo it’s worth more.

But JavaScript? Well that would be security but also support. I certainly don’t want people messing with JS because it’s easier than CSS to break your site with it. Don’t believe me? Go look at everyone’s whose visual editors broke after upgrading to WordPress 3.9 because of plugins that don’t work well with the new JS settings in TinyMCE. Those are plugins, written presumably by people who know what they’re doing. And they broke.

Is there a security risk to letting people edit CSS? No.

Is there a security risk to letting people edit JS? Yes. And worse on Multisite (which is what WordPress.com is running) as that could break the entire network, not just one site. A bad CSS call will only break your own site on the network, after all.

But I think the question may be “What’s so dangerous about JS anyway?” and the answer there is “Cross Site Scripting” (aka XSS). XSS is a vulnerability that will allow hackers to inject scripts from their computer into your site, which is normally (in WP land) used to bypass the requirement to be logged in, dump garbage into the database, and then log in and create merry havoc on your site. I’ve been told up to 84% of all vulnerabilities in the web are XSS related. This may or may not include CSRF (Cross Site Request Forgery). The XSS article on Wikipedia is pretty good.

Based on that alone, I would not allow users to make their own javascript edits. I would perhaps provide plugins to allow them to make certain adjustments, but not anything they wanted, any time they wanted. If they need that, then they need to get their own hosting on their own server, so they only blow up themselves.

Oh and whatever you do, don’t try to become ‘the next…’ anything on your own. That way lies madness. Get some help.

16 May, 2014
All is Revealed
I had some issues with SEO Slides in the past, mostly around how it’s not quite what I need while also being more than I need and less. I banged around this for a while, before I remembered that I’ve seen a lot of people use WordPress for slides in a way that I never really loved, while others used something decidedly not WordPress.

Step back.

I don’t believe that I should use WordPress all the time just because I’m a WordPress person. I thought about what I want from my slides:
1. A way to load them locally or remotely
2. A way to control them and see my notes
3. Usable on mobile
4. Embed-able by me and me only
5. “SEO” friendly
That last one really means “HTML should be readable so a screen reader could make sense of it for the blind.” And that’s really the primary reason I ended up with SEO Slides to begin with. But when I stepped back to really think about what SEO Slides did, and what I needed, I realized that while I really do love it, it made it harder for me to make slides.

Let me explain. SEO Slides’ interface is not the WordPress post editor. I suspect, if it was, I’d be happy since I can mangle HTML there all day long. But SEO Slides doesn’t let you at the source code of the page, you have to use their GUI, and I was having a hell of a time with things like centering and floating and wrapping… All things I’m a boss at with HTML.

In addition, I’d recently discovered serious limitations with pageload, especially on mobile. The fixes in 1.5.0 didn’t fix it for me (actually it became worse with my slides taking over fifteen minutes to load, at which point I gave up). This is not to say I don’t love SEO Slides and what it does, it just didn’t fit my personal workflow. As much as I loved it when I did my EDD presentation for WP Sessions, I wasn’t satisfied.

So as I contemplated my vodka over Passover, I came to the possibility that maybe WordPress was totally overkill for slides. Maybe, like with a Gallery, it was too much and too complicated for something that should be more simple. To me, HTML is simple. It’s straight forward, direct, and I still use it every day. With the exception of paragraph tags, I wrote this post in HTML mode.

I did what comes naturally to me. I went and poked around what some of my friends have done (and kept up or not…) and finally decided that I was going to try out reveal.js.

Wow.

Installing was simple, just a git clone. And while the directions claimed you can’t use speaker notes unless it’s running locally, I found this not to be the case. Maybe it’s because I’m on Chrome, or maybe that’s not updated. Either way, it’s awesome for me since I can suddenly control my slide-deck on my laptop. Making my own slides was also pretty basic, I made a folder for each deck, tossed in the images and the index.html, and went to town. It’s really that easy to do, though I wish there was a basic, example, and not just the big one. Still, a search and replace of HTML is super fast.

It loads faster than SEO Slides, works better on my iPad, and the only thing I can’t do is embed. I’ll live. I’m also sure it can be done, since http://slides.com/ (the freeium version that hosts it for you) has an embed ability. The other massive gain is that it’s smaller. When you upload media to WordPress, you get multiple images, and I have to pre-load each page (or load it on the go). This gets heavy since I like background images and pretty things.

With reveal.js, I just upload one image and I’m done. It loads everything at once, since it’s one HTML page, and the image (while large) is just reused. And that was good enough for me. Also I get to use remotes.io to remote control my slides from my notes (I use the iPhone app Scan, by QR Code City, and paid for it because I hate ads).

I may go back to SEO Slides (who should consider an import from reveal… Hmmmm) but this works for me now. We’ll see if I love it in the long term. I suppose I should actually read stats and see if anyone but me even cares about the slides…
14 May, 2014
Mapping Domains Without a Plugin
Recently I wrote WordPress Murder Mystery. The day I released it, I got on a plane to fly to Miami, and proceeded to have a pretty awful travel day, thanks to a storm that pretty much knocked travel to the SouthEast out of commission. While I waited for my flight to DFW, I got pinged. “Hey, I can’t add anything from your store to my cart!”

I pulled up my laptop and thought about what I’d changed. Oh. I’d turned off domain mapping. But not really.

You see, I love the WordPress Domain Mapping plugin. But I’m not using it here. No, I’m actually doing something I expressly and patently tell people not to do … because time has changed with 3.9 and it’s almost okay to do things this way. The change here is that WordPress is smarter now, and it’s safer, and you actually can just edit the home and site URLs in the Network Dashboard. But you know how I said ‘almost’ back there? Your ability to shoot yourself in the foot is directly proportional to how smart you think you are.

What I did? It’s basic but assumes you already know how to add a domain onto another.
1. Go to Network Admin -> Sites
2. Edit the site in question
3. Change the URL to the mapped domain, check the ‘change home and site URL’ box, and click update
That was it! Three steps and everything still worked! This also let me force change a site to https all the way, and since I didn’t have content, I didn’t bother with a search/replace. If I had, I’d use that Interconnectit Script or WP-CLI for it. Still, like a wise person, I always get the domain ‘right’ before I add content.

And at this point, everything seemed to work just fine! And so I left it as is and published my book. And as you know, it all failed, spectacularly. I rolled everything back (because I knew what I’d changed last, see? always remember that!) and it worked again, so I knew I had to have missed something big here. Since I was stuck in an airport with choppy wifi, I disconnected everything and fired up my localhost version of my site. Banging on that for a while, I saw I missed a small, but hugely important factor in the plugin.

See most of what it does is that pretty interface to say “Pull domain.foo content from site #2 (aka foo.example.com)” and force redirects. It also lets you do cool things like “Allow users to log in from foo.example.com instead of domain.foo” but really I didn’t need any of that. The meat of the code is in the sunrise.php file, which when I studied, I realized was just doing the redirects “Send Site #2 to domain.foo” and for me, by renaming the home and siteURLs, I was already doing that.

So what had I missed?

define( 'COOKIE_DOMAIN', $_SERVER[ 'HTTP_HOST' ] );

That was it. I forgot to tell it “Cookies belong to the domain you’re on.” What this means is that if you log in at example.com, the cookie you get is for example.com and not domain.foo! For the most part, this isn’t a problem since no one logs in but me … until you try to make a purchase and it validates a cookie which doesn’t match the domain. I added that to my wp-config.php (down at the end of my Multisite section, where the SUNRISE define had been earlier) and everything magically worked.

Two lessons! First, test everything. Second, you can map domains without a plugin, safely.

I will note that, over time, it’s possible those settings for home and site URL may vanish from display. They’re powerful and dangerous settings, and you should not mess with them without a good backup.
12 May, 2014
Defaults Matter

We tout decicions and not options. We laud people who make it work, simply and efficiently. So how do we decide what the default decisions should be?

I was looking at a new plugin for an affiliate program, and it set up the links based on region. The way this plugin worked, if you don’t have an account specifically for that country, the plugin author had it set to use his ID if the user didn’t enter one. This is a small issue, in that the user may, unwittingly, be letting the dev earn money of their site. It’s also just not permitted. You don’t put up links or ads on someone else’s site without them checking a box to allow it, it’s gauche and against the .ORG guidelines.

Without knowing the issues of the affiliate app, I pushed back, and was surprised that the plugin dev was doing this because if he didn’t, the code would break. The affiliate program didn’t have a fallback to show a default location if you didn’t have an ID for that area, it just errored out. Thankfully, this developer and I worked out a solution. If there was no ID for the region, the plugin wouldn’t display the affiliate links. There was also a checkbox “Use the developer’s affiliate code in regions where you don’t have one!” that explained this would help feed and clothe the dev.

Another example. A plugin made a shortcode to play MP3s, and by default if you don’t have an MP3, it played one of him from his domain. Besides the fact that you’ll crash your server if you get popular enough, the fallback for that should be for the shortcode to output “Oh noes! No MP3 picked!”

This got me thinking about how we determine the defaults for anything. We pick what we want to support most, we guess at what people will use most, and we test what we can think of. But that isn’t easy at all. Start factoring in upgrades. You add a new feature and you want people to use it, so you turn it on to aid discovery (Jetpack does this). Not everyone likes that and gets mad that the first thing they have to do is disable it! So you think about alert boxes “Hey, you upgraded and there’s a new thing!” but then people hate dismissing those alerts.

Picking the right defaults for your intended audience matters. The affiliate code guy knew about an error if he didn’t do that, and compensated in a way that would be seamless for the users, but a little unethical (I felt) because it took advantage of their ignorance to make money for him. I’m kind of hip on educating the masses. The shortcode guy just didn’t think about the long-term ramifications. Neither actually meant to be harmful, but both were thinking about their users and their familiarity with things. Both were cognizant of the fact that a product not working because of incomplete settings should not break.

Determining your default settings is a race between education and simplification. It should be as simple and straightforward as possible to make things easier for the new users. At the same time, it should be made totally obvious in straightforward ways what the defaults can be changed to. This can be done with help screens in your plugins, but also in the welcome pages and the in-line explanations of setup. You can hide aspects of the code from users until they’ve finished pre-requisites.

Defaults are the one place where you have to actually try to know what the users will be thinking, so don’t worry if you get it wrong. You can always iterate.

9 May, 2014

Author: Ipstenu (Mika Epstein)

It’s Not Beer It’s Homebrew

Review: Sitespeed.io

Mailbag: I want to make WordPress.com

All is Revealed

Mapping Domains Without a Plugin

Defaults Matter