Best practices for a “child” plugin.

  • I have modified a number of plugins in different places. Now, I do not update the plugins as I am afraid that my changes will be overwritten. I know that for themes, you have a child theme because of this very problem, and updating the parent theme will not affect the child theme. So, is there anything corresponding for plugins? I think that for example woocommerce lets you do something where you can have your own files…But either way, how do you solve this problem? Are there any best practices?

Viewing 5 replies - 1 through 5 (of 5 total)

  • In general, the following applies to plugins, themes and the WordPress core: do not adapt their source codes if they are not your own. In case anyone else is reading this: not a good idea.

    If you want to influence processes in plugins, you have to do this via hooks. These hooks must be provided by the plugin in question at the relevant point. You can integrate your individual code, which uses the hook to change the process, in your own plugins, via functions.php of your child theme or code snippet plugin into the project.

    If the plugin does not offer a hook for the position, contact the developer of the plugin and ask him for a solution or customization. Many are happy to do this.

    Some plugins also provide their own templates. If the plugin developers adhere to WordPress standards, you can also overload them with a child theme. Talk to the plugin developer about this if you are interested.

    Thread Starter reachingout

    (@reachingout)

    Why not “do not adapt their source codes if they are not your own.?“?

    Do you have more information about “If the plugin developers adhere to WordPress standards, you can also overload them with a child theme.”

    By adapting plugin codes and disabling their updates, you will not receive any security updates from them. Apart from that, you won’t get any extensions, e.g. if the plugin is made PHP 8.3 compatible and your hosting requires PHP 8.3 at some point – without updates you would run into error messages in such a case. This means you are endangering the stability of your website if you change plugins this way.

    Apart from that, no one can answer your support requests anymore because it is completely unclear what your adjustments look like.

    For child themes, see: https://developer.www.ads-software.com/themes/advanced-topics/child-themes/

    Example of a plugin that supports and documents this: https://developer.woocommerce.com/docs/how-to-set-up-and-use-a-child-theme/

    Thread Starter reachingout

    (@reachingout)

    Thanks!

    I know about child themes, but it is more trickier for child plugins.

    • This reply was modified 6 months, 1 week ago by reachingout.

    The reply from @threadi is spot on. I would just add that if the plugin you’re wanting to change calls WordPress function under the hood, there is a chance that there’s a hook buried within that function, giving you an opportunity to manipulate content or trigger additional actions, even if there isn’t a specific hook added by the plugin developer.

    A simple example might be if the plugin developer calls get_option() to get plugin settings from the database, you could use an option hook to filter the content or trigger an action.

    The caveat is that the developer hasn’t intentionally introduced an API, meaning that if they change the option name in the future, your code would no longer fire.

    That said, it is a good interim solution. Better than modifying the plugin directly, but not as good as relying on hooks that were intentionally introduced and might offer better backward compatibility.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Best practices for a “child” plugin.’ is closed to new replies.