Tag: mailbag

Mailbag: Can I Track Issues with Github Like WP Support?

How do I see all my Github issues for all my projects?

I was asked this at a WordCamp by someone who had seen my ‘how to get into Github’ series with Carrie Dils.

If you’re tracking the WordPress forums, https://wordpress.org/support/view/plugin-committer/YOURID will list all of the support requests and reviews for any plugin you have commit access.

Not a comitter, just someone listed as an author? Use https://wordpress.org/support/view/plugin-contributor/YOURID

But Github? Turns out it’s super easy!

https://github.com/search?q=is%3Aissue+is%3Aopen+user%3AYOURNAME&type=Issues

Basically you can go to the Github Search Page and put inis:issue is:open user:ott42 and you’ll see them all! There’s no RSS feed mind you but you do get emails for all those so you should be okay.

29 January, 2016
Mailbag: Why Do Cannonical URLs Mess Me Up?

This came from a DreamHoster who said it was okay to blog it if I didn’t mention them by name. They were embarrassed about the mistake.

Why was my site having a redirect loop, and why did changing the domain to force www in panel fix it?

The ‘panel’ being mentioned here is DreamHost’s Panel. We don’t have cPanel, we have PANEL, and it’s our special, 100%, tool. In there, you can edit your domain settings. One of the settings has to do with your domain settings. Simply it asks “Do you want the www in your URL?”

In general I check “no” because I’m a no-www kind of person. I don’t like it.

The issue this person was faceing was that you’d go to http://www.wordpress.dev and everything was fine, but his site went all over the place weird when you went to

In order to fix that person’s website, I changed “Leave it alone” to “Add WWW” (their preference, not mine).

Why did that work? Let’s understand the issue first. What was happening was that your server generally doesn’t care if you visit http://www.wordpress.dev or http://wordpress.dev because it knows that they both mean /home/user/wordpress/public_html/ (or whatever). But! Some servers (like DreamHost) let you prioritize and redirect. If they don’t, you can use nginx/htaccess to force www or not. As far as the server cares, none of this matters. If you force no-www and someone goes to www, they get redirected and everyone’s happy.

Except WordPress. WordPress is picky. WordPress has special settings:

Recognize that? If you have WordPress set to use www and you go to the non-www URL, it won’t redirect you. It will, however, force all internal links and generated paths to have the www. The same thing happens if you don’t force https for your site. WordPress will still serve http://wordpress.dev but all the links on that page would be to https://wordpress.dev and so will your stylesheets and javascript.

This may make you think that WordPress doesn’t care. You’d be wrong. WordPress cares deeply, and it shows up when you go a URL like http://wordpress.dev/i-am-fake/ – assuming you don’t have a page named that. If you’ve forced www, WordPress will look for that page and do a 404 redirect. Suddenly you’ll have www!

Except in some cases, what happens is WordPress accepts the URL you gave it and shows without the www. Then it remembers it should have the www and redirects to that. Only it knows you told it non-www and redirects to that. And you get an endless 301 redirect loop. And you cry.

If you force www in DreamHost’s Panel and you force it in htaccess and you set it your settings, this still may not be enough! You may have to do a search and replace to change all the non-www urls to www!

Amusingly, when WordPress 4.4.1 dropped, we found a rare race condition with http and https and WooCommerce, born from a simple mistake.

Everyone I know who looked at that went “Oh, right, if my site has https in the home and site URLs, maybe I shouldn’t try to force http here!” But Woo lets you shoot yourself in the foot. Or at least they did. There’s a ticket open where I suggested perhaps they prevent that.

And for what it’s worth, I totally get how these things happen. You set up your domain and your WordPress site and your http/https settings at different times. It’s understandable that in 2013 you didn’t have SSL, but you added it in 2014. And at that time, you only put SSL on your checkout pages (right?) and since you wanted your cache to work better, you said “no https for checkout’ed!” That’s perfectly sane and logical. But since LetsEncrypt and HTTPS Everywhere became big in 2015, you changed the whole site over and simply forgot about that one, teensy, toggle…

At least, until someone got that horrible 301 redirect on checkout.

Like I told the people I fixed, don’t kick yourself over this. You have a lot of moving parts and the secret is understanding how each bit works. If you know that you set Panel properly, and .htaccess properly, and site/home URLs properly, and it only happens on checkout, you can zero in on what’s left and debug that.

22 January, 2016
Mailbag: Access and Security
In the midst of a longer set of forum posts about how to not have a plugin updated because you’ve made edits to the plugin, someone said that their issue was that the people on the site updated.

Now please don’t say that we should give them minimum privileges …

