Matt Cohen

Category: WooCommerce

  • The reason we build WordPress plugins

    The reason we build WordPress plugins

    Story time. Once upon a time, a man walked up to three brick layers at a building site. He asked the first, “what are you doing?” to which the brick layer replied, “I am laying bricks”. Curious, he asked the second what they were doing. The second brick layer’s response was, “I am building a wall.” Now more curious, he asked the third. The response he received was, “I’m building a cathedral”.

    This parable is a clear reminder of the importance of knowing the greater purpose behind our actions. This story resonates with me in the context of WordPress plugins as well.

    Asking “why” usually leads to poor answers, so lets ask rather what is the reason we build WordPress plugins. Who are these plugins for? What is their reason for being created?

    Factually speaking, WordPress plugins exist to add features or adjustments to WordPress which don’t exist within the core software. Zooming out from this statement, there is a lot more to unpack.

    WordPress plugins enable anyone to transform WordPress into something different or more than the core software. With a single plugin, WordPress can become a CRM, online store, marketplace, or anything else in addition to being an amazing blogging and content management tool (even a terms list block).

    Additionally, plugins continue to live within WordPress. A part of what every plugin’s mission is involves serving to enhance WordPress itself, for the benefit of the user.

    So before we ask “why”, lets remember the integral part that plugins play in the WordPress experience, and that the plugin serves it’s users. Throughout development, keep your users in mind. If your plugin includes a “delete” action, make sure the user is aware of what they’re doing before the action is taken. If your plugin adds options, metadata, custom database tables, etc, be sure to include an uninstall.php file to help the user clean up if they choose to uninstall your plugin.

    A most importantly, remember that your users are experiencing your plugin in the context of their WordPress which may also include other plugins, custom code, and more. Plugins should complement one another, should act responsibly, and should act with the best interests of the user in mind.

    At the end of the day, when building plugins, we’re building our part of a cathedral, not simply laying bricks one on top of the other.

  • Adding unit tests to your WordPress plugin using wp-env

    Adding unit tests to your WordPress plugin using wp-env

    Earlier this week, I spent some time adding unit tests to my WordPress starter plugin. I’ve worked on this plugin for almost a decade, and use it as a place to explore and learn the latest developments in WordPress.

    Adding unit tests is important for the integrity of your code as the codebase increases in size and complexity, and as a thought experiment for writing more considered code.

    I took this opportunity to create something, as well as use the latest tech to make unit testing more accessible. Here are a few tips for using @wordpress/env to add unit tests to your plugin.

    The wp-env project handbook page has links to instructions on how to install each dependency. It’s really the best overall detailed guide for using @wordpress/env. Consider the rest of this post as my experience of the tool and my tips, rather than as the official guide. Bookmark this page. You’ll refer to it often while setting up your environment.

    I’d love to hear from you on how I can improve the wp-env and unit tests integration in my starter plugin. Add feedback in the comments below, or submit pull requests on GitHub. Patches welcome!

    (more…)
  • Smart defaults and your WordPress plugin settings

    Smart defaults and your WordPress plugin settings

    When building WordPress plugins, there are likely options you’d like your users to be able to adjust. Turning features on or off, changing text labels, customizing colours, etc. Many of these settings land on a settings screen within WP Admin or in a meta box on a post type. Lets focus today on the settings screen idea, and introducing smart defaults.

    Smart defaults are pre-configured values for the settings of a WordPress plugin. In WordPress itself, we see smart defaults for the site title, site tagline, and many other features within WP Admin. These can all be adjusted, though they start with a pre-defined value. These pre-defined values are the smart defaults.

    When installing a WordPress plugin, the plugin should “just work”. No additional setup required. How a plugin is configured is part of the user experience for that plugin.

    (more…)
  • Building WordPress plugins in context

    Building WordPress plugins in context

    One particular recurring theme comes up for me regularly when building products -in particular WordPress plugins- is to consider the parts as part of the whole. Consider the context your product fits into. This one concept is critical to building successful products.

    I apply these concepts when building and reviewing WordPress plugins.

    To my mind, a WordPress plugin should feel like part of WordPress. This guiding principle has helped to inform how I consider decisions when building and reviewing WordPress plugins.

    (more…)

  • Measuring your online store’s performance

    I spend a somewhat regular portion of my time answering questions around scalability with WooCommerce. Questions such as “I have a catalog of 600k products, can WooCommerce handle that” and “how many orders can WooCommerce handle” are not uncommon. That said, an interesting post by Chris Lema around scaling WooCommerce brought to light a metric I’ve long felt to be a worthwhile metric for measuring overall performance of any online store; “add to cart” events. This metric is great for measuring not only how well your store performs as you receive more traffic, but how well your store is performing overall as well. (more…)