A common TGMPA customization typo I found in some WordPress themes

Envato Authors Theme Authors
,
1

Hi authors!

I’m a plugin developer and I want to share and discuss something that I frequently have to deal with when providing support to my customers about my plugins.

I’m not a native English speaker so the tone of this post may be misinterpreted, forgive me in advance for that.

The context

A generic customer reaches me reporting a fatal error when trying to activate my plugin. The error is:

Fatal error: Cannot redeclare tgmpa() (previously declared in /wp-content/plugins/my-plugin/libs/tgm/class-tgm-plugin-activation.php:2126) in /wp-content/themes/example-theme/inc/tgm-plugin-activation/class-tgm-plugin-activation.php on line 2126

So the TGMPA class bundled with the theme is redeclaring the tgmpa function although already declared by the one bundled with the plugin. As all we already know, recent versions of TGMPA library should take care already of that with conditional blocks, so the first thing I check is that the theme is up to date. Unfortunately, the theme is up to date as well as the TGMPA library. So what?

The issue

Theme’s developers often customize the TGMPA class to play well with their themes. While inspecting the customized class I often come across what looks like a search-and-replace typo:

if ( ! function_exists( 'whatever-theme-slug' ) ) {
    function tgmpa( $plugins, $config = array() ) {

This always-true conditional is silent most of the time, hence hard to spot when testing the theme, yet trivially destined to generate a fatal error when an active plugin includes TGMPA.

For the sake of completeness, here is the correct vanilla one:

if ( ! function_exists( 'tgmpa' ) ) {
    function tgmpa( $plugins, $config = array() ) {

The outcomes (fatal error apart)

I need then to explain to that customer that theme contains that little typo which I can fix by myself, but at every theme update they will face the issue again. So I invite the customer to report the issue to the theme developers etc.

Some theme’s developers immediately react and fix the glitch, while others are less prone to intervene. Once I was even told that it was my fault to provide the TGMPA class because it’s made for themes only, which is clearly a nonsense.


Long story short, I can’t run checks for TGMPA presence right before including the class in my plugins, as they are loaded before the theme (if you know a way, please let me know!) so I beg you to have a look at your TGMPA implementation being typo-free, because this has quite an impact on compatibility.


Sincerely,
VonStroheim

1 Like
2

Why do you need to load TGMPA inside of the plugin anyway?

3

Hi!

Are you suggesting to defer the inclusion by hooking it?

4

I didn’t understand why you need to use TGMPA within the plugin? You’re developing the plugin so if you need extra one, you could just use ( import/add ) without using TGMPA

5

Oh, I like to suggest other plugins (like Envato Market). TGMPA seems to me the nicier ready-made way to handle the process.

6

TGMPA is mostly for the themes. IF you’d come with that idea, you’d better to code your own script to prevent issues with themes and TGMPA

7

TGMPA is mainly used by themes, of course. But it’s made for plugins too, infact it works pretty well with both.

The aim of this topic is to report (what in my experience is) a widespread typo in custom implementations that may cause issues. The proper way to handle those issues is to fix the typo. Me coding my own script, while certainly effective, is a little bit drastic as a countermeasure :slightly_smiling_face:

8

Instead of writing

if ( ! function_exists( 'tgmpa' ) ) {
    function tgmpa( $plugins, $config = array() ) {

in your one plugin you ask all authors fix it in their themes? I’m right?

1 Like
9

BTW, the proper way to include plugins using TGMPA is:

add_action( 'tgmpa_register', 'my_awesome_required_plugins' );

function my_awesome_required_plugins() {
   $plugins = array();
   $config = array();

   tgmpa( $plugins, $config );
}
10

You are wrong. The TGMPA bundled with my plugin is the non-modified version, so that conditional is already correct. The issue is when a customized version has the typo I reported. Plus as I’ve already pointed out, it’s completely useless for me to enforce conditionals of any sort, as the plugin code is always executed before the theme code.

11

Of course, but how that is related with this topic?

12

if ( ! function_exists( ‘tgmpa’ ) ) {

This may cause a soft-rejection on the theme and you cannot control it with a specific slug. Every author is using different slug so the easiest way, include the tgmpa inside of your plugin and rename all the functions ( eg. tgmpa_myplugin ) so it won’t cause errors. And use that modified TGMPA for the other projects as well. That would be the only solution that I can think of it

13

Thanks for the insights, but why the soft-rejection risk? I see the vast majority of Envato themes using the correct conditional with the original ‘tgmpa’ string :thinking:… Only a few show this:

if ( ! function_exists( 'whatever-theme-slug' ) ) {
    function tgmpa( $plugins, $config = array() ) {

that is a just a logic mistake. Even if not a typo because the author is forced to change the ‘tgmpa’ string to avoid soft-rejections, then he should change the function(s) name accordingly to keep consistency.

14

Please use a unique prefix for all function names, custom images sizes, classes, CONSTANTS, hooks, public/global variables, and database entries to avoid conflict issues with plugins and other themes. For example, themename_ OR frameworkname_ - Read more at http://themereview.co/prefix-all-the-things/ - You can have frameworkname_ if you are using a framework while using themename_ for your themes

This is one of the recent soft-rejected mess\age I received. It was the Option Tree Plugin so I had to rename them

if ( ! function_exists( ‘whatever-theme-slug’ ) ) {
function tgmpa( $plugins, $config = array() ) {

This is not correct way to do it, I know