startups and code

WordPress Plugin Development - My next attempt

← Back to home

Writing a WordPress Plugin is extremely easy to do. Writing a good plugin, adhering to coding standards, best practices, documentation, naming conventions, etc... is not as easy.

Its been a while since I have written a plugin, written a post, or written anything public. I have a lot going on right now and I'm very excited about all of it. So here I am back creating a plugin. I worked on a site for a yoga instructor and realized no plugin really did exactly what she wanted to do. So I wrote my own. Well, I want to explain my journey and the things I learned in creating it.

First, before you go looking for my new plugin, it has not been approved by WordPress yet, they are super busy and when it gets approved, I'll be sure to let you know.

Now, that being said, let me go into some details of the "where to begin" and what I experienced.

What am I trying to accomplish with a plugin?

In this case, I wanted a simple popup that allows users to enter name and email. I want it sticky on the right hand side and it will open a form that has a message of why they want to submit it, and allow them to get on our mailing list. "Oh, that is simple enough, I'm SURE that there is one out there that already does that!". So let's see, popup contact form... 124 results... one of them has to do it... Oh, this seems great, let's try it locally... I need to setup another account to send an email from? Uh, no. Ok, how about this one... Man, it doesn't even work! Ok, let's try another one... if I buy the enhanced edition... oh man... ok.. one more.. Oh, this is good... but wow, that really has hard-coded paths and doesn't use the built-in options to save? Well, it is the best start, let's see what I can learn from them.

Just because the plugin is on WordPress does not mean it is a good template for your code

I started fixing some naming conventions that just make me twinge when I see it used incorrectly. I actually tweeted about the naming convention and reached out to someone I know who has best practices against the codex (Thanks Tom).

So let me clarify something. I am not a perfect coder. I am not the best developer I know. However, I do try to do my best and always look for opportunities to learn new best practices.

Here is what I learned:

Now there is a lot of documentation out there, but here is what I found out for naming conventions...

JavaScript: function ltmMyFunctionName(){...}; PHP: function ltm_my_function_name(){...}; CSS: .my-class-name{...}

Now, that was just the tip of the iceberg of what is best practices. Now, I noticed that some people create their own tables and save configurations, and then load them. AHHHH!!! So much work and not needed. settings_fields, register_settings, and the whole settings api handles so much for you. Post to the options.php page and TADA! LOVE THAT!

Ok, next thing I learned is submitting a form is not complicated, but you can over-engineer it and make it really painful.  :-)   My first attempt at submitting an email form was posting to a php page, sending the email through wp_mail and setting up everything, making sure I required the wp_config.php so I could reference the wp functionality, because well, it worked... and then after configuring email locally to test, it worked.  Wow, what a great plugin... I did it!

Just because it works, does not mean it is right

I looked at my code the next day and was embarrassed.  I am a better developer.  I got lazy and saw that it worked.   So I started doing some investigation and realized that their is a better way to make an ajax call, an not have to setup my own request, and everything else I originally did (you can see the logs in my github).  What an opportunity to write better code, not because I'm getting paid, not because its my job, but because it is my reputation and who I am.  So I did.

I now know about wp_ajax_nopriv_my_function_here and wp_ajax_my_function_here.  I know JavaScript pretty well, so making the call and kicking back a response was pretty trivial once I learned the hook and registration process.  All in all, I wrote better code.  I took the time to clean it up, and the next thing I want to do is document better.

I treat my development with a special sense of pride.  Why?  Because I care what I am putting out in the world.  I care about how others look at my code.  I want to be a better developer each day.  That only comes with attention to detail, pride in my work, and always ask the question, "What if I showed this to Dr. Nino?".  For anyone who attended the University of New Orleans Computer Science Program, you will always think twice before submitting code.   He made me a better developer.  There are so many people along the way that would suggest little things to make me better.  I listen.  I know I don't know everything, and I know that I am around some pretty amazing people at my current job.

Well, that was my insight into the world of plugin development round two.  Hopefully round 3 will be even better.  Take pride in your work and realize your code is affecting others... help us all get better by writing good code.

Thanks for stopping by!  Glad to be back!