Samuel Wood (Otto) 9:09 pm on December 7, 2018
Tags: blocks   

Blocks, Plugins, and You

WordPress 5.0 has been released and with it the new block editor for composing posts has been released.

There are exciting possibilities afforded by the new interface and we like to show off new things. So, we’re showcasing plugins that are block-enabled.

If you’ve written a plugin that introduces or improves blocks, or know of a plugin that does, email us at plugins@wordpress.org. Note that these must be plugins with their block-enabled version currently available in the Plugin Directory.

We’re featuring these plugins in a new “Blocks-Enabled Plugins” section in the directory, as well as in a new section on the WordPress Plugins homepage.

We will be doing something similar with themes soon, so stay tuned!

#blocks

Ipstenu (Mika Epstein) 7:35 pm on November 21, 2018
Tags: ,   

Reminder: We can’t rename plugins post approval.

When you submit a plugin, the plugin slug (i.e. the URL) is determined from your plugin’s display name, as set in the main plugin file. The slug can be changed while a plugin is in review but we cannot change it once your plugin is approved.

That’s why, when you submit a plugin, we send you an automatic email telling you what your slug is, and asking you to please reply immediately if that slug is wrong. We also show you what the slug will be on the post-submission page.

If you fail to tell us before we approve your plugin, you’re going to be stuck with the name you got, unless there’s an extenuating circumstance (like a legal issue, or a typo). We do not accept ‘resubmissions’ to fix the name, as we’re making every reasonable effort to get the information out there for you to act on.

Please. Make sure you read the emails. Make sure you check the slug after you submit. Tell us right away when you spot something wrong. And above all? Remember you have full control of your slug in your own submission 🙂

#reminder #policy

Ipstenu (Mika Epstein) 7:15 pm on October 22, 2018
Tags: ,   

Reminder: Plugins are closed if emails bounce

We emailed out the ‘5.0 is coming’ email and received a record high number of bounces. Over 2000. Normally we get a couple hundred, mixed in with vacation notifications (which we ignore) and auto-replies.

When your email bounces, we close your plugin because we no longer have a way to communicate with you. We even email you to tell you, just in case it’s a one-off glitch. If your email auto-replies, you get a warning. If you don’t fix this, the next auto-reply gets you closed. There are a couple exceptions to this, like the person who’s system got stuck in a loop and emailed us back 6 times for one plugin.

  • If the email was the owner of the plugin, and there’s no clear secondary owner, the plugin’s closed
  • If the email was the owner but we can tell another account is the co-owner, we transfer the plugin and email the new owner to explain
  • If the email is a committer, their account is removed and the owner emailed to explain why

Why so many?

But this number being so high was astounding to us. Like I said, it’s 10x the norm. In looking into it, we’ve determined the following facts led to this number:

  • Yahoo will delete your email account if you don’t use it for a year
  • Google reserves the right to deactivate your email after 9 months of inactivity
  • Free Windows Live Hotmail accounts become inactive if you don’t sign in for more than 270 days
  • Google email groups default to not allowing external emails.

My guess is that with GDPR being a thing, many email servers have gone ahead and deleted things. Also I suspect they changed the defaults on Google email groups, since a few of these accounts have been around for a while.

How do I get my plugin reopened?

First check that your user’s email is correct. If not, fix that. Then email us and ask if your plugin can be reopened. Most everyone has been reopened immediately. The stragglers are due to ownership issues. This is why we’re so pedantic about official accounts owning plugins. If the owner bounces but other people from the company have official accounts as committers, we’ll transfer the plugin.

What can I do to prevent this from happening?

The simple answer is “Make sure your email is up to date and functional.”

  • Add wordpress.org to your email’s white-list so you always get our emails
  • If you have a plugin that is a company plugin, make sure that the plugin owner’s email us up to date, and not an auto-reply
  • If your email is an alias, make sure everyone who gets the copy of the email is an active users
  • If you use a group/mailinglist account for your plugin, make sure wordpress.org can email it (groups need to allow ‘world’ access to send to)

