Tag: administration

No Notice For Upgrades?

About a week ago I realized I’d not see an email with the subject “[Ipstenu.Org] Background updates have finished” in a long time. A really long time. Like so long that when I looked in my email trash, there wasn’t one.

This was bad, because on Ipstenu.org I’m running trunk WordPress, which means I should get two emails a day about this. I ran to my server and scanned logs for 30 days. Nothing. And that was really bad.

I’ve been using Advanced Automatic Updates for a long time, and I love it, it works well, but it wasn’t working ‘right’ for some reason, because it wasn’t emailing me on that one site, so I uninstalled it. The problem there is that without it, how would I upgrade plugins and themes? Since I know I can control the upgrades with filters, I decided to make an mu-plugin to handle just that.

And that was when I saw I already had an mu-plugin called upgrades.php with this:

WordPress site: https://ipstenu.org/
The following plugins were successfully updated:
* SUCCESS: Akismet

Perfect!

I don’t know how fun that story was, Benny, but that’s what happened.

26 November, 2014
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
Automatic Geolocation

Traveling outside the USA always reminds me of how annoyed I am when I go to websites.

Like most of you, I have a bevy of websites I visit regularly. In my case, a large number of these sites are image or video related, and due to the legality of those things, I find myself restricted based on my current location. It annoys me, because if I pay for a service like my cable TV, why can I not watch it outside my home? Restricting my content based on my location is frustrating. I get CSI at home, but I can’t watch it while I’m here in Japan. This, of course, leads to things like illegally downloading movies, because there simply is no easy, quick, efficient way to acquire those things.

But worse than that is the tacit assumption that just because I’m in Japan, I want to visit the .jp version of a site. The number of sites that auto-redirect me to my current location’s language are not few, and most of them don’t have an easy way for me to click back and explain I’m not able to read Japanese.

For many years I’ve told people that forcing a language choice on users based on their IP is improper and unpredictable. It’s for the same reason I tend not to recommend blocking entire countries from your websites. The probability that you will hit innocents with a broad attack is very high. It’s higher than the chance of rain in Southern California.

So how do you do it right? You have to start by asking the right questions.

What language does the computer use?

You can detect that, you know. If my computer uses English, the odds are that I want to use English. Of course, a French speaker might use my laptop, but that’s on them, and one hopes they know to go to google.fr instead of google.com. Speaking of that…

What URL did I type in?

If I go to a URL directly, I may actually want that URL. This goes for you mobile apps too. If I go to Google.com right now, I get this:

That’s a nice, friendly question in English asking if I’m sure.

Have I been here before?

Cookies. When I go to a site, I get cookies. Those cookies can tell you what language I used the last time. So if you have a flag system where I can pick my language, please do try to honor that. There’s nothing a visitor hates more than having to reset their preferences every time. Facebook, this means you.

Where is my IP?

I know I said not to use this, but there’s a reason I want to ask this. If I take into consideration the URL, the browser locale, and the IP, I have a clearer picture of who’s visiting the site and what they want.

15 October, 2014
It’s Not GPL and That’s Okay

I’m probably starting a wildstorm here, but I want to put this out there. I don’t always use 100% GPL products on my sites, and that’s okay.

Please put down your pitchforks!

I am a happy Open Source person. If you give me a choice between two equally good products, one being Open Source and the other not, I’ll pick Open Source any day of the week. But. There’s a reason I use Apple Pages and not Open Office. Pages works for me. It fits my workflow, it fits my brain, and it makes me write more easily. Since I’m often sprawled on the couch writing with my thumbs on my iPad Mini, it makes perfect sense to use Pages and iCloud.

But there’s another place I don’t worry too much about GPL or Open Source, and that’s when I’m coding something that is only ever going to be for me.

I was working on a new site and we were looking for icons to properly represent how we felt. We needed a toaster. We didn’t have one in Font Awesome or Genericons, so I pulled up Symbolicons! The catch? It’s not GPL. But the thing was, we knew we’d never be distributing these icons. It was for one website, so why did it matter?

And the fact is that for this use case, it did not matter at all!

Understanding what I’m doing, who it’s for, and where it’s going to be used is highly important. And understanding what I want to support and maintain is equally important. For the most part, open source doesn’t come with Apple Care or companies like OWC who specialize in bailing people out or helping them extend things. WordPress doesn’t come with that, for good or not, it’s really a ‘figure it out as you go’ sort of product.

