Category: How It Works

Why I Pushed Back On Your Plugin
The talk at WordCamp Ventura was actually called “Top 11 Reasons Your Plugin Was Rejected.” It was supposed to be ten, but Konstantine said “You should make it 11!” and I did but forgot to update the info for him. Bonus reason! You can see all the slides at helf.us/wcventura2014 right now. Video will be up on WordPress.tv soon.

The truth is, there were only two reasons I actually would ever reject your plugin. If you never replied to our emails about any of the other reasons, we’ve probably rejected you. And if you’re claiming to be someone you’re not in a way we can’t prove, we’ve also rejected you. Let me cover the reasons here, for posterity. My slides are fully accessible, but people learn in different ways.

And to understand how I made this list, I use aText to auto-reply to things. I just made a note of which ones I used to most, flipped ’em in reserve order, and thus I had a list.

Trademarks

This is the funny story one where I rejected Facebook because they used a gmail address and a DropBox URL for their plugin. I looked at it, thought they couldn’t possibly be Facebook, rejected, and got egg on my face. I’d do it again, though, because the point here is that if you’re making a plugin for a company and you’re using the company name, you need to make it clear and easily provable that you are them.

If you’re doing contract work for, let’s say Pandora, to make an official plugin, you should make a new account on WordPress.org for that. Pandora-Dev or even just Pandora, using a pandora.com email address of course, and then making the plugin downloadable from pandora.com does a lot to make us think you’re real. If you don’t? I may reject you right away.

Missing readme

Otto used to let me pend a plugin because there was no readme. The number got so high, he made me stop. Now we only do this if you’re acting as a service or calling files remotely. Akismet and Disqus would require a readme, as would Twitter, but “Hello Dalai” would not. Of course you always should make a readme, but we don’t force you to do so.

Phoning Home

Akismet ‘phones home’ to it’s own servers to process your comments as spam or ham. That’s not what I mean here. We don’t permit plugins to phone home to your own server unless they’re acting as a service.

A plugin that simply validates a license and ‘unlocks’ functionality that’s already in the plugin is not a service. A plugin that sends an email or message to your own servers when the plugin is installed and/or uininstalled is also not a service. A plugin that calls out to maxcdn or Amazon S3 for your JS and CSS files is also not a service.

When you call out to another server you’re generally doing one of the following:
1. Intentionally tracking the use of your plugin
2. Creating an unnedded dependancy on another server being accessible in the interest of ‘controlling’ your css/js/images or keeping your plugin smaller
3. Trying to control who uses your plugin
None of those are okay. Think about it as a user. If you’re behind a firewall and can’t access Google (which is not an unrealistic situation), and your plugin requires Google’s version of the html5 shiv script, you just broke your plugin for probably the people who needed it most. Well done.

Don’t do this. Make everything local to your plugin. It will actually run faster.

Updates

Related to phoning home is a plugin who calls back to it’s own servers for updates. Would you be surprised to learn that WordPress.org hosted plugins can already serve updates from WordPress.org? Of course not. You’ve seen that helpful alert on a site before. This is usually a hold over from self-hosting a plugin, or hosting it on Github, but it still needs to be removed.

One of our guidelines is that you actually use the WordPress.org hosting to, you know, host your plugin. It’s not a directory for spamming, it’s for using to deploy too.

Encryption

Using encryption methods like base64() or p,a,c,k,e,r to hide your code or otherwise make it human-unreadable breaks our rule of “No obfuscated code.” It’s fine to compress your code and minify, but it’s not okay to hide it. All code must be human readable for inclusion in this repository.

This is because we feel the spirit of GPL means that anyone can easily look at your code to reverse engineering what it does and expand on it. Easy being subjective of course, but you get the idea. Hiding your code is useless. It doesn’t help the community at all.

GPL

Speaking of… I don’t care your thoughts on GPL. I really don’t. What I care about is this: In order to be hosted on the WordPress.org repository for plugins, every single bit of code in your plugin must be compatible with the GPLv2 (or later) license. This isn’t negotiable, it’s not up for debate. It’s above and beyond what the GPL requires, and we know that. Which is why I just don’t care how you think we’re ‘interpreting the GPL wrong.’ That isn’t my point at all.

