Podcast Episode

488 – How to Submit a Plugin to the WordPress Repository


Is there a plugin for that?

With more than 50,000 plugins in the WordPress repository, it’s hard to find the perfect one. Each week, I will highlight an interesting plugin form the repository.

For more great plugins, download my 50 Most Useful Plugins eBook.

WP Scheduled Posts – Missed Schedule & Best Editorial Calendar manages your schedule through an editorial calendar and enables you to auto schedule your posts.

How to Submit a Plugin to the WordPress Repository

You can submit the plugin to the WordPress Repository here:

The plugin must follow all these guidelines:

Thank You!

Thank you to those who use my affiliate links. As you know I make a small commission when someone uses my link and I want to say thank you to the following people. For all my recommended resources, go to my Resources Page

Full Transcript

Business Transcription is provided by GMR Transcription.

On today’s episode we are going to talk about how to add your plugin to the WordPress repository. Right here on Your Website Engineer podcast, episode No. 488.

Hello and welcome to another episode of Your Website Engineer podcast. My name is Dustin Hartzler and I’m excited to be here with you today and I hope that all things are well and that you are staying at home and slowly getting back into what is going to be a long transition into the “normal” way of life. I’m still working on lots of projects around here and I’ve got so much stuff to do around the house. It’s okay that we can’t go anywhere for quite awhile, but today I wanted to start off this show with a song. It’s called WordPress Strong and it’s made by the community and it’s just a minute long – minute and 20 seconds – and you can watch it on YouTube. I’ll put a link to it in the show notes, but this is a little bit about – just a whole handful of WordPress people coming together and recording. They did individual segments and then it was all meshed together and it’s on the GravityView YouTube channel. So, it’s all about WordPress Strong. Let’s go ahead and listen to it and then we’ll dive into the rest of the show.

One third of the entire web cannot be wrong
We raise our voices up in a unified song
Screen to screen to screen we march along
That’s because we are WordPress Strong

WordPress Strong
(WordPress Strong)
Friends you can count on
WordPress Strong
(WordPress Strong)
Friends that go beyond
Anything you need,
Just call on the community
That’s WordPress Strong

Someday we’ll be together again at WordCamps
Till then do the WordPress wiggle (Yeah, you can d ance!)
Wapuu so cute he’ll keep your anxiety calm
And singing about how we’re WordPress Strong

WordPress Strong
(WordPress Strong)
Friends you can count on
WordPress Strong
(WordPress Strong)
Friends that go beyond
Anything you need,
Just call on the community
That’s WordPress Strong

And, that is WordPress Strong and if you listen in there about halfway through, there was a little cameo there by Matt Mullenweg. So, be sure to go and watch him do a little bit of a dance as part of it. It’s just kind of a neat way for the community to continue to support one another and just really interesting and neat that we are in this community together. And, if we can’t go outside or we can’t interact with friends, just know that our online community is still there. The other announcement that I wanna share with you this week is all about Word – or Local by Flywheel release of version 5.3.1 and this is the latest version and it just adds some new things to their dashboard. It allows you to filter different sites. So, if you’ve got hundreds of sites in there, you can easily filter to the ones that you need and they fixed a bunch of bugs and whatnot. So, if you are a Local by Flywheel desktop user, then I recommend updating to the latest version.

Also, in the news – or also in a plugin that I wanna share with you today is a plugin called “WP Scheduled Posts and Missed Schedule Post and Best Editorial Calendar.” It’s got a gigantic name, but it is by the folks over at AppSumo, and it’s a complete WordPress solution for managing your post schedule. So, you can manage with a calendar and it allows you to have things go off when you’re not around and all those good things. So, it’s got a great visual calendar. There’s a dashboard widget. So, when you first log in to your WordPress site, you can see the scheduled and draft post right away from the WordPress dashboard. It’s got drag and drop features and it saves just time on content creation. You can add things directly from the dashboard. If you wanted to do an image post or whatever, you can do that right from the WordPress dashboard.

