Just a quick note.. Due…

Just a quick note.. Due to the Thanksgiving Holidays followed up by the entire team being at WordCamp US in Philadelphia this weekend, plugin approvals and even emails to the team will be delayed. Don’t worry, we’ll deal with the backlog when we all return home to our comfort zones. 🙂

Known issues with pre-commit to the plugins SVN

Have you seen this recently?


$ svn ci -m 'commit first version of plugin'
Adding trunk/readme.txt
Adding trunk/my-cool-plugin.php
Transmitting file data .......svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

***********************************
PHP error in: my-cool-plugin/my-cool-plugin.php:
Errors parsing my-cool-plugin/my-cool-plugin.php
***********************************

A couple weeks ago, the PHP “lint” part of the SVN pre-commit check was changed from using PHP 5.4 to using PHP 7.0. Somewhere in that process, something got broken with regards to the output of the error messages resulting from this check. So, none of the errors show up.

This can be confusing, especially if you’re not running PHP 7.0 yet, because PHP 7 is actually a lot more strict about this sort of thing. You can run the PHP lint process yourself on your own files all day long and not see what the issue is, because it *only* comes up in PHP 7.

My advice: Grab a copy of PHP 7 for your machine, and run “php -l” on the file you’re getting an error message about. There is a valid error, you’re just not seeing it on older PHP versions, which were not quite so picky.

One known case that seems to be cropping up a lot:

The “break” and “continue” keywords are only valid inside a for, foreach, while, do-while, or switch structure. You’ll get the error message of “Fatal error: ‘break’ not in the ‘loop’ or ‘switch’ context in my-cool-plugin.php on line 123”

We’ve been seeing code that has something like this in it:

if ( is_thing() ) {
  do_thing();
  break;
}

And that is invalid in PHP unless that if is inside a loop. But, previous versions of PHP didn’t show the problem in their lint processes. Not so with PHP 7.

So, make sure to check your code with PHP 7. It’s no fun for people using the newest systems, like we always recommend, to be running into syntax errors. Note that these were actually syntax errors in previous versions of PHP as well (using break and continue makes no sense outside of a loop structure), but now you’re getting told about them by the lint process.

We’re still working on finding the bug not showing you these errors in the pre-commit checks too. 🙂

Edit: Any plugins uploaded to the directory should still be PHP 5.2 compatible. Just because we’re allowing PHP 7 code doesn’t mean this is a free-for-all.

Look at https://wordpress.org/about/stats/ . This isn’t complicated. Your main plugin file can be installed and activated on any of those sites. If you have even 5.3-only code in that main file, then you are responsible for breaking that person’s website, and *you* will get the appropriate review from them for doing so. And we are not going to delete that review just because you ask nicely…

Make your plugin handle failure cases properly. If you want to limit your userbase, then you’re welcome to do so. But do it right. Add code to the plugin to fail gracefully on older systems.

On the Topic of Selling Your Plugins…

Unlike the title might suggest, this post is not about buying a plugin from a commercial author, or the viability of “freemium” plugins in the directory, or app stores, or anything of that sort.

This post is directed squarely at plugin authors.

Question: Who owns your plugin?

The answer is simple: You do. You wrote it. You hold the copyrights on it.

Now hold on a minute (one might say), everything in our directory is GPL or compatible. Isn’t that copyleft? Well, yes, and I’m not going to go into excessive amounts of legalese here (IANAL), but the GPL is built on top of copyright. It actually requires it. So yes, you do own the copyrights to your plugin, even when it’s available for free in the WordPress.org plugin directory.

And yes, that totally means you can sell those rights to somebody else. We won’t stop you. Heck, if you ask, we’ll even help you perform the transfer correctly.

Now, while we’ve talked about this before, it’s worth re-iterating because it has come up a lot recently: your name is on that plugin. If you sell it to some scummy spammer, then your name is likely to get dragged through the mud. Not by us, of course, we don’t name names. But other people do notice bad things happening, and they tell other people, and make posts in our forums, and leave bad reviews… and before you know it, you can get a bad rap for something you didn’t even do.

There have been a lot of reports of various unsolicited emails recently asking plugin authors if they would sell their plugins. Sometimes these are legitimate offers. Not often. Usually it’s from marketing agencies looking to add backlinks.

