4

I work at a webdev company where we are experiencing the following problems:

  • The plugin not functioning properly with other plugins that are already installed.
  • Things that don't work the way we expected, this usually happens because we cannot spend too much time investigating what a plugin actually does.
  • Bugs that occur while trying to use certain functionalities.

For example: I was trying to implement WebP for one of our clients, after having struggled with the plugin of our choosing due to bugs within core functions I finally got it to work after implementing some changes within the plugin. Then finding out that the caching plugin that is being used by the website(and many other client websites of us) does not support the dynamic function which detects whether a browser even supports WebP or not.

I'm not trying to get an answer to the problem described in the last paragraph but I would like to know:

  • How you guys tackle the problem of having to work with plugins in general, working with multiple plugins and their malfunctions when combining them.
  • At what point you decide to build the functionality yourself instead of using a plugin.
  • When receiving requests from the client that require you to either add a new plugin or a new piece of code which hooks into almost the same element. How do you keep in mind the longterm of a website instead of looking at whether it's more cost efficient in the short term. For example we have a client that wanted us to implement discount coupons that were only available for certain user_roles. And there were already certain discount rules being applied to those user_roles. Then they wanted invoices specifically for those user_roles. Shipping costs that are different based on user_role, location and the checkout total.
3

Experiencing plugin incompatibilies isn't something I can relate to very well as that is something I've only faced a handful of times over the past years.

On those few occasions that I've needed to build a site using multiple plugins I've prioritized using plugins from same authors. For example WooCommerce and its official addons. I've found this minimizes the risk of plugins not playing nicely together. I also try to do some research beforehand to find out, if the author or other users have reported any incompatibilites.

And in general I tend to use known, tried and tested plugins, that I know they won't cause any problems. In the case of minor problems I might fix it myself and submit the patch to the plugin author. If there are any major problems, I usually just try find another plugin that gets the same job done.

Regarding building functionalities myself. If the functionality takes only few lines of code (extra user profile fields, WooC checkout fields..), it's something very site specific (CPTs, metaboxes..) or there's no need for any UI, I do it myself. On few occasions I've "cloned" plugin functionalities to a custom plugin, because I didn't like the way the plugin was done originally or it had unnecessary features.

Coding functionalities myself also depends on the case and client. I discuss a client about the existing plugins and their pros, cons and limitations. If a existing plugins is good enough and it's ok with the client, I usually go with it.

  • I would also suggest checking how frequently a plugin is updated, if it hasn't been touched for sometime it might be a sign to try a new plugin. – RiddleMeThis Apr 18 at 14:27
  • Yes, that is a good point. – Antti Koskinen Apr 18 at 21:07
  • Sticking with WooCommerce addons when using WooCommerce is indeed a better choice. I've also noticed in that those combinations usually don't bring incompatibilities. Do you have any experience in terms of having to add new functionality on functionality within the same area/element(for example on discount coupons)? – Bas van Dijk Apr 19 at 7:48
  • Yes, some experience. I've created an addon for WooC Bookings that prevents users from using coupons on bookings that have dates past the coupon expiration date. E.g. you can't use a Xmas coupon, valid until 25th Dec, to get discount from a booking for the next summer. – Antti Koskinen Apr 20 at 12:15
  • @AnttiKoskinen And what kind problems did you run int while developing and maintaining the plugin? – Bas van Dijk Apr 23 at 12:56
3

It's a tough problem, especially with supporting sites long-term. I have a couple rules of thumb when building new sites.

1. Establish your standard plugins

Put together a list of standard plugins for functionality you want on every site, ie caching, image optimization, forms, etc. Give these a review to make sure you're comfortable supporting them. Always try to use as much of the functionality in these plugins first before looking for others. For example, if your image optimization plugin also supports webP, try using that before searching for a webP plugin.

This will pay dividends later.

2. Add simple plugin functionality to your theme

There are tons of one-off plugins that do simple things that WordPress supports natively. For examples, disabling comments, maintenance mode, cron, etc. Try to limit use of these simple plugins in order to simplify your site. It's not that there's anything wrong with installing a load of plugins. My suggestion here is based on the extra cruft that may be included in these plugins and the burden you're taking on to rely on someone else for what's often simple functionality.

3. Try and stick with plugins in the official repository

There are absolutely exceptions to this rule, but there are real benefits to listing your plugin or a version of your plugin on the official WordPress plugin repository. That's why many companies that write plugins offer a free version. Code that's hidden behind paywalls is often subject to more issues because it often has less exposure and testing.


No situation is perfect, but you can reduce your burden by putting your trust in trustworthy plugins and by trying to understand how WordPress already supplies many features and hooks you can leverage without looking for a plugin.

Good luck!

  • Especially your third point is something that I haven't really thought about earlier. Nonetheless those ar some great tips to improve stability and maintaining a structured base. – Bas van Dijk Apr 19 at 7:44
3

That's a rather opinion-based issue. But I'd recommend to always assume custom coding. And building your custom code around major well-maintained developer-friendly official plugins.

Thing is that when developing bigger projects, I nearly always at a certain point are missing certain things from WordPress' core. Foremost a form API and a permission API. And also that plugins can't declare dependencies on each other.

So what I always do now from the very start of a project, I choose some few well-maintained, most-installed, long-term-tested, high-starred and developer-friendly plugins from wordpress.org that provide indispensable functionality I can hook into with my own custom plugins to extend WordPress and provide the features the client wants.

  • I agree that it is opinion based but I also think that there could be a structured way of working that could prevent most of the malfunctions that combining plugins brings with it. Although I kind of have an idea of what this would be but what makes a "developer-friendly" plugin? – Bas van Dijk Apr 19 at 7:52
  • @BasvanDijk – Taking wordpress.org/plugins/meta-box for example (it even already has "framework" in its name) which provides you functions to really easily implement complex meta boxes from your own custom plugin or theme. Or even de.wordpress.org/plugins/cookie-notice which provides you a function cn_cookies_accepted() you can use in your own custom plugin or theme to fire other things conditionally. That's developer-friendly. – leymannx Apr 19 at 8:08
  • Thanks for pointing that out. Functions like those do really add value to a developer. – Bas van Dijk Apr 19 at 9:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.