And, so, that is the plugin that I want to share with you today. It’s called “WP Scheduled Post” and you can find it on the WordPress repository – searching for that – or you can find it in the show notes for episode No. 488. And, just as a reminder, you can always get to a specific episode by listening to YourWebsiteEngineer.com/ and then the episode number. So, this is YourWebsiteEngineer.com/488.

Okay. Thinking through what we were gonna talk about today and I’ve just been kind of mulling around lots of ideas of what we can talk about on the show that I haven’t talked about in the last 487 episodes. But, I kinda stumbled upon looking at plugins and figuring out what plugin to share, and then all of a sudden I noticed that my plugin was outdated, ‘cause I haven’t updated it in awhile. It looks like I need to spend some time doing that today. It looks like WordPress 3.6 or higher is the latest version and it has been last updated two years ago. Just life has gotten busy and whatnot, so I’ve got to spend some time updating that.

But, I wanted to spend a little time today – and we’ll kind of probably talk about plugins for the next couple episodes because there are tons of plugins out there, as you know. Let’s get an updated count – is 56,171 plugins and anyone can submit a plugin to the WordPress repository. And, I just wanted to take a few minutes to tell you the process and what that looks like. So, basically, you can go to a page on – the WordPress plugins page is WordPress.org/plugin/developer/ad and this is where you upload your file. It basically has to have a zip file that’s less than 10 megabytes in size, and then there is a manual review process. Somebody who is actually gonna go through and look at the code and make sure there’s nothing malicious and whatnot in there, and it’s reviewed for common errors and whatnot.

Looks like, right now, there are 21 plugins awaiting review. So, it could take a little while. I’m not sure how big the team is or how many they get to, but 21 isn’t quite that many. I think I remember back when I submitted my plugin – it was probably in 2012 or 2013 – and I think there was hundreds of plugins waiting to be reviewed. And, I just luckily was able to be at a WordCamp where we were talking about how to do this and Pippin Williamson, who is the founder of Easy Digital Downloads and runs that whole company over there at Sandhills Development, he was there and he’s like, “Well, I can review it. Just put it in there and then we’ll review it real quick and we’ll talk through it.” So, I got kind of a neat way to get a plugin in the repository very quickly, but 21 plugins – that should only be a week or two I would think until your plugin would be approved.

There’s a couple questions or a couple things I wanted to share. Like it can take anywhere between one and 10 days. They attempt to review all plugins within five days of submission, but the process could take a little longer than that depending on the complexity of your plugin. And, then, your plugin will be uploaded to the WordPress repository. It basically takes your plugin name and then puts dashes between it. So, if your plugin is – mine’s called “As Heard On” and so mine’s at https://WordPress.org/plugin/as-heard-on and that’s the slug. If there is something that has the exact same name, then it would be “as-heard-on-2.”

And, then, if you have any mistakes or you have any problems, don’t necessarily resubmit. Make sure that they have approved it or they go through the process and then there is a – if the plugin review team says, “Oh, hey. We need to make some changes or we need to make some customizations.” You get that and then you can make and upload those changes again. So, that is kind of the submission process.

But, I wanted to talk through today what some of the guidelines are because we’ve talked about these plugins in the past, and a plugin can be as simple as four lines of code that basically adds a checkbox, or deactivates a checkbox, or does something very, very simple to your WordPress site. But, I just wanted to kind of talk through just what the repository is and some of the things to keep in mind – some of the guidelines for creating your own plugin. And, the plugin directory – the goal of it is to provide a safe place for WordPress users from the non-technical to the technical – the very developer type people – to download plugins that are consistent with the goals of the WordPress project. To that end, we want to encourage the simple and transparent process for developers to submit the plugins to the directory, as our ongoing efforts make the plugin directory inclusive. It’s more transparent.