There are use cases to consider. Who’s going to use the computer? What do they know? Is it worth teaching them Linux or can they keep using their Mac? Much like I do when I’m mentoring someone, I don’t try to push my ideals on someone, or assume my way and my solution is the only solution. When I look at GPL, yes, it’s my default. I always start there. But I don’t stop there and I don’t let it blind me to what things need to be, because the best solution may not be open source, it may not be GPL, and it may not be WordPress.

So long as you’re not violating a license, use what suits your needs. But do pay attention to those licenses.

13 October, 2014
The Bias of Transparency

When I was in elementary school, we used to go to SeaWorld all the time. I loved seeing the animals, I loved being able to pet and feed dolphins. I loved the whole data dump of the ocean information. I went back in the days where the trainers were in the water with the orcas. I fed one once, and patted it’s nose. I danced with a seal (and sea lion). I really fell for the whole “Humans and animals together!” patter.

And then I grew up and read about how SeaWorld got those animals in the first place.

Your personal feelings on movies like Blackfish aside, even SeaWorld admits today that they were wrong in how they captured orcas back in the day. They were cruel and wrong, and SeaWorld hasn’t done that in 35 years. But the part of me that is upset with them is the part that wants to know why it took Blackfish to make them step up and say that. And the part of me that’s livid is the part who asks why they don’t disclose their history as a learning experience?

Transparency in development is not a new thing. Technology used to be a magical black box, but the more people embrace open source, I feel they’re more willing to express their issues and explain things that have happened. Even when you don’t understand the whole explanation, being told something like “Yes, the outage was caused because some electrical work caught fire” is much more satisfying than “The outage has been resolved.”

When I talked about why an outage didn’t inspire me to change my webhost, much of the reason was because of communication. While it could have been better, my host was transparent with me such that I knew what was going on. Perhaps not as fast as I wanted it, but I did, at all points in time, know what the deal was.

Being up front about problems gets messier when you start to talk about things like security. Earlier in the year, MailPoet had a security vulnerability. They fixed it, pushed the fix, and then it was reported on and everyone found out. People were surprised to find that the exploit was hunted down by people now that the information was in the wild, and others pointed fingers at the reporters for publicizing of the issue.

It’s a double edged sword. If they don’t report on the situation, people don’t understand how important it is to update. If they do make it public, the bad guys know what to look for. That’s why you get things like the accidental DDoS from TimThumb. People knew to attack for it, and they did. It’s the same thing with the HeartBeat vulnerability or the recent Bash issue. Once a vector is found, it will be exploited.

There isn’t a perfect answer here. There isn’t a perfect balance between information and education and secrecy. We want people to know “Hey, fix this!” but we don’t have a way to tell them without telling evil people. This ends up making us want to keep secrets and hide the truth, which just isn’t going to work in the long run. The only practical answer would be to fix this as soon as possible and hope no one hits us in the meantime.

8 October, 2014
Network Rules

I love Multisite. I don’t think people use it ‘right’ but I love it. So I’ve started to make my own rules about Multisite and how to use it properly.

Only One SuperAdmin

There should be only one SuperAdmin, and you should never use that account to post. This will limit what you can do on any given day, and you’ll need a second account to mess with network settings, but this is a good thing. While WordPress lacks a sudo feature (yes, I know there are plugins), having only one SuperAdmin and locking that account tight and keeping the keys to yourself limits people’s ability to be mean to you and brute force. Extra points if you name the account something random.

Restrict Access

Only give people access to what they need. This means you limit their plugins to what they have to have, ditto themes, and you don’t let them argue they need the unicorn.

You knew I’d pull that one out, right?

Be mean and say no. Don’t let someone be an admin of a hundred sites if they only need to be admin of one. Don’t let them be members of sites they don’t need to write on. Remember, Multisite makes you a pseudo-subscriber so a user will be able to read and comment on all sites on your network. They only need to be a legit member if there’s a real reason, like it’s a locked site.

Don’t Network Activate Things

Perhaps this is better said as follows: Only network activate things that must be network activated.

Is it ‘easier’ to network activate W3TC and configure it for your network? Sure! Should you? Probably. But what about Jetpack? Does everyone need it? Do they all need the tool for GUI comments when not all the sites even use comments? Be judicious and cautious when you network activate plugins.

Test All The Things

Vet your plugins and themes before you install them. Test your upgrades on a non-production site. I cannot stress this enough. Test, test, test, test! Test! Just … test okay?

What are your rules?

I asked on Twitter and Tim Moore said he turns off the plugin menus for subsites. You can do this very easily by going to Network Admin -> Settings -> Network Settings and uncheck the plugins box for “Enable administration menus.” I do sort of wish we had more things there, like disable themes and so on, but seeing as you can more granularly control themes anyway it doesn’t matter that much.

5 September, 2014