Tag: wordpress

Mailbag: Debugging the Dread “No Permissions”

Sometimes customers hunt me up here. That’s okay. I’d rather you opened a ticket since I like to eat, sleep, and hang out with my wife, but in this case they also had an interesting problem.

When I log in, I get “You do not have sufficient permissions to access this page.”

I found the support ticket and solved it, and then I mailed the DreamPress Ninja’s with this methodology. It relies on wp-cli, so bear with me.

The first thing to do is check the user list:

user@server:~/example.com$ wp user list
+----+-----------------+--------------------------------+-----------------------------+---------------------+---------------+
| ID | user_login      | display_name                   | user_email                  | user_registered     | roles         |
+----+-----------------+--------------------------------+-----------------------------+---------------------+---------------+
| 2  | bobby           | Bobby Done Nightly             | bobby@example.com           | 2014-02-12 17:44:28 | administrator |
| 3  | darren          | Darren Done Rightly            | darren@example.com          | 2014-09-29 17:49:11 | contributor   |
| 4  | ethan           | Ethan Done Wrongly             | ethan@example.com           | 2014-10-27 21:01:07 | subscriber    |
| 5  | jimmybear       | Jimmy Eaten By A Bear          | jimmy@example.com           | 2013-12-16 14:45:18 | author        |
| 1  | iamempty        | Admin Account                  | admin@example.com           | 2015-03-05 01:30:09 |               |
| 6  | sonnyboy        | Sonny Boyd                     | sonny@example.com           | 2014-10-27 22:13:08 | contributor   |
+----+-----------------+--------------------------------+-----------------------------+---------------------+---------------+

Notice how imaginet has NO role? That’s the problem. So let’s give it a role!

user@server:~/example.com$ wp user add-role 1 administrator
Success: Added 'administrator' role for imaginet (1).

Check again and all is happy!

user@server:~/example.com$ wp user list
+----+-----------------+--------------------------------+-----------------------------+---------------------+---------------+
| ID | user_login      | display_name                   | user_email                  | user_registered     | roles         |
+----+-----------------+--------------------------------+-----------------------------+---------------------+---------------+
| 2  | bobby           | Bobby Done Nightly             | bobby@example.com           | 2014-02-12 17:44:28 | administrator |
| 3  | darren          | Darren Done Rightly            | darren@example.com          | 2014-09-29 17:49:11 | contributor   |
| 4  | ethan           | Ethan Done Wrongly             | ethan@example.com           | 2014-10-27 21:01:07 | subscriber    |
| 5  | jimmybear       | Jimmy Eaten By A Bear          | jimmy@example.com           | 2013-12-16 14:45:18 | author        |
| 1  | iamempty        | Admin Account                  | admin@example.com           | 2015-03-05 01:30:09 | administrator |
| 6  | sonnyboy        | Sonny Boyd                     | sonny@example.com           | 2014-10-27 22:13:08 | contributor   |
+----+-----------------+--------------------------------+-----------------------------+---------------------+---------------+

If the roles had be totally empty, it’s a case where the database is looking for the ‘wrong’ table prefix and that’s a little messier. There, you’ll want to grab the table prefix from the wp-config.php file:

$table_prefix  = 'wp_hsy671e_';

Then go into the database and look at wp_hsy671e_options for a field called wp_hsy671e_user_roles – if you don’t see one, that’s the problem. Check for one named wp_user_roles and rename it.

If you DO see the right user_roles, then the problem is all the users are pointing to the wrong table. You can just run wp search-replace wp_user_roles wp_hsy671e_user_roles to force it back.

20 March, 2015

I Hate Your Framework
The plugin itself was one PHP file and three JS files.

The framework was over two megs.

The plugin added in a new setting to select which one of the three javascript files should be called.

The framework ‘made it pretty.’

I’m right up there telling people that the WordPress Settings API is a giant bag of wet hair. It’s confusing, it’s cryptic, it doesn’t always play well with everything, and sometimes it makes you feel like the point is to make us have decisions, not options, for our plugins. But I don’t think plugin frameworks are the answer. At least not the way most people seem to be going about them.