You want to be hosted on WordPress.org? Your code must be 100% compatible with GPL. Deal with it.

Calling wp-load or wp-blog-header or wp-config

Including wp-config.php, wp-blog-header.php, wp-load.php, or pretty much any other WordPress core file that you have to call directly via an include is not a good idea and we cannot approve a plugin that does so unless it has a very good reason to load the file(s). It is prone to failure since not all WordPress installs have the exact same file structure.

Usually plugins will include wp-config.php or wp-load.php in order to gain access to core WordPress functions, but there are much better ways to do this. It’s best if you tie your processing functions (the ones that need but don’t have access to core functions) into an action hook, such as “init” or “admin_init”.

If you’re trying to use it because you need to access WordPress functions outside of WordPress, we’d actually much rather you didn’t do that at all. Your plugin should be inside WordPress, only accessible to people who are logged in and authorized, if it needs that kind of access. Your plugin’s pages should be called via the dashboard like all the other settings panels, and in that way, they’ll always have access to WordPress functions.

Security

Sanitize your post calls, sanitize your SQL queries, use the right code, and be smart. Don’t reinvent the wheel. This is the hardest one to get right and we miss a lot of things, but we want all instances where $_POST data is inserted into the database, or into a file, to be properly sanitized for security. And when you’re making database calls, it’s highly important to protect your code from SQL injection vulnerabilities via prepare() or other functions.

This is just hard but we do try very hard to catch them all.

Including your own copy of jQuery

Please stop this.

WordPress includes its own version of jQuery and many other similar JS files. If your code ‘requires’ an older version, fix your code to work with the one that comes with WordPress. Having ‘your own version’ means you run the risk of breaking everyone else’s plugins and themes, which makes you a bad person. Stop it. Use the ones with WordPress. It keeps your code smaller and your plugin smaller. Also if everyone uses the built in ones, then the first time one of you enqueues it, the faster everyone else’s code will run. Really. It’s magic.

Calling wp-content directly

When you hardcode in paths, or assume that everyone has WordPress in the root of their domain, you cause anyone using ‘Giving WordPress it’s own directory’ (a VERY common setup) to break and you make me cry. In addition, WordPress allows users to change the name of wp-content, so you would break anyone who choses to do so.

Oh, and don’t worry about supporting WordPress 2.x or lower. We don’t encourage it nor expect you to do so, so save yourself some time and energy. Remember! If we stop supporting WP 3.8 and older, then people have to upgrade to use our plugins! Everyone wins!

Not answering an email

If you never reply to an email we sent you about why we pending your plugin, yes you got rejected. In order to keep the queue low and manageable, we reject plugins after seven days from our first reply (not your submission). This can also happen if you’re working with one of us on your plugin code and it takes a long time. This happens when a plugin is complicated, or if there’s a language barrier, or if we just can’t understand why you’re not making the changes we asked for.

Did I reject your plugin and you still don’t understand why? Have a weird question about plugins? Ask away in the comments!
19 November, 2014
Karuta

The idea of WordPress Karuta is based on the Karuta (カルタ) game in Japan. Karuta means, essentially, card game and yet is a very popular game to play competitively. The cards are written with the Ogura Hyakunin Isshu, which are 100 famous poems, and the game is played very simply. The poem is read and the first person to find the card of the poem and tap it gets the card. In the end, the most cards wins. It’s also really wild to watch.

http://www.youtube.com/watch?v=nKAmZxVhQww

At WordCamp Tokyo they introduced me to WordPress Karuta.

The game is simple. The black cards are to be asked aloud and you grab the pink card with the answer.

I now have all the data from the 2013 and 2014 cards and the plan is to make a GlotPress site where we enter all the Japanese original data and translate it so anyone, anywhere, can make the cards to play and teach. Yes, teach.

If you’re an American, think of it like Jeopardy the card game and pretend you Alex Trebeck is saying this: “Display the URL of the individual pages, such as posts or fixed page.”

And you go, “Oh! the_permalink!!”

But instead you grab a card.