In a couple of notable cases, some of those plugin authors asked what the person was planning on doing to change the plugin. Surprisingly they responded and told them. Let’s just say that these plans are very much against our guidelines.

In at least one case, the plugin author told this prospective purchaser as much, and the person responded by asking how long it would be in the directory before we shut it down, and how many sites could he get the code to before getting this noticed and thus removed from the directory. He even asked whether it was a manual or automatic process (hint: it’s both).

Yes, this guy was actually that blunt about his plans.

While my evidence is slim, I believe this particular person is a Russian spammer or hacker looking to add malware into the plugins and get this code onto as many sites as possible before we put a stop to him.

What can I say? WordPress is a big target. Some are going to try to abuse the system. We’re used to that. Now you plugin authors will need to get used to it too, because you can be a target for this sort of thing as well.

People offering to buy your plugin are generally spammers. They’re probably using fake email accounts, and offering you false information as well. They may be able to pay you, but understand that what they’re looking for is to buy heaps of unrelated plugins, modify them all with SEO spam like backlinks or potentially even malware, and get our systems to push those things to as many sites as possible before we notice and shut them down hard.

Do you really want to sell your plugin to somebody like that? Do you want your hard work to be abused and to have your good name tarnished?

Think twice before selling your plugin. Know the person you’re selling it to very well. Ignore unsolicited emails from people you don’t know. If they are going to pay you based on the number of “Active Installs”, then just don’t even consider it.

Don’t worry about the plugin review team too much though. We can find and shut these things down very quickly, even in real-time. But it does help us quite a bit if you ignore these types of scammers too. 🙂

But if you do decide to give your plugin to somebody responsible and real and who actually cares about it, make sure they know about the Plugin Directory Guidelines. Because hosting a plugin in the WordPress.org Plugin Directory is a privilege, not a right. We can and will act to remove and stop plugins in our systems from doing bad things, no matter who “owns” them.

#directory, #plugins, #selling, #spam

RESOLVED Same issues that were happening two weeks…

[RESOLVED]

Same issues that were happening two weeks ago are happening again right now. I have alerted relevant parties to the problem.

For now, new plugin authors won’t be able to commit, and some plugin readme.txt files won’t get processed correctly until this is corrected.

Sorry for the inconvenience.

Edit: This seems to be fixed for the moment, we’re working on preventing future recurrences.

ETA2: If your plugin is still missing, we know and we’re working on it.

Plugin Translations for All Plugins

We have not mentioned this here yet, but since Matt mentioned it in his State of the Word talk yesterday…

The WordPress.org plugins directory has the translations import mechanism currently enabled for all plugins. The update will happen for the plugin at the time of the next commit.

To break down what this means into details:

  • When you commit the plugin, it will get read by the translations system.
  • All the strings for the plugin will be imported into the GlotPress install at https://translate.wordpress.org.
  • The plugin will become available for translators and language packs.
  • A message detailing the import will be posted into the #meta-language-packs channel on Slack.

That last part has not been widely mentioned, but that is there for debugging and so you can find out what has happened or gone wrong.

Here is an example of a problem: (I picked this at random, I’m not judging anybody here 🙂 )

Import of ewz-rating
​_Time: Sun, 06 Dec 2015 15:23:20 +0000, Development Log_​
Code for stable (ewz-rating/tags/1.0.0/) in process...
This plugin has no text domain declaration in the file header.
This plugin doesn't use `load_plugin_textdomain()`.
Code for stable was processed.
Readme for stable (ewz-rating/tags/1.0.0/) in process...
The GlotPress projects were created.
Result of the POT import: 57 new strings added, 0 updated, 0 fuzzied, and 0 obsoleted.
Readme for stable was processed.

The problem for this one is simply that the plugin is missing the proper Text Domain header, as well as not having any calls to load the plugin text domain. So, obviously, for this plugin, language packs will not work.

Here’s one that worked fine:

Import of docu
​_Time: Sun, 06 Dec 2015 13:45:53 +0000, Development Log_​
Code for stable (docu/tags/1.5/) in process...
The GlotPress projects were created.
Result of the POT import: 37 new strings added, 0 updated, 0 fuzzied, and 0 obsoleted.
Results of the inital translations import:
Code for stable was processed.
Readme for stable (docu/tags/1.5/) in process...
The GlotPress projects were updated.
Result of the POT import: 26 new strings added, 0 updated, 0 fuzzied, and 0 obsoleted.
Readme for stable was processed.
Import of docu
​_Time: Sun, 06 Dec 2015 13:46:38 +0000, Development Log_​
Readme for dev (docu/trunk/) in process...
The GlotPress projects were updated.
Result of the POT import: 21 new strings added, 0 updated, 0 fuzzied, and 0 obsoleted.
Readme for dev was processed.

This one updated both the trunk and tagged version of the code, so it processed everything successfully. There’s a color coding indicator in the Slack channel as well. Red for a big error of some kind, orange for issues with missing headers or function calls, and green for good-to-go. 🙂

So, if you’re having trouble with the translations for your plugin, check there for your plugin’s slug. If you have updated recently, then you probably have translation access already and might just be missing a header or something.

Now, if you don’t want to get everything sent to you about all the plugins on the Slack, then you don’t actually need to join the #meta-language-packs channel. Instead, just add your plugin’s slug to your highlight keywords, and Slack will ping you when your plugin gets mentioned. This will let you see just the info about your plugin and can be a bit easier to manage.

And again, if you already have translators for your plugin, but they don’t know how to contribute, point them to the Polyglots handbook, and consider asking the polyglots team to make them Translation Editors for your plugin. This will give them access to translate the plugin easily and to approve translations to get out the language packs to your users quickly.

#glotpress, #i18n, #language-packs, #slack, #translations

Making Better Banners for your Plugins

With the plugin directory now being converted to use language packs, it’s more and more likely that your plugin will be translated by others and available in our various international plugin directories. But banners are kind of a problem for a few of those directories.

Compare the Hebrew plugin directory to the English plugin directory. One thing you’ll probably notice right away is that the icons are on the other side. Hebrew is a Right to Left language, so the design for it is flipped. Click through to any of the plugin and you’ll notice something else: The banner image is the same, but the title is now on the opposite side of the page.

For some plugins, especially those who designed banners thinking that the title was in a fixed place, this can present a problem.

Probably the best solution is simply to make your banner work with either method. Compare Ninja Forms old banner vs. their new banner:

Old:

ninja-forms-plugin-hebrew-old

New:

ninja-forms-plugin-hebrew-new

For another example, take a look at Yoast’s SEO plugin.

Old:

yoast-seo-plugin-hebrew-old

New:

yoast-seo-plugin-hebrew-new

It’s an interesting stylistic difference, but the point is that they simply made the banner work for either case of title positioning. That’s honestly the best solution, IMO, because it also eliminates something from the banner that shouldn’t be there to begin with: Text.

Text in images is bad. It’s non-accessible. Screen-readers can’t read it. It’s non-translatable to other languages. It’s a pain. Avoid it.

However, sometimes people really like their designs. The design of a banner says a lot about the plugin, even though it’s just a big image. Some authors may want to be able to adjust their banner designs to adapt to the RTL language pages.

For this reason, a couple of weeks ago, we added RTL support to the banners. I’ve been holding off on announcing this here to make sure it worked okay, and it appears to work fine, so, here’s the announcement. 🙂

How to do it? There’s no magic to it. Just make your new banner, and name it with -rtl at the end of the name. Banner images live in the same directory as always, /assets. Nothing else changes.

An example if you want to see how this looks in the SVN: https://plugins.svn.wordpress.org/pluginception/assets/

And how it looks on the plugin page:

https://wordpress.org/plugins/pluginception/

pluginception-banner-ltr

https://he.wordpress.org/plugins/pluginception/

pluginception-banner-rtl

Strictly speaking, the banner on Pluginception didn’t need to be reversed. I only did so as a demonstration, to show you how it’s done. Nothing tricky to it.

In the future, adding support for specific locales may or may not happen. It is undecided if it is necessary, because, frankly, there’s a LOT of locales we have. Who wants to make individual banner images for 80+ languages? Best to just leave the text out of the banner instead.

Note that while the RTL banners are now active for WordPress.org, they have not yet made their way into core, so the banners won’t yet show up properly in WordPress installations. Working on it. 🙂

#directory

Creative Commons Licenses in the Plugin Directory

Back in February, the Creative Commons organization began taking steps to introduce compatibility between their licenses and the GPL. At that time, we took notice and started discussing the problems we’ve had with CC licenses in the directory in the past.