#email, #reminder
Ipstenu (Mika Epstein) 4:26 pm on September 26, 2018
Tags: ,   

Reminder: Respecting Trademarks Includes Icons and Banners

This is a reminder that one of our guidelines is respecting trademarks and brands.

tl;dr

Using someone else’s trademarked logo in your plugin logo or banner is a trademark violation, and they have the right to have us remove your plugin at any time.

Explanation

Normally trademark situations come up when you submit a plugin like Facerange Messenger, but you don’t happen to work for Facerange. We change your slug from facerange-messenger to messenger-for-facerange (or something to that effect) and ask you to rename the plugin to “Messenger for Facerange”. Another common instance is when we have to explain bobo-facerange-messenger.com is a violation of their trademark use, and you need to rename your domain.

As of late, companies have begun enforcing logo usage as well. Originally they were just picky about the icon or banner being only their logo, but now they’ve moved on to the use at all. What this means to you is simple: Don’t use someone else’s logo in your plugin’s icon or banner. Period.

If you don’t have the legal rights to use it, don’t. If you’re not sure if you do, assume you don’t. If you lose the legal right (like no longer being a part of PayFriend’s trusted developer program), you must immediately remove their logo from your plugin’s public facing pages.

FAQ

What happens if a company complains?

You will receive a warning via email that a complaint has been filed and you are to correct the icon and/or banner immediately.

How long do I have to comply?

0-days. Technically you’re already a violation. They don’t have to let us give you a chance to come correct, so we would appreciate it being done within 48 hours.

Do I have to push a new version of my code to do this?

Nope. Just fix the images in your assets folder.

Addendum by Otto: This includes screenshots. If you have somebody else’s logos in your plugin itself, or displayed on your service, then you might want to consider getting those removed as well.

What do I do if a company asks me to change my icon/banner?

Change it. Seriously, it’s not worth it. Make your own unique and distinct logo for your plugin. It’ll make you more memorable in the long run.

Do I have to change my display name as well?

Yes, you do. Remember: Don’t start your display name with someone else’s trademark/copyright/commonly known name. If it’s not your name, it’s not a good idea.

Isn’t this contrary to the GPL and open source?

No. Licences like GPLv2 are separate entities, and in fact the GNU supports the use of copyright in code. As for open source, it’s not above the law. Check out FOSSMarks for more information and as always, contact a lawyer with your legal questions.

Addendum by Otto: Also note that Trademark and Copyright are two entirely different things. There is no “licensing” for trademarked items. The GPL and any other license will not apply. Basically, if something is trademarked, then you need to get explicit permission to use it, in writing, or you just don’t use it.

I think it’s fair use. Will you let me keep the icon while I fight them?

Alas, no. We have to consider the directory as a whole and it’s over 60k plugins. The risk for us is too high, and we will side with the legal request.

Addendum by Otto: There is no concept of “fair use” in trademark law. Don’t use other people’s trademarks. Period.

What about existing plugins that you let violate trademarks in the slugs?

That’s because we do not have the technical ability to rename a slug without breaking it for all users. They’d be abandoned. And you can’t automatically migrate users from one plugin to another, so because of that limitation, most companies have permitted us to retain plugins that violate their trademark in the slug. Some have not, and we’ve been forced to close those plugins.

Since the logo and display name can be safely changed, it’s a different matter.

Someone else is violating too! Why didn’t you shut them down?

We email people in batches. You’re welcome to report fellow plugin devs who are violating the guideline, but the odds are we’ve already been in contact with them (or will be shortly). You’re not being singled out, we just have a lot of plugins to work through and we take breaks. Keep in mind, if it’s not YOUR trademark, we generally just warn.

Someone’s using my trademark in their icon/banner, how do I get them to stop?