This would let people learn in a fun way, as it forces you to think about the meaning behind the code. It’s easily extendable past just code, you can ask questions about plugins. For example, an answer might be ‘WordPress SEO’ to a question of ‘A plugin that allows you to connect to Google Analytics, Google Webmaster, Yahoo sites, and also edit your robots.txt file.’

I’m going to work with Markus and Shin to translate this so everyone can try their hand at WordPress Karuta!

7 November, 2014
Mailbag: Site Security Plugins
This one comes from Gabriel and WordCamp LAX:

Hello, I met you at WordCamp LA 2014. Thank you so much for speaking there and giving me great advice. I am now in a pickle again though, I wanted to ask you as an expert. What premium/pro version of site security protection would you find to be the best for a WP site? I am now using the free version of iThemes but I want to start buying pro version of iThemes, which would be $40 a year for a client.

I don’t use any security plugins on this site. I use Mod Security, some complex .htaccess rules, and a firewall app on my server. None of the weight of the security is on my WordPress install for a few reasons.

This site may be a nice massive Multisite, but on this server I have a dozen other WordPress sites and not all are my own. I also have a gallery and a wiki, a forum, and a few other non-WordPress things. Using just a WordPress plugin leaves about a third of my site not protected. Worse, it means I have to be sure all my ‘customers’ are equally protected all the time and upgraded and configured right. I opted to take that out of their hands.

Most major hosts (DreamHost, BlueHost, GoDaddy, LiquidWeb, etc) all have Mod Security and a firewall, or some equivalent. Some of them have fail2ban and others have CSF but they all do have server level protections that frankly do a better job of protecting you against a brute force attack than a plugin ever can. I’ve said this before in many different ways but I’ll spell it out again. I don’t believe a plugin is ever the best choice to protect you from a DDoS. That does not mean a plugin doesn’t help, but it does mean I would never use it as my first and only defense against attacks and hacks. The practical reason is that it makes a site slower, to have it recursively check things.

With that said, there is a different sort of ‘protection’ to be gained from a security plugin, and that is notifying me as to what files are changed. If you’re using cPanel, WHM has a feature to email you about Recently Uploaded Cgi Scripts which emails me when certain core files on my server changes, but also when a plugin upgrades and messes with email:
```
/home/ipstenu/public_html/wp-content/plugins/contact-form-7/includes/submission.php:240:
/home/ipstenu/public_html/wp-content/plugins/contact-form-7/includes/submission.php:241:       private function mail() {
/home/ipstenu/public_html/wp-content/plugins/contact-form-7/includes/submission.php:242:               $contact_form = $this->contact_form;
```
That’s one of my favorite things, by the way. It’s a rare email to get, but I love getting it because I know what dangerous emails are sent. There’s also an add-on feature of CSF called ConfigServer eXploit Scanner which can be used to send emails when any file is changed. This is awesome for scanning PHP changes and even is aware of WordPress though it’s probably going to have a lot of false positives given the nature of WordPress upgrades.

And this does get us to where I do use security plugins. Rarely, yes, but when I do use them I use products like a malware scanner to make sure my files aren’t changed without me knowing. You hear that called “Security File Integrity Monitoring” sometimes, and the idea is that I want to know when any files on the server are changed. But since Gabriel mentioned ‘for a client’ I can guess that he doesn’t have admin access to the server, which makes the whole thing a lot messier.

The weakest leg in the security tripod is users. Sorry. Users are people. We make mistakes, we eat gas station sushi (hush, Otto, you get the point), and we don’t think about our actions.

With that in mind, which plugin would I use? It depends on the client and how much help I think they’ll need cleaning up, and how much help I’m going to be expected to provide. I’d be inclined to hook them up with a service that can help unhack them if I’m worried about that, or if I know they can follow directions well, then a simple scanning plugin is fine.

It’s really not a simple answer, though.
29 October, 2014
He Ain’t Heavy, He’s My Website
I get asked this a lot from a more technical perspective.

All the myriad reasons you have to use, or not use, Multisite aside, the question that is often wondered and confused over is the one where we’re trying to balance out ease of support vs cost. You see, a lot of the time, people consider multisite because they’re on a webhost who only allows one domain for your site. You may be able to use add-on domains but they also may be limited, and the easiest way to run a hundred sites on one hosting plan is multisite.