Part of the problem is that the Creative Commons licenses are so fragmented. It’s very much a choose-your-own adventure landscape for CC licenses, and many people don’t understand licensing very well in the first place (it can be confusing, I admit).

Since we require everything in our directory to be GPL Compatible, then it’s something we have to constantly scan for when even an accidental violation occurs.

Then, things became even more interesting in March, when gnu.org silently changed their compatibility page to state that CC-BY 4.0 was now considered compatible with all versions of the GPL. So, at that time, we started trying to ignore that particular case. It isn’t easy, because a lot of CC licensed code is licensed under version 3.0 of their licenses, which is not GPL Compatible. And the issue of CC-BY-SA was still very much up in the air.

However, last month, Creative Commons finally stepped up. CC-BY-SA 4.0 is now compatible with the GPLv3.

Accordingly, you can now use CC-BY 4.0 and CC-BY-SA 4.0 licensed code or images or anything else in the WordPress.org plugin and theme directories.

A few points of note:

  • Only version 4.0 is acceptable. Check before using third party code which may still be licensed using 3.0.
  • Only the Attribution (BY) and Share-Alike (SA) clauses are acceptable. The No-Derivs (ND) and Non-Commercial (NC) clauses are definitely not GPL-Compatible. Code or images using them cannot be used.
  • If the code you’re wanting to use has the Share-Alike (SA) clause, then it is only compatible with the GPLv3, not GPLv2. This means your plugin and all the other code in it must be licensed under the GPLv3. The GPLv2 is not compatible with the GPLv3.

The license compatibility page does mention that the compatibility is one-way. This is important, but probably not relevant for the most common cases we’re concerned with. The cases for plugins is likely that they want to use CC licensed code such as javascripts. The cases for themes is likely that they want to use images or other artistic work in the themes. Well, now you can do that. Just mention in the readme.txt for either where the work you’re using was obtained from, and the license that work is available under. Since you’re not relicensing the work, then one-way compatibility is not really an issue.

If you need it in simpler terms:

  • CC0 – This is equivalent to a public domain declaration, essentially, compatible with everything, and we have always allowed it.
  • CC-BY 4.0 – Compatible with any version of the GPL.
  • CC-BY-SA 4.0 – Compatible with the GPLv3 only.
  • Previous versions of CC licenses (like 3.0) – not compatible.
  • Any CC license containing “NC” or “ND” terms – not compatible.

So, if you have a favorite library or image that we’ve had to push back on you in the past for, take another look at it. The license might be compatible now. Also, if something is CC 3.0, consider asking the author of the work to bump that up to 4.0, so you can use it. It’s nicer for everybody to have more things out there compatible with each other.

(Note: everything above applies to themes too. I just don’t want to write two posts. 🙂 )

#gpl, #licensing

MySQL in WordPress 3.9 – Implications for Plugin Authors

If you’re a plugin developer and you have a plugin using any of the php mysql functions directly, then you might start to see breakage in WordPress 3.9.

See, the php mysql extension is very old. As of PHP 5.5, it’s also deprecated and will very likely not be receiving further updates.

So starting in WordPress 3.9, if PHP 5.5 is being used, the built in WPDB class will switch to using the mysqli extension instead.

What this means for your plugin is that if you’re using any mysql_* functions directly, and somebody tries to use your plugin on a WordPress 3.9 + PHP 5.5 system, then all your database code will no longer work properly. Since the mysql functions are no longer being used in such a case by WordPress, then there is no longer an implicit database connection available to these function calls.

Instead of using a direct database connection, you can switch to using the global $wpdb instance of the WPDB class to access the database. @pento gives a great rundown on what functions to use as drop-in replacements on this make/core post: https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/

Now, as this is currently limited to PHP 5.5 and up only, the amount of breakage will likely be very minor. Our stats currently show that PHP 5.5 is being used on less than 1% of installations. Nevertheless, hosts are starting to upgrade PHP versions more and more frequently. This number is thus expected to grow over the next year or two. So before your users start having broken sites, please, take the time to switch your plugins over to the WPDB based methods. This will ensure future compatibility and minimal breakage.

WordPress will always maintain backward compatibility in its own functions, so using them ensures that you’ll be good for the forseeable future, no matter what database methods are being used internally.