When I say frameworks, I don’t mean the libraries like the AWSSDK for PHP framework that you package up into your plugin and do a proper check for a function, calling yours if the the library isn’t there. No, I mean the plugins that are totally separate plugins but are meant to be called by yours in order to make development easier and more consistent.

That’s what I hate.

I love the idea of these frameworks, actually. I think that a boilerplate plugin, similar to _underscores, where I can put in my plugin name, my information, and press a button to have the basic plugin files generated for me is brilliant! But I think most of the libraries out there are doing it in a way that will annoy and upset most people.

The problem is less the framework and more the people using them as a ‘quick fix’ without properly thinking about what they want to do.

They’re Too Large

In the case of this plugin, one file with three settings could just be done with two functions (maybe three) and instead he’s made a download half the size of WordPress core. The zip is large, it makes things take just a little bit longer for people on slow servers to download and upgrade, and the larger you get, the worse you are for the really small shared hosts. I know a lot of people argue with me about this, but remember than a high number of hosts still default you to allow 7M in PHP upload size. That means when your plugin becomes the 30 meg behemoth with all your dev files, you’ve made things pretty bad for some users. But even when you’ve only made your plugin 2 or 3 megs, why would you do that when you have one file of actual code?

The logic escapes me.

They’ve Got Too Many Files

Not the same thing as too large! There are hundreds of files in a framework, and if you’re using only 4, that means you have 96+ files to review for security. You just increased your workload for not enough value. Which is really a major part of my next issue. The point here is you, the developer, are responsible for every single file in that framework. You are expected to know everything about it, where it installs, what it uses, why it uses it, and when to upgrade. This is a pain. It’s a chore. And it’s your job now.

You Don’t Know How to WordPress

This is also why I don’t like the idea of making Multisite too much easier. The further you take a developer from writing this code, the further they get from understanding how it all comes together and the harder it is for them to debug their own plugins. If you’re developing a plugin you plan to share with other people, even a teeny tiny one, you need to understand what you’re doing. You need to learn about the way the code interacts with the CMS tool, you need to understand why some things are secure and others are not.

You Use the Frameworks Wrong

I said before, I love the idea. And I do. They’re a brilliant idea and, when done right, work perfectly. The problem with them is, a bit, a problem with WordPress, which is we really don’t have a way to handle children plugins. You see, the best thing for a true framework plugin would be to have it be a separate plugin. But without plugin dependency support in core or the directory, it becomes another level of hassle for users.

For example… if you have the plugin as a separate plugin, these are the issues we’ve see for end-users (not developers):
- Not recognizing the framework plugin, and thus deleting it (causing the plugin(s) to break)
- Not recognizing the framework plugin and thinking they’ve been hacked
- Updating the framework plugin separately from the dependent plugins, possibly leading to breakage
- Updating a dependent plugin without updating the framework, possibly leading to breakage
- Different plugins requiring different versions of the framework
And bearing in mind that the framework and plugin developers are different people, that’s another level of coordination/compatibility issues. Frameworks and libraries should be packaged with each plugin (hopefully in a way that doesn’t conflict with other plugins using the framework or libraries). At least until core supports plugin dependencies.

But I still think that’s wrong.

I still think the best framework plugin isn’t a plugin at all, it’s a tool to help you design and build a plugin via your editor of choice. Or maybe a Grunt Script that lets you build it out based on parameters. Time spend making a framework for making the plugin ‘interface’ better would be better spent making the Settings API better.
18 March, 2015
Mailbag: Learning Resources

Ann asked about books:

[..] if you’re open to throwing a few key book recommendations – sites – blogs – whatever resources that you use/have used and particularly liked – I would be grateful. Essentially – I love your blog and am always looking to improve my WP developer skills. I want to get better. I want to be really really good. So I ask the greats if there’s something in particular that they think I should read – out of the huge sea of articles/books/blogs/etc out there. Something that they’ve singled out and thought was really worth paying attention to. And then I read it! [..]