Contact them first and point to this post (and the 17th guideline) and just ask them NICELY to please change it. If they blow you off or don’t respond in a reasonable time (like 2 weeks), you can email us at plugins@wordpress.org and we’ll follow up.

#guidelines #trademarks

Ipstenu (Mika Epstein) 4:07 pm on September 3, 2018
Tags: ccoc, crosspost   

Notice: Community Code of Conduct Meeting 4 Sept

The Code of Conduct will apply to all plugin developers and their support crew, so we encourage you to be aware of these developments.

Community code of conduct next meeting: 4th September 15:30 UTC

#ccoc, #crosspost

Ipstenu (Mika Epstein) 2:55 pm on August 29, 2018  

Unused Plugins Closed

I’m happy to say that at this point, all plugins that were approved and never used (that is, never had any code uploaded, ever) have been closed. Roughly 8500 plugins were closed for never having any code committed to them since approval.

In addition, the plugins that have been broken since we migrated to the new plugin backed (April last year) due to incorrect SVN usage have also been closed. They weren’t showing up anyway, so it’s not like anyone could have installed them in the first place.

This means we currently have 700 plugins that have been approved and never used, dating back to April 2017.

Going forward, we’ll be holding any new submissions from developers who have an unused plugin. This means if you submit a plugin and get it approved and immediately turn around and submit a new one, we won’t even review it until you actually use the approved one.

This is not a change to guidelines. We already require you to provide a stable version of your code from our SVN service, so this is simply a means to enforce that guideline. If you have hosting, you’re expected to use it.

Ipstenu (Mika Epstein) 9:23 pm on August 23, 2018
Tags:   

Guideline Update: Clarifications to trialware and human readability

Two situations have arisen where we feel it would be best to clarify the guidelines a little.

Guideline 4: Human Readability

We strongly feel that one of the strengths of open source is the ability to review, observe, and adapt code. By maintaining a public directory of freely available code, we encourage and welcome future developers to engage with WordPress and push it forward.

However with the advent of larger and larger plugins using more complex libraries, people are making proper use of build tools (such as npm) to generate their distributed production code. In order to balance the need to keep plugin sizes smaller while still encouraging open source development, we will be requiring plugins to make the source code to any compressed files available.

For example, if you’ve made a Gutenberg plugin and used npm and webpack to compress and minify it, you must either include the source code within the published plugin or provide access to a public maintained source that can be reviewed, studied, and yes, forked.

We strongly recommend you include directions on the use of any build tools to encourage future developers.

Guideline 5: Trialware

Historically we’ve not permitted test or trial plugins that arbitrarily limit usage, and then upsell, to be included in the directory. The primary reason we don’t permit this is that locking people down to a specific number of (say) images is foolish and a pointless endeavour. People can, and will, fork your locked plugin and unlock it, as well they should. That said, we’ve always allowed (and will continue to) plugins that offer a free limited service (think Akismet for a good example).

Related to this are ‘sandbox’ plugins, used for testing. For example, if your plugin only accessed the Instagram Sandbox API, and included upsells about a pro version that allowed full access, you would be a trial plugin. Since they are easily abused as turning the directory into a marketplace, we have modified the 5th guideline to address this more clearly.

#guidelines

Ipstenu (Mika Epstein) 11:07 pm on June 27, 2018
Tags:   

Reminder: Check your Boilerplates

Boilerplates are hugely popular and can save you a lot of time getting started. That’s great.

However … The number one reason for plugin pushback this year is this:

define( 'PLUGIN_NAME_VERSION', '1.0.0' );

Please remember to check the defaults in those boilerplates.

#reminder

Konstantin Obenland 9:06 am on June 13, 2018
Tags: 3539-meta   

Document Titles for Repo Plugins

The Growth Council has submitted its proposed updates to document titles and meta descriptions across the WordPress.org network. As part of the update for the Plugin Directory, they suggested adding the first two tags of each plugin to the document title:

$Plugin_Name, $Tag_Name Plugin | WordPress.org

