Proper way customize default functionality, when using methods & hooks?

  • Resolved Endlyss

    (@akel-res)


    7 years, 6 months ago

    I recently had the misfortune of dealing with WooCommerce’s 3.0 update.

    It broke literally everything on any website that I had built with custom WooCommerce functionality. One website in particular took about 6 hours to clean up… I had to comb through every bit of custom code that I wrote, and change how data was accessed, replace method names, etc.

    So, now I am looking to avoid that in the future — for any kind of custom “thing” I write, not just WooCommerce.

    What would be the best way to build my sites in the future, so that this is no longer such a huge issue? The main thing I am looking to avoid is having to comb through every bit of code that I wrote in order to find every little detail that needs to be changed.

    Best thing I’ve come up with so far is to carry around a library of functions for each major plugin that I use, and plan to customize. In that library would be my own set of functions for all of the basic “stuff” that I use the built-in methods to access.

    Literally all that my functions would do is access the method using the most up-to-date methods from the plugin’s documentation, and then return the data whenever called.

    What this would do is give me one core file in my custom theme or plugin that I would have to go back through and update the new/deprecated methods, since all of my template and function files would be referencing my functions, instead of directly pulling from the plugin APIs in a million different places.

    My main question here, though, is: Would this be considered “good practice”, or would it be considered bad juju? Are there any performance issues that I’d have to worry about? Would there be a better way to do this?

Viewing 2 replies - 1 through 2 (of 2 total)
  • Moderator bcworkz

    (@bcworkz)

    If plugin devs maintained reverse compatibility, this would be a non-issue. Of course this isn’t always possible. They ought to at least allow some time to deprecate functionality so we have time to make adjustments instead of surprise! your code no longer works at all and you must address this right NOW on your dozens of sites that are now all broken. To be fair, there was probably a beta version out for some time where we could have foreseen this coming and have been better prepared for it. But it is time consuming to deal with issues that may not even make it into production. Even for changes that do make it, we cannot preemptively deploy updates since the new methods are not currently defined. Ideally there would be an overlap of at least one release where both the deprecated and new methods both work so we can adapt in a reasonable time frame.

    Having your own plugin that customizes all plugins you normally use is a great way to organize and maintain your code. The only downside I see is there would be excess, useless code in some cases where a particular plugin is not used. To avoid undefined function and similar errors, your code in some cases would need to be encapsulated in conditionals that are only processed when the related plugin is active. Even then, this code still must be parsed even if it is not processed. There will always be some degree of inefficiency unless all plugins are always active in all cases.

    Short of writing all of your own custom code and not using other plugins and themes, this is about as good as it will get.

    Thread Starter Endlyss

    (@akel-res)

    Thanks for the reply and confirmation that my idea would work!

    In order to tackle the issue of defining many different plugin function sets, therefore creating excess, I’ll probably do what I do with SASS right now — treating everything like modules.

    Have one main core plugin file, and each plugin that I am accounting for will have it’s own separate functions file stored within subdirectories. And then from there I’ll simply require_once their function files, only if I am using that particular plugin. If it doesn’t get “require_once”-ed, then it doesn’t even make it to parsing.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Proper way customize default functionality, when using methods & hooks?’ is closed to new replies.