WordCamp Notes: Lessons Learned Releasing My First WordPress Plugin - Jamie Bergen

1. Scratch your own itch
think about pain points for YOU
if you built it, YOU would want to use it
will help you feel invested in the project

"wouldn’t it be nice to have..."

more than 50,000 plugins available for wordpress

old plugins that haven’t been updated in a few years
opportunity to do things in an updated way

things to consider when building a plugin --

tools / techniques
using OOP, keeps conflicts w/ other code low
actions and filters to hook into
jQuery ajax to make a smooth UI
version control - git / svn
xdebug for PHP debugging
linting w/ php code sniffer

security considerations
what skill level does a user need to be to access this plugin
data validation and sanitization
nonces - before you save to d/b, confirm it was coming from the form you EXPECT it to come from

data handling
storage - put it in an existing db table or a custom one?
safe database queries
API uses

working w/ multiple sites?
accessibility?
localization / internationalization?
make sure it works on different operating systems

2. if it's worth doing, it's worth doing BADLY
permission to say "i want to build a thing." mistakes are ok if htey happen

     how?
     1. adding a new column to the plugins table

3. if you're not uncomfortable, you're not learning

knowthecode.io
wpsessions.com
great resources for building WP plugins and best practices
good video tutorials - process of building a plugin start to finish

WordPress Plugin Handbook
Pippin's Plugins blog
Delicious Brains blog

OOP PHP
WP Plugin boilerplate is really helpful for this
 can cut out what you don’t need
good foundation to start

jQuery / ajax

wp_kses() - to filter notes, strip evil scripts
wp_create_nonce()

internationalization -
__(), _e()
esc_html__()
esc_html_e()
mark strings so people can provide translations of strings in your plugin
poedit to create the translation file

how to test the plugin
basics -
does the thing you want it to do
doesn’t do the thing you don’t want it to do

also -
different user roles
diff browsers, operating systems,
multi site, translations, accessibility
ask others to test - encourage them to look for edge cases
     not looking for people to compliment you.
     consider bribery
     want people to BREAK your plugin in new ways you didn't think of
     look for edge cases

process for submitting plugin to the repo -
upload plugin as a zip file to wordpress.org/plugins/developers/add
unique slug will be derived form plugin name
go into repo BEFORE you submit to make sure you have a unique slug
reviewers will check for common errors and guideline adherence
they WONT test your plugin to make sure it does what you expect. so your OWN testing is really important

once approved - refer to links provided in the email about using Subversion, readme.txt, and plugin assets

*** bugs will surface at the worst possible times.

wp_normalize_path() - to get consistent file paths between windows and linux servers

** you're going to make mistakes. treat them as learning opportunities

*** you're not going to be able to please everyone

prerequisite for building a plugin:
1. an idea for a plugin
2. the desire to learn to build a plugin
3. the time to do it well

@shoptalkshow - "juist build websites"
podcast?

@jamiebergen
jamiebergen.com