She got an email reply right away, but here’s for everyone else.

The best advice I have is to pick something you like (or that drives you absolutely up the wall) and poke at it.

I got started and good because I really, really, really, wanted to do something that (at the time) WP didn’t do. After banging my head a lot, I started googling and trying to figure out what was there to use. I looked at a lot of code that was ALMOST what I wanted. And I broke my test site. A looooooooot.

The biggest problem is we all learn differently. I learn by doing, so for me the act of writing BAD code helps me understand it better. I hate videos.

But do I have a specific resource for learning? Sometimes I do. The majority of my ‘research’ remains search engines and constantly refining parameters, or trying to remember the name of the one thing with the thing. The problem is that I’m very haptic, I learn by doing things, so for me it’s way easier to take the examples and break them than anything else.

13 March, 2015
Mailbag: What Code Makes You Sigh?
When I was talking about ThemeForest, I mentioned we had code on WordPress.org that made me sigh. Or cry depending on the day.

Here it is:
```
if (!defined('WP_CONTENT_URL')) define('WP_CONTENT_URL', get_option('siteurl').'/wp-content');
if (!defined('WP_CONTENT_DIR')) define('WP_CONTENT_DIR', ABSPATH.'wp-content');
if (!defined('WP_PLUGIN_URL')) define('WP_PLUGIN_URL', WP_CONTENT_URL.'/plugins');
if (!defined('WP_PLUGIN_DIR')) define('WP_PLUGIN_DIR', WP_CONTENT_DIR.'/plugins');
```
Why do I sigh?

It’s not needed.

You can use functions to determine those directories and while I’m sure someone’s thinking “But WP_PLUGIN_DIR is shorter than plugins_url()!” it’s not.

That code block above was used so that one line of code could exist.
```
include(WP_PLUGIN_DIR.'/PLUGINNAME/settings.php');
```
Those four lines, plus the include, could be replaced with this:
```
include( plugins_url( 'settings.php' , __FILE__ ) );
```
So yes, I sigh. Because with just a little work, you could see that there’s a more efficient way to make your plugin smaller.
6 March, 2015
Stop Using Copy Protection
I’ve seen a million features out there to ‘prevent people from stealing your content.’ The idea is that by preventing people from (easily) copying your work, you stop them from stealing it and profiting off your efforts. You may even think that you’re saving your images from being stolen. In general, they use javascript to prevent things like right-click, view source, copying text, and disabling keyboard short cuts. In general, they suck and here’s why.

User Experience

Anyone who uses a screenreader or an alternative mouse tool now, officially, hates you. You’ve made your site look like absolute crap. Some screen readers can no longer read your content at all. Also not everything handles javascript very well (which is by far the ‘most popular’ way to block out content) and that makes for a pretty lousy experience for your visitors.

Support

If you have a problem with your website and ask the world at large for help, they will take one look and hate you. No one can easily help you with your CSS or your layouts or your design now, because you’re protecting content. When customers ask for help, the first thing I do is turn those plugins off so I can use my normal debugging methods and not worry about cruft interference.

It Doesn’t Work

If you disable right-click, you make it harder for me to bring up Chrome’s dev tools, but not impossible. You can’t make it impossible. This is, in part, because there are so many different browsers to account for, but also because developers really don’t want you to be able to kill dev tools. We need them to fix the web, and if I were to leave the dev tools open and then visit your site I would be able to have it open on your site.

Once I have dev tools open, I can view the resources loaded by your page. Take Instagram, who doesn’t let you right-click on an image to download. I can instead right-click, chose ‘Inspect Element’ and I get this:
```
element.style {
    background-image: url(http://photos-g.ak.instagram.com/hphotos-ak-xaf1/t51.2885-11/10912600_6619567248918_1818171895_n.jpg);
}
```
Guess what I can do now? Load that URL in another window, download, done. If that’s not available, I’ll go over to the Resources tab, open up the Instagram folder, then Images, and find the image I want. Again, done.