They’ve created a list of guidelines and here are those guidelines: The plugin must be compatible with the general public license. So, it basically means they’re GPL compliant and this is pretty standard. Most themes are GPL compliant. WordPress itself is GPL compliant or whatnot. So, that is something that – the first guideline. The next one: Developers are responsible for the contents and the actions of the plugin. It’s the sole responsibility of the developers to ensure all files within their plugins comply to the guidelines. Intentionally writing code to circumvent the guidelines or restoring code that they were asked to remove is prohibited. It is under the illegal or dishonest actions. So, that is the second one. Just make sure they’re responsible for the actions of the plugin.

The stable version must be available from the WordPress repository directory page. You can develop your code elsewhere, but users need to – developer need to be able to download the latest version from the WordPress environment. Distributing code via alternative methods while not keeping the code hosted up to date may result in a plugin being removed. So, if you upload a plugin to WordPress and say that – “Here is my latest version,” and then in your README you say, “Here, download it from over here on my GitHub – ” It’s not best practice and you may get removed from the WordPress repository. Code must be mostly human readable. This basically means that you can’t use any type of functions or whatnot to obfuscate any feature or uglifying the – there’s a bunch of different ways that you can just kind of hide your plugin code. This is not allowed. They want to be able to see exactly what your plugin is doing.

The fifth thing is that they don’t allow trialware. So, plugins may not contain functionality that is restricted or locked only to be available by payment or upgrade. Functionality may not be disabled after a trial period or quota is met. So, basically, the paid version of your plugin is allowed but it needs to be a premium version that adds features. You can’t remove features from a plugin on the WordPress repository. You can add features in a pro version and you see that a lot. You see Yoast Pro and Pretty Links Pro and a bunch of these plugins have gone pro now. So, that’s kind of how they get away with not having a trial. You have to offer all your features that you want in the free version, and then to add additional features comes in the pro version.

Software as a service is permitted. So, plugins that act as an interface through some sort of external third-party service are allowed, even for paid service. So, this is kind of like – let’s see…OptinMonster is a good example. OptinMonster has a free plugin and the plugin has all the features there, but in order to use OptinMonster, you have to have the paid SaaS service for it to work. So, that is how software as a service works.

User – or plugins may not track users without their consent. And, so, in interest of protecting user privacy, plugins must not contact external services without explicit and authorized consent. This is usually with an opt-in method, requiring registration with a service or checkbox within the plugin settings. And, so, you can be assured when you’re downloading a plugin off the WordPress repository that plugins are not tracking you unless you give them explicit permission to track your events and whatnot. And, I think WooCommerce does this. It says, “Would you like to send the developer details on crashes or things like that?” And, that is acceptable inside the WordPress repository.

Plugins may not send executable code to third-party systems. Basically, this is using – or externally loading code from document service is permitted, but communication must be made as securely as possible. Executing outside code with a plugin when not acting as a service is not allowed. So, an example is serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org, installing premium versions of the same plugin, calling a third-party content delivery network for reasons other than font inclusions. All non-service related JavaScript and CSS must be included locally. Things along those lines. So, a plugin’s not going to be installed and then all of sudden it’s getting font files from Google and JavaScript loaded from all these different places and whatnot.

The ninth reason – or the ninth guideline – is developers and their plugins must not do anything illegal, dishonest, or morally offensive. So, this basically is artificially manipulating search results via keyword stuffing, black hat SEO, or otherwise, offering to drive more traffic to sites that use the plugin, compensating, misleading, pressuring, extorting, or blackmailing others for reviews or support, implying that users must pay to unlock included features. All this kind of stuff is false under the guidelines of illegal, dishonest, or morally offensive.

No. 10 is plugins may not imbed external links or credit to the public site without explicitly asking permission. Any “powered by” or credit displays that are included in the plugin must be optional and default not to show on the user’s front-facing website. User must opt-in to display any and all credits to links clearly stated in understandable choices, not buried in the terms of service, or documentation, or whatnot. So, basically, if you install a plugin, it’s not going to credit your site at the bottom of it – automatically hook into the footer to say, “You are using Gravity Forms,” or things along those lines.

