Submitting, maintaining and growing a plugin on wp.org

Editor's Notes

• #3: My answer might be wait and I’ll get to that, but would rather your questions while they’re on your mind then all at the end.
• #5: have created a plugin, even a small one for a client project have a plugin release on the wordpress.org repo already Not going through how to actually code a plugin in this talk, I’m assuming you already have one, but hopefully this will still be useful to keep the process in mind as you’re creating one
• #6: Event Calendar Newsletter story + startup hub in Hamilton, app created on the couch as drunked people threw darts here above their head. New definition of extreme Programming
• #7: I waited until I sobered up to publicly release the plugin (and you probably should too… “don’t drink and launch”?) but releasing and maintaining it had some hurdles and things to think about… which is what I’ll be going over today.
• #9: One thing we need to add to our plugin is a readme.txt file, which is required to submit to the wordpress.org plugin directory.
• #10: The readme.txt file goes inside the root of your free plugin folder, and is just called… readme.txt
• #11: You can see a sample readme.txt that you can copy and paste as a starting point, over on wordpress.org.
• #12: This file includes things important things like the short and long description of our plugin Any installation notes to install your plugin A list of frequently asked questions or FAQs A description of any screenshots you include inside the assets folder of the SVN repository on wordpress.org once your plugin is approved And also a changelog detailing what changes have been made for each new version you release
• #13: …don’t spam the tags by adding more than 12 tags, or putting any competitors’ plugins as a tag. This can get you removed from the wordpress.org plugin directory as it looks like you’re trying to game the plugin search system. You really don’t need more than 12, and just pick keywords that are relevant to your plugin.
• #14: look at other plugin readme.txt files to get ideas on what tags you might add for your own plugin
• #15: And last but not least don’t forget to validate your readme.txt file before you submit! You can edit it later before you do your initial push of your plugin, but it should validate for the plugin review team to see.
• #16: It’s easy to do using the readme.txt validator over on wordpress.org
• #17: There’s a number of rules to consider based on what your plugin is doing
• #18: This includes any libraries, images, CSS, etc you include And you should include the images/CSS/javascript within the plugin, not hosted on your own site (in case it goes down and because you can track usage)
• #19: No tracking of any kind without consent, even just what site URL the plugin is installed on It just can’t be turned on by default Wisdom plugin or Freemius Insights
• #20: Can do this after getting their permission though Can have links to your site on your settings page in the admin area no problem
• #21: Things like asking users for a 5-star review of your plugin, can do this at the appropriate time but must be dismisable
• #22: No bitcoin mining After all this and other rules, they still reserve the right…
• #23: The plugin directory team is awesome, they’re volunteers, and they really aren’t trying to make enemies and delete plugins at random. But you’re playing in their sandbox and they can remove your plugin at any time.
• #24: There’s a number of rules to consider based on what your plugin is doing to keep in mind
• #25: Ensure your readme.txt file is present and validated Package up the free plugin into a zip file, and be sure to remove the .git folder if you’ve already set up version control Submit the plugin for review Then once it’s approved, push the code up to SVN
• #26: Before you submit you’ll want to make sure you have tested your plugin with WP_DEBUG turned on, to make sure there’s no warnings or errors.
• #27: You’ll submit the plugin over on wordpress.org slash plugins slash add If you don’t already have a WordPress.org account, you’ll need to create one over on login.wordpress.org slash register.
• #28: You can’t have any auto replies, like vacation messages, come from the email address in the wordpress.org account you’re using to submit the plugin. Otherwise you’ll get a warning if you’re lucky, but likely your plugin will be removed.
• #29: Once you’ve created your account or logged in you’ll see the submission form. There’s just the 3 fields, the plugin name, a description of your plugin which you could grab from your readme file, and a link to download the zip. You can upload this wherever…
• #30: Put the zip file wherever, easiest would probably be uploading it to one of your WordPress websites and grabbing the link to it from there.
• #31: As they note on the form, the name of your plugin will get turned into a slug like this. While you could change the name of your plugin later, that url slug cannot be edited, so make sure there’s no typos and you’re happy with that name before submitting.
• #32: Once you’ve submitted the form, now you wait. You can see how many plugins are in the queue waiting for review at the top of that form, but there’s no guaranteed timeline or anything. The plugin review team are volunteers so be patient.
• #33: Once approved, you’ll get an SVN repository to submit your plugin files to with your plugin slug there. You’ll need to download and install SVN if you don’t have it already.
• #34: You’ll start your initial submit by opening up terminal and typing svn co (for checkout), then the URL of your repository. This would be somewhere on your computer outside of your WordPress installation, in your-folder-name which can be whatever you want to call it.
• #35: Inside of the folder you’ll have another folder called trunk. Inside of that…
• #36: you’ll copy all your plugin files into it.
• #37: Then back in the terminal window, type svn add trunk forward slash star, to add all of your plugin files.
• #38: Lastly, you’ll commit and push the files up to wordpress.org by typing svn ci (for commit), -m for message, then in quotes your commit message. You should receive a message that the files were successfully committed, and after a few minutes if you go to…
• #39: your plugin’s page on wordpress.org, you should see your plugin there with a link to download.
• #40: Your free version is now released and available to anyone who searches for a WordPress plugin in Plugins > Add New
• #41: You should also add at least a screenshot or two into the assets folder, and optionally an icon and header images if you have them or would like to make them. All of these make the plugin stand out when users are searching for it. There’s a link below the video with instructions on how to do that and what format it should be in…
• #42: but basically in your SVN repository you’ll see an assets folder. Inside of that you’d put screenshots and name them
• #43: screenshot-1.png, screenshot-2.png, and so on. You could also use .jpg files if you’d rather.
• #44: Then in the readme.txt file, update the screenshots section with a description of each one.
• #45: Then back in the terminal, add the assets to svn…
• #46: And commit them along with the changes to your readme.txt file, with another svn ci command.
• #49: 1.1 —- or whatever your new version number is
• #50: Started with this…
• #51: Copied trunk into tags/1.1
• #52: Will keep doing that for future versions. Don’t HAVE to do this but it’s best practice to make it easy to get older versions of your plugin if needed (for testing purposes) and keep stuff organized
• #53: Otherwise people won’t see your changes
• #54: While you need to ultimately use SVN to push your changes up to wordpress.org, you can also use git during your normal development, then pull those changes into your SVN trunk folder
• #55: Currently you have a repository with trunk folder, and your free plugin inside.
• #56: After setup, you’ll also have a git repository inside of the trunk folder. This will make it easy to pull your changes from the git repo into SVN. Don’t have time to go through the whole process but that article gives all the details… and go through the exact commands for common tasks
• #57: This causes the wordpress.org server to recreate all your .zip files for all your versions
• #59: … If it’s not needed. ie. you have an admin page for your plugin settings or whatever, just add your css/js there
• #60: … If it’s not needed. ie. you have an admin page for your plugin settings or whatever, just add your css/js there
• #61: If you’re using newer features of PHP
• #62: Let’s people extend your plugin without having to hack your codez
• #63: You don’t have to do the translations! Others might do it for you
• #64: For example with The Events Calendar Shortcode I added one underneath the Events menu of The Events Calendar
• #65: And when you click on it….
• #66: … you get to this Beautifully designed help page
• #67: Don’t let this stop you from releasing a plugin though. Even major plugins can have major issues. Jetpack 4.x then 4.0.1 still broke things, finally 4.0.2 fixed. Just be available… don’t push a release, forget to include a required file, then go to a concert with terrible cell reception… not that I’VE ever done this… Breaking benjamin is a great band by the way
• #69: They can do to Plugins > Add New and give it a go, very simple install process. Takes time but super valuable.
• #71: Not all of these tips on the freemius article are recommended and could get you banned, like creating a new WordPress account username with the keywords you want… and it says so
• #72: If my amazing write meow plugin…
• #73: … still has fewer than 10 installs it’s a pretty hard thing to do. Older plugins are much more favoured over new ones.
• #74: Takes time, but nothing beats being able to tell people they can go to Plugins > Add New, search for your plugin, and find it :)