Example:

Obenland Media, Gallery Plugin | WordPress.org

Before going ahead with that change I wanted to bring it up for discussion here, given the risk of abuse here.

How do we weigh the benefit of ease of discoverability on search engines with that risk of abuse? What are your thoughts?

Progress on this is tracked in #3539-meta.

#3539-meta

Ipstenu (Mika Epstein) 7:46 pm on May 17, 2018
Tags: core, , privacy   

WP 4.9.6, Privacy, Hooks, and You

WordPress 4.9.6 has been released. This was a focused release, a little different than other minor releases, in that it adds a system for a privacy policy to WordPress. While the only change to plugins has been our requirement that you not claim (or imply) 100% compliance in anything, the changes to privacy awareness are far reaching.

The tl;dr of the whole post is “You’re going to need to consider the impact of data collection in your plugins, even if you don’t collect anything.” So yes, I know it’s long, but please read the whole thing.

NOTE: We are not lawyers. We cannot tell you if what your plugin is doing is going to break a law. Please don’t ask us to try and figure that out for you. The purpose of this post is to make you aware of what’s going on, and give you a place to start with making your plugins better.

Does This Impact You?

Yes. This impacts everyone. Plugins are used internationally which means you actually do have to be aware of the world, Net Neutrality shenanigans aside. Your plugin could, in fact, cause someone to get in legal trouble. While that is technically their responsibility, you should be as aware as possible of the implications of your code and how it’s used.

Ask yourself this: Does your plugin…

  • … write any private data of users (registered or visitors) to the database?
  • … send any data to remote servers (i.e. act as a service or embed content)?
  • … edit the comments form in any way?

If yes, then this absolutely, without a doubt, impacts your plugins.

If no, then this may still impact you, so please keep reading, because people are going to ask you about this.

Privacy Means Disclosure

If you’re a service, like you pull a library from a remote server, then you have to tell people that you pull data remotely. This has always been a policy, so if you’re not disclosing this now, please go fix it right away.  But you also need to tell people the obvious things, like embedding content via your plugin means the site administrator is consenting to the embed terms of that service.

An example for you. Let’s say you have a plugin that embeds YouTube playlists. Your plugin should be clear “This plugin embeds YouTube Playlists.” We also recommend you include a link to YouTube’s privacy doc. It’s alright to say “By using the embed features in this plugin, you will be agreeing to YouTube’s Terms of Use.”

The same holds true now for data stored locally. If your plugin stores browser data of visitors, then yes, you need to document and disclose this. You can’t force site admins to publicize this in turn, but by making sure they know, you’re helping them determine what their own reasonable disclosure should be.

Some Code To Help

WordPress has gone the extra step to make it easier to make a privacy page and hook into it, both for users and developers. The moving parts you need to be aware of are the tool for users to request an export of all the stored data associated with them on the site. There’s also a tool for users to request erasure of that same data. Both tools include admin workflows to fulfill those requests. And there’s one to suggest what kind of text should be on someone’s site.

The handbooks have been updated to help you out here:

Also, while this is a little more aimed at theme developers, if your plugin happens to mess around with comments, please read the changes that affect themes, as there is going to be a new checkbox for comments.

Update Your Plugins

The tl;dr of all this is that plugins should…

  • … disclose what user/visitor information it saves in the readme;
  • … hook into the privacy page creator to inform people there too;
  • … provide a way to export said information;

We aren’t (currently) changing any policy to require all this. At the same time, I strongly recommend at the bare minimum everyone put a privacy policy in your readme. Even if you don’t save any data and you don’t send anything, make a Privacy Policy anyway and tell people that.

Why? At the very least, it may stop people from asking you “Is this plugin collecting any data?” which saves you time. But more importantly, this is to protect yourself. After all, if people come through with a 1-star review that you caused them to become non-compliant because you didn’t disclose local data collection, well, that would be a very justified review.

#core, #guidelines, #privacy