I have to remind everyone here, I would never, ever, in the history of ever even remotely consider running Multisite on anything less than a VPS. Yes. I said it. Keep in mind when I run a Multisite I’m always doing it to run a network of heavy duty sites. If I was just running a tiny private network, my goals would be different. But more than that, I keep in mind the realizations of the limitations of shared hosting. Shared hosted is tiny. Multisite is big. Match ’em up and you’ll be happier.

What does this have to do with the heft of a network? Well if I have 100 separate sites and 100 sites on a multisite network, what’s the real, practical difference?
- 100 separate logins vs 1 login on 100 sites
- 100 separate sites to update vs 1 site
That’s pretty much it. Yes, there are a dozen of little things (like it’s easier to restrict access to a single site) that come into play here, but when you start looking at the server itself, the practical differences when it comes to things like disk space, memory usage, process utilization, and emails, there is no negligible differentiation on your site’s performance.

Yeah, 100 separate sites and 100 sites on a network will run pretty much the same on the same server, assuming the exact same level of traffic and use of plugins. That’s a pretty big assumption most of the time but in this one case, it’s safe. We’re trying to compare apples and apples, with only one difference: Multisite or Not.

Of course, there are specific situations where a multisite will cause more damage to a server than a single site, especially if you’re doing a lot of cross-content manipulation (like including the RSS from one site into the sidebar of another). But it all really depends on if you have a lot of traffic. Yes, one Multisite blog getting hammered will hurt the others on the network, but it shouldn’t cause a significant CPU spike any more than two separate really massive single sites would on the same server.

And there is one place where Multisite very much would do more work on the server than Single Site, and that’s with ms-files.php. That old magic that made your image URLs to be domain.com/files/2014/09/image.job. The way that worked was to pass images via .htaccess through the ms-files.php page and then generate the image. Yes, that caused more load. It’s part of why we don’t do it anymore, and why I suggest never trying that again.

It’s funny, though. I’ve seen one host say that Multisite will use less by way of PHP processes because it’s one install, while another said it would use more because ‘Multisite’, and a third said there’s no difference.

Obviously I don’t think there’s a difference.
3 September, 2014
Referrer Madness

Everyone’s heard of Semalt by now. They are, weirdly, an actual company run by actual people, who are entirely weird and annoying.

I should explain. I’ve talked to them in email and twitter, and I’ve read about them all over the net, like everyone else has. They’re an ‘SEO’ company who trawls the net via bots, just like Google and everyone else, tracking you and your competitors. Here’s how they explain it:

Semalt is a professional webmaster analytics tool that opens the door to new opportunities for the market monitoring, yours and your competitors’ positions tracking and comprehensible analytics business information.

That sounds vaguely legit when you look at it on the surface. They’re based in the Ukraine, which explains the imperfect English, and showed up right around the time Russia was invading, so most of us made Putin jokes and moved on. They’re not actually doing anything bad, they’re just acting like a regular bot, scanning your site…

Except they’re not.

When asked, they’ll tell you that Semalt crawler bots visit websites and gather statistical data for their service, simulating real user behavior. Their crawler bots, and yes, they admit they’re bots, don’t click on advertising banners or extend links. And all the visits are automatic and random.

This means their goal is to get a bot that acts like a human. Now I don’t know about you, but I don’t trust anything when I can’t see it’s brain, and I certainly know better than to believe in true random when it comes to software. But what gets me is how you stop the bot from scanning.

Everyone uses a robots.txt file to block bots from scanning things they don’t need to scan. If you use WordPress and have pretty permalinks on, go to http://example.com/robots.txt and you’ll see a default file, made by WordPress, to block various folders like wp-admin from being scanned.

Semalt ignores these. They also ignore things like bot rate limiting, and they use IPs from around the world to scan your site (arguably to get a better idea of real speed and response), so they end up acting a little like a DDoS attack. Worse, they claim to act like a ‘user’ but I never have a link to my wp-admin pages from the front of my site, which means their bot is checking for WordPress and going there not because a user would have any reason, but simply because Semalt knows WordPress is there.

They have a form you can fill out to have it removed if you want, but we’ve been using robots.txt for years, and I simply fail to understand why they’re ‘better’ than the standard.