There’s Only One Way

There is but one foolproof way to prevent your content from being stolen: Don’t publish it.

But of course no one wants to hear that. So what’s the other way? Well give up on not having your words stolen. Even if you make it difficult, people will get at it. People type up books and scripts today, they’ll do it for your website if they’re properly motivated. Images, on the other hand, are a different issue. If you’re a photographer, don’t put your full-sized images online unless you’re selling them. And if you are selling photographs, put them on a cloud host like Amazon. Large files and PHP aren’t the best of friends anyway. Your website, unless it’s a store, doesn’t need the 10meg image file.

As much as it pains me to say it, DRM is also a solution. So is watermarking your images. The way people like Getty protect their images is to lock it down to purchased users only. You can (fairly easily) download the smaller, sample images, but the awesome big ones are locked down.

But that’s how you protect your content. Not with those plugins.
23 February, 2015
What Themes Get Wrong

I neither create nor review themes. I can fix a theme and edit one and hack one, but I don’t design them because I don’t visualize that way.

But boy do I see a lot of themes doing things in a way I can only describe as wrong.

Packaging and Requiring Plugins

A lot of themes do this, and I can understand why. If you make a theme that’s meant to be a store, then of course you want it to be used with an ecommerce plugin. That makes sense. But then we have to think about the drama of Revslider or TimThumb and we have to question the themes that throw every feature into their code. Part of development is maintenance. This is an accepted responsibility and, in the case of plugins, we’re all used to upgrading them for maintenance. The same isn’t true of themes. People hate upgrading their themes, and it’s the fault of themes themselves, doing things wrong.

Forcing Users to Edit Files

The first week of February I lost my mind at a theme. I had found a user who had run into a mod_security error. They were trying to edit their theme via the WordPress theme editor and hitting save tripped the scanner. Why? The code in the functions.php file was phrased in a way that spooked the scanner. We walked her through SFTP, which worked, and I helped review the security rules to see if we could safely change them. But then I asked her why she was editing the files directly.

She wanted to edit her footer, to remove the ‘powered by WordPress and Theme’ line, and the only way was to edit the file.

That couldn’t be right, I shouted at my screen, but I tested and used the theme and was stunned. Yes. The theme was written in a way that the footer wasn’t editable unless you could code and use a hook to unset the action and make a new one. Even just a simple child theme wouldn’t help because the footer was handled in a function and not footer.php

No wonder users edit themes. But then it got worse.

Forgetting About Cache

The top line in the header.php was a forced setting to create a new PHP session. There are a few problems with this. In many cases, having PHP sessions causes a cache to not serve cached files because the forced session tells it that the particular visitor is meant to have a unique sessions and its trying to honor that. The other common situation is that the first person makes the cache with their unique data, and all subsequent visitors get that cached data. Neither is desirable.

Why do people do it? I presume because when they built their features, they wanted to make sure each user got an individual view. But sessions are a cheap and dirty way about it. Sadly so are cookies, which a cache will either ignore in order to serve cache, or honor and slow a site down.

People remember to test a theme for speed and features, but so often they forget to test for cache.

Un-WordPress Designs

When a theme makes its own custom interface, it’s harder for users to know what to edit and where. It’s the kind of cognitive dissonance that happens when you’re reading a book or watching a tv show and suddenly everything feels wrong. Like if Harry Potter and Dolores Umbridge started dating. Right. That’s how uncomfortable it is to see a theme with its own custom design for the admin pages.

Let WordPress be WordPress.

Accessibility

I don’t meant on the front end. I mean did you know that there are very few themes that, on the back end, are fully accessible to the blind? It’s just not something people think about and it’s the worst thing a theme can do to the world. You may think that only a small part of the world is blind and you may not worry too much about such a small potential user base. But look back to the previous point. The less you design like WordPress the worse it is for users. All users.

What Do You See?

What drives you batty?

18 February, 2015