#php

Be the Author…

So, I’ve had this working for a while, but not a lot of people noticed, so I figured I’d spell it out explicitly.

WordPress.org plugin pages have special magic Google markup. This is what allows many of the Google tricks we do for plugin pages to work. If you’ve ever searched for one of our plugins on Google, you may have noticed that it says it’s “free” as well as showed the rating as stars and such. This is all using Google’s Rich Snippets functionality with markup from the schema.org specifications.

One of the magic tricks we do is to point to your WordPress.org Profiles page as the “author” of the plugin. It’s your plugin, after all, and you deserve the credit. But promoting the authorship is only half the picture, it helps if Google also knows who you are as an author. Then they can do something clever too:

googleauthor

This is a sample entry for one of my plugins from the Rich Snippets Testing tool. The photo and authorship info may not show up on every search result that gets my plugin up on Google’s search results, but it certainly doesn’t hurt. But to get this information to be capable of showing, Google needs to connect your profile and user information on WordPress.org with a profile and user information from Google+. To do this, there’s two steps:

Step 1: Edit your WordPress.org profile to include a link to your Google+ account. You can do this yourself, and you can see how I did it on my Profiles page. I included this link in my “About Me” section: https://plus.google.com/100201852715113506716?rel=author

Note that the ?rel=author bit is important, that’s what tells Google that you are the author here and links your G+ account to this page.

Step 2: Tell Google that you contribute to WordPress.org. To do this, go to your Google+ Profile. In the “Links” section you will find a “Contributor To” area. You need to add two links to this area:

  • The first link will be a link to your own profile page, on http://profiles.wordpress.org. This completes the connection and tells Google that you and the profile are the same person. Because your plugin page automatically links to your profile with the author information, making this connection creates an indirect authorship connection to all your plugins.
  • The second link you need to make is a link to http://wordpress.org itself. This is because Google wants there to be an explicit connection on the same domain name (not a subdomain), and so this link is required. And hey, you’re contributing to WordPress.org every time you update your plugin or theme, so well done there! 🙂

After doing both these steps, you can try your plugin’s URL in the Rich Snippets tool yourself, and voila, you’ll see the magic. Note that you may not see it in the actual Google search results for weeks, and it may never appear. Google shows snippets like these on terms of their own choosing. All you’re doing here is to give them the data that lets their engine do the magic, if it can.

#schema

Last December we added header images to the…

Last December, we added header images to the top of plugin screens. Since then, we’ve made more changes to the plugin directory and started supporting HiDPI images for those plugin headers as well.

As part of that original header update, one thing that was added which I always meant to do more with was the addition of a new “assets” directory at the top level of the plugin SVNs. This is an optional directory that sits alongside the /tags and /trunk directories, and was just used to hold the banner images. Creating a place to put plugin assets which didn’t need to be included in the plugin itself simply made sense to me.

It also never made sense to me that the plugin screenshots, which are rarely used by the plugin, needed to be included in the plugin’s ZIP file. Some plugins can use these themselves, certainly, but the majority don’t and it’s just really inflating the size of the plugin to include them.

So, starting today, you can put your screenshot files in the assets directory instead of in the main plugin directory.

A few notes, for the technically minded:

  • Screenshot naming conventions have not changed, nor have the readme.txt requirements for their captioning. The naming and behavior is exactly the same, the file can just go into a new place.
  • The old way still works too. If you have your screenshots in the plugin’s “stable” directory, then it will find them there just fine.
  • Screenshots in the assets directory take precedence over screenshots in the plugin’s directory. If you have both, then the assets directory wins. Of course, there’s really no reason to have both, this is just for backwards compatibility.
  • Like everything else in the assets directory, we are serving them through a separate static caching system, and so it may take a few minutes to update when you change them. What this means is that when you put the screenshots in there for the very first time, they may not show up on your page for a few minutes and you’ll just see the captions with no images above them. Please give the proxy some time to retrieve your screenshots and cache them before telling me it’s buggy. It should only take a few minutes. 🙂

The ultimate goal, of course, is to reduce the size of the plugin ZIP files being served. By not including the screenshots in the plugin, files are smaller and upgrades are thus speedier for everybody.

In the future, if we have a need for more “directory only” files, I expect them all to be in the assets directory as well, for just this sort of reason.