Besides that, what’s the real issue here? Semalt is screwing up my stats. They’re using referrer links to check my sites out, which means I have a bunch of referral links like this:

semalt.com/competitors_review.php?u=https://halfelf.org

Those links tell me someone linked to me, and generally I go back and check them out to see if they’re something I want to talk to or work with. These are not. Worse, they don’t really act like ‘real’ users, despite the claim. Karen Francis has a great explanation as to why Semalt is ruining your bounce rates in Google, and a couple good ways to block them.

Am I blocking them? No, not right now. Do I trust them? Not at all. They make it ‘easier’ for someone else to compare themselves to me, which is laudable, but they do it in a way that makes it harder for me to understand how my sites are doing. And that, to me, is the epitome of the goal of all black hat SEO companies. They gain at someone else’s loss.

27 August, 2014
Don’t iframe Me In
I review plugins for WordPress.org, and one of my pet peeves is when I see a plugin that purports to connect your site to their service…. using an iframe.

I have a stock reply to those:

Having the admin dashboard be just an iframe isn’t permitted.

We don’t permit plugins to phone home like that (for two main reasons – security and appearance – too often people assume that they just signed into WORDPRESS and not your plugin). Please change your code to use an API or just link back to your site so they can configure things there.

The minority of the time, this is accepted, fixed, and moved on. The majority of the time, people complain that it’s ‘easier’ or ‘not confusing’ or ‘someone else is doing it.’

If everyone on the planet would stop using someone else doing something wrong as a reason to allow them to do it, I’d be so happy… But that isn’t the point. The point is that using an iframe in a plugin is a bad idea in general, and a horrible idea for your admin panel.

Let me step back. Like everything else, iframes are awesome to a point. They’re a great, easy, way to include content in your site without having to include a mess of code. When YouTube was new, iframes was the only way to include videos, and they looked like this:
```
<iframe width="420" height="315" src="//www.youtube.com/embed/dQw4w9WgXcQ" frameborder="0" allowfullscreen></iframe>
```
You’ll notice the iframe has to specify a height and width, which means I can’t adjust my site quite as much as I want to. The other major issue here is that I’ve had to specify http, which means if my site runs https, I will have security issues. Now, there are workarounds to this (and YouTube now uses a src of //www.youtube.com/embed/oHg5SJYRHA0 to mitigate the security issue), but there’s another, cooler, aspect to how it’s all working.

If you use WordPress, you don’t have to paste in the iframe at all, ever, because you have embeds! What the embed does is use the magic of oembeds to … well … embed! This allows WordPress to reach out to YouTube, ask how it wants to embed itself, and use either embed code or iframes or html5, or whatever else we come up with! It does this using an API (application programming interface) which let’s it talk back and forth. This same principle applies to your plugin pages. If you use an iframe, it’s a quick and dirty way to include content from your service (like a login form) on the plugin-user’s site.

So why don’t I like people to use it? Let’s start with the login issue. The admin page could be changed to point that iframe anywhere it wants, making it easy to send you to a page that looks a lot like the ‘right’ page but isn’t. This is a lot harder to do if, instead, you have an API that securely transmits data. If someone can edit the php code of your plugin, either one is possible to be redirected, but the API details are a little harder to fake.

An iframe is also a problem when you consider layout. Yes, it can make design easier in that you are in full control of the design, but you’re not in control of the rest of the site. I like the eggplant color for my admin dashboard, and if your iframe clashes with that because you don’t ‘look’ like WordPress, then it’s jarring for a user. Another worry? Adblock or Ghostery, the two most popular browser extensions ever, will often block those things.

Finally, and for me this is the biggest one, your users won’t know where their account is. Look, I know it should be obvious when you have something that ‘makes’ an account with a service that the account belongs to the service. And yet. One of the places I help out is with WordPress.org password resets. 90% of the emails are for people trying to reset the password on their own blogs. You can’t convince me that people actually know what they’re doing anymore, if they ever did.

So please, don’t put an iframe in your plugin as the only way I can access your admin area. It’s lazy, it’s insecure, and it’s confusing. It’s 2014. Trust me, people understand allowing their blog to connect to Twitter now.
22 August, 2014