No. 11 is plugins should not hijack the admin dashboard. Users prefer and expect plugins to feel part of WordPress. Constant nags and overwhelming admin dashboard and unnecessarily alerts detract from this experience. [Inaudible] [00:13:38] prompts, notices, alerts, and the like must be limited in scope and used sparingly, be that contextually or upon the plugin’s settings. Sitewide notices or imbedded dashboard widgets must be dismissible or self-dismissed when resolved.

And, I think that some of these – and granted, I don’t know if these are all WordPress hosted on the repository plugins, but I’ve seen a lot of WordPress sites I’ve logged into and then I have to scroll before I can actually do anything. There’s so many admin notices. And, so, this was something that they’re looking for and they’re making sure that they’re not – I don’t think they can catch all of them that come into the WordPress repository, but they definitely can make sure that you’re using them sparingly and they’re using them appropriately.

No. 12 is public-facing pages on WordPress.org. The README’s must not include spam. And, so, we have pages that have README’s and translation files may not be used to spam. Spamming behavior includes – but it’s not limited – unnecessary affiliate links, tagged a competitor’s plugin, to use over 12 tags total, black hat SEO’s, all that kinda stuff. So, we can’t have that in your plugin. No. 13 is plugins must use WordPress default libraries. So, there’s useful libraries built into WordPress like jQuery add-on, SimplePie, PHPmailer, PHPass, and more. You must use those if your plugin is using those types of things.

No. 14 is frequent commits to a plugin should be avoided. Basically, the SVN repository is the release repository and it’s not the development one. So, you can have lots of commits, and code, and README files. You don’t wanna have these plugin update all the time. If you make one change to a plugin, you don’t want to release that as a new update unless it’s a major one that needs to be replaced and fixed right away. But, for example, if you’re adding four or five new features, you can build those into your plugin, release them all at one time as the new version. So, No. 14 is to not have frequent commits to the WordPress repository. No. 15 is make sure there’s virgin numbers. Each one must be incremented for each new release. That’s how the triggers are – that work. So, you can see an update in your WordPress dashboard and that WordPress SVN system knows that you’ve released another version.

And, then, just a couple more here. A complete plugin must be available at any time of submission. So, plugins are examined prior to approval. That’s why a zip file is required. Names cannot be reserved for the future or to protect brands. And, so, what that means is the directory name is only given to somebody that has the full plugin and a plugin that has been submitted to the repository. Plugins must respect trademarks, copyright, and project names. And, so, use of trademarks or other projects for the sole or interim term of plugin slug is prohibited unless the proof of legal ownership representation can be confirmed. For example, the WordPress foundation has trademarked the term “WordPress” and it is in a violation to use “WordPress” in the domain name. And, so, this applies to plugin slugs and so you can’t have a slug that has “WordPress” in it. So, you can’t name your plugin something with the name “WordPress.”

And, then, No. 18 is they reserve the right to maintain the plugin directory to the best of their ability. Basically, they can update the guidelines at any time, they can disable or remove plugins from the directory for any reason not explicitly covered to the guidelines, they can grant exceptions and allow developers time to address issues, even security related. So, they can do all this and – again – these are all guidelines to be the best for the community and allow that community – it’s all volunteers doing this and they’re doing the best to make sure that the repository with those 51,000 plugins is in the best state it can be. And, it’s doing the very best that they can do to manage and make sure there’s nothing malicious out there, and they run scans regularly on outdated plugins to make sure that there’s no code in there that could be deprecated or may not work anymore.

So, that’s what I wanted to share with you this week. We’re gonna continue to talk about plugins and what it takes to build a plugin and some of those things in the coming weeks, but until then, take care and we’ll talk again soon. Buh-bye!