WordPress, wannabe programming & my opinions

Devtard's Patreon page


  • Posted November 21, 2012 at 6:52 am | Permalink

    Hi @Devtard,

    I heard about this plugin at WPBeginner and decided to look at it. As luck would have it I had a bug in a plugin I was testing in the WordPress installation where I activated your plugin and so your plugin broke causing me to debug into it to figure out why.

    While I was debugging my plugins interaction with yours I noticed several things that would keep me from using it unmodified on a production site (see #2, #3 & #4.) And since you said “How to contribute? – Improve my code” I assumed you would be open to suggestions for improvement?

    1. Verify that the wp_apt_tags table is not already in the database before you try to create it. When my plugin failed during activation of your plugin it left your plugin inactive but not after your plugin created the table. Trying to activate your plugin after deactivating mine caused your plugin to throw an error on your table already existing.

    2. Better than#1, use a custom taxonomy ‘auto_tags’ instead of a custom table. It’s a perfect fit for what you need, it gives you lots of “free” functionality such as caching, an API for handling all the SQL code, and it lets the user manage with the taxonomy interface. It also makes your plugin more attractive to other plugin developers (like me) who prefer their plugins don’t add custom tables unless overwhelmingly necessary.

    3. Create a single entry called ‘automatic_post_tagger_settings’ in wp_options as an array that gets automatically serialized() on update_option() and unserialized() on get_option(). In other words, instead of a bunch of options prefixed with ‘apt_’ all those same options would be stored in your one option array.

    This’ll make your code a lot easier to read and write, it’ll make passing the settings around between functions possible, it’ll make upgrades and uninstall easier, it’ll reduce the small likelihood of a conflict with another plugin that chooses the ‘apt_’ prefix and a site’s pages will load a tiny bit faster for high traffic sites. It will also make your plugin more attractive to other plugin developers (like me) who prefer their plugins generally only add one setting in the wp_options table unless there is a really good reason to add more.

    4. Add define( ‘WP_DEBUG’, true ) to your wp-config.php while you are developing the plugin to catch warnings like the previously undefined $apt_post_statuses_sql on line 566.

    5. Lastly consider wrapping all your functions in an ‘Automatic_Post_Tagger_Plugin’ class. Doing this all but eliminated change of function name conflict and I think you’ll find it allows you to establish a consistent structure for what code should go where so maintenance becomes easier. And you might consider simplifying your method names to match the hooks; I’ve been doing this for a few years and it really makes mainteance easier; just be sure to use PHPDoc comments to document the purpose of the hook so that you’ll be able to remember that you are using publish_post() to to set post tags for a single post.

    There many be other suggestions I could give but those were the ones that jumped out at me. I think if you rewrite with these suggestions you’ll see your code cut in half and see improved performance as well. Of course you’ll have to write and test the conversion code from the old table format to using taxonomies but that shouldn’t be too difficult.

    Hope this helps.


  • Devtard
    Posted November 21, 2012 at 11:13 am | Permalink

    Hello, I added your suggestions to my to-do list, thank you very much. :)

Post a Comment

Your email is kept private.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">