Actually. That’s precisely what I’m going to say.

1) Do not make anyone an admin whom you do not explicitly trust.

2) As the admin, test all plugins before updating.

3) If a plugin is constantly releasing unstable updates, stop using the plugin and look for alternatives.

3a) But make sure it’s not your theme or a conflict with another plugin first. It may be something else’s fault.

4) Stop editing plugins directly.

5) Treat every upgrade as a serious thing.

Now. I know why the guy doesn’t want to hear “You’re doing it wrong.” But the truth is this. If you give people who are irresponsible enough to update things the ability to update things, they’re gonna update things!

True story? On one of our company sites, one of the guys has access to update all the things. He did and broke the site. I jumped in, told him “Don’t do that, please, ask me next time.” and I fixed it. And then I went through everyone who had admin access and locked their accounts down to Editors. The exceptions were the people who legitimently needed that access.

And yes, WordPress needs more granular user roles/controls. I want that user to have access to administer all posts and add new users. I don’t want him anywhere near the plugins and themes. But I evaluated the risk vs reward of his access, and since he’s educatable, I felt it was safe to leave him there. Plus he knows right away to call me if he breaks things.

That goes back to the trust aspect, though. I trust him.

Trusting people to have access to aspects of your site reflect your understanding of what that access means. Making everyone and their brother an admin is reckless, not to sugar coat the situation. Only people who must be admins should have admin access. It’s really that simple. And if you insist there’s no other way around it, then you’re not paying attention closely enough.

Make a list of what your users need to do. Not what they want, what they need. And be serious here. Do they need to update plugins or do you do it for them in a reasonable timeframe? Do they really need to be able to add users? Remember though, we’re asking what they need, not you. Go to WordPress’ list of Roles and Capabilities and take note of what they actually can do.

Now I said before, the roles and controls and capabilities of WordPress leave a lot to be desired. But thankfully WordPress has add_cap and you can adjust roles.

Here’s how Isabel Castillo did it:
```
function isa_editor_manage_users() {
 
    if ( get_option( 'isa_add_cap_editor_once' ) != 'done' ) {
     
        // let editor manage users
 
        $edit_editor = get_role('editor'); // Get the user role
        $edit_editor->add_cap('edit_users');
        $edit_editor->add_cap('list_users');
        $edit_editor->add_cap('promote_users');
        $edit_editor->add_cap('create_users');
        $edit_editor->add_cap('add_users');
        $edit_editor->add_cap('delete_users');
 
        update_option( 'isa_add_cap_editor_once', 'done' );
    }
 
}
add_action( 'init', 'isa_editor_manage_users' );
```
You only need to do that once since the roles and caps are locked into the database (see above, the controls need to be better). Still. Now your editors can edit users. Brilliant.

So yes. I will tell you you’re doing it wrong, especially when you’re doing it in a way that is dangerous and risky in the long run.

Don’t let the toddlers try to drive the car.
8 January, 2016
Mailbag: Hugo from iPads

So I’ve done the whole Hugo thing and it’s great and it totally works for me. That 1% itch left from Jekyll is gone. So queue the inevitable…

But what about mobile posting?!

Why on earth the planet is obsessed with posting everything from their phone, I don’t know. Things like Instagram and Twitter make it easy for us to ‘communicate’ (and I use that loosely) and post photos of our lunch. And yes, the iOS app for the iPhone means I can ‘live blog’ but, to be honest, I hate it on my iPhone.

My iPad though… I love posting from that.

And yes, yes I can post to my Hugo run site from my iPhone or iPad. Remember, I can push my new content by running a git push command. The server will build, sync, and clean up on its own. All I need to do it is a Git app on my iPad that doesn’t suck

Working Copy does not suck.

It’s an iOS app that pulls my git repository to my iPad (the whole thing, so make sure you have room). Then I can edit files, commit them, and push. Hugo on the server does the rest, just like it would from my desktop.

Working Copy is different from many other Git related apps because can hook into any git repository. I’m not using GitHub for this project. I want to do 100% self hosting, and that means no GitHub. Also no BitBucket. These tools are fine for what they are, and in fact I pay GitHub for some private repos. But I wanted my repo on my server, in part so I could do exactly what I’m doing.

The tool is incredibly simple. It’s a familiar file navigator, tap through the folders. Tap edit to edit, make changes to the post, hit done. There’s even a preview feature that mostly works. Some of my Markdown files are very weird.

If I wanted to edit in Byword, which is what I do most of my writing in for non-novel related things, I can share and go back and forth. I’d love it if the WordPress iOS app (or Calypso) did that. Write in Byword, send to other app. But even a copy/paste is simple enough. In this case, I can write in Byword and share to Working Copy. The interface takes the title of my document and let’s me pick the folder.

Once I’m done with my edits, I commit my changes. Then I can push, or not. There’s an option to commit+push, but it crashed my app. A skim of reviews showed this happened to others. The iOS interface can be a bit tetchy so having this be two steps doesn’t bother me.

I did find it odd that there was no button to push. I had to go back to the main folder, swipe-left, and press the orange push button. But that, and the weird crash, were it for annoyances.

While free to download, it’s $9.99 for unlimited deployments. It was free for 3 weeks, which I tried out over WordCamp US and found simple and perfect for my workflow.

25 December, 2015
Mailbag: Wasting Time

Today’s question comes from a Slack DM tossed my way about learning and possibly discarding Jekyll.

Don’t you think you’re wasting your time learning all these nonWordPress things?

Nope! Every single thing I’ve learned and discarded has improved my skill set.

Let’s take MediaWiki. Learning that taught me templating in a way that I never would have understood in WordPress. It also taught me about the perils of your ‘own’ language instead of HTML. While I’ve come to like Markdown, you still have to know HTML to make Markdown really work, because you need to understand what it is you’re writing.

And Jekyll? I learned a lot about importing and exporting data between ‘languages’ that don’t like each other. I also learned a lot about deployment of static content. Anything but FTP, right? Jekyll had me writing my own deployment scripts.

Now that I’m looking at Hugo, really not much has changed. I’ve learned GoLang, which is not all that different from things I already knew. But it’s expanding how I think about the logic structures. Hugo’s got an up on Jekyll in a lot of ways, like how easy it is to make loops for traditional blogs. Also it can handle remote JSON a little better, which sets me up for what’s next.

You see, all of this work, all this learning, is going to come back to WordPress.

What I want to do is manage my site in WordPress and have that output the JSON (via that awesome new JSON API I’ve been learning), which will in turn be dynamically called when I want to build my static HTML site.

For sites you’re not updating daily, or even weekly, this might be the magic you need. Everyone writes on WordPress. Someone has a command (or even a script) to run that collects everything from JSON and dumps it to Hugo, which generates the site for you to proof and then push.

Version controlling the content.

Let the users write in Wordpress while you bask in the glory of your static site that is, pretty much, unhackable as a CMS. I mean… what are you going to do to my HTML?

See?

It’s all WordPress.

18 December, 2015
Mailbag: Why did you ask that at the Town Hall?

Last weekend, at WordCamp US, I asked a question at the town hall.

At its heart, the question was that did Matt feel the rapid release cycle of WordPress major revisions was too fast? I asked this based on the concerns I hear voiced by plugin developers, generally the smaller shops (single person or under ten teams), who not only have to test their plugins with the new versions of WordPress, but also learn these new, rapidly evolving and changing, libraries like ReactJS and the REST API.

Matt’s answer was essentially no, and that he felt that things would only get faster. Also he said he didn’t think plugins should be one-person shops.

What did you think of the answer?

I was asked variants of this by many people that night and the next day.

I disagree with Matt somewhat.

This isn’t a shock. I’m sure he’ll read this and nod. But he and I both know that a health disagreement can be good for an ecosystem. I understand his point, and in many ways agree with it. A team project for plugins and really any development is what makes things improve faster. Two heads are better than one.

But at the same time, we look back on things like Yoast SEO, and to think that those can only exist while supported by a team is to forget the way that all of this, even WordPress, started.

One person has an idea. One person shares the idea. A second person makes a suggestion.

One person.

Of the 45,000 plugins in the repository, the majority happened because of one person. One person had an idea and a dream and built a plugin. One person learned a thing and shared it. One. And the harder we make it for that one person to grow, the harder it will be for them to become the next Yoast, or Woo, or Jetpack.

As of this post, we released four major releases of WordPress within 355 days. I think that speed for the sake of speed is as bad as dragging out feet and having one release a year. Yes, we have improved our stability by having more frequent releases, because we don’t rush to have an unready feature added to a release. There’s going to be another soon. And that’s a good thing.

At the same time, it’s pushed us to release faster and faster, and that causes the bar to be set too high to new people. It causes burnt out. It causes update fatigue.

I don’t think we should revert to ‘release when it’s ready’ again. That has as many problems (if not more) as ‘release X times per year.’ I do feel we need to consider the emotional health and the supportability of what we are releasing.

Do it well, do it fast, do it cheap. Pick two. And know that the price is from our blood and bone.

I think we should turn it down a notch. Just one notch. And we should stop releasing just to be sure we release a number of times a year.

11 December, 2015