The plugin does not have a valid header. caused by TGMPA

[weavertheme]

TGMPA Version 2.5.2 has this in the lead-in comment to class-tgm-plugin-activation.php:

 /* @wordpress-plugin
 * Plugin Name: TGM Plugin Activation
 * Plugin URI:
 * Description: Plugin installation and activation for WordPress themes.
 * Version:     2.5.2
 * Author:      Thomas Griffin, Gary Jones, Juliette Reinders Folmer
 * Author URI:  http://tgmpluginactivation.com/
 * Text Domain: tgmpa
 * Domain Path: /languages/
 * Copyright:   2011, Thomas Griffin
 */

Given that a goal of the library (at least as I use it) is to simplify all the stuff for recommending or requiring plugins, this comment code is NOT okay. I recently updated to 2.5.2 for a plugin (doesn't seem to bother themes), and the above comment definition OVERRIDES the real Plugin Name, etc. when my plugin is installed. This leads to the "The plugin does not have a valid header." message if the user tries to activate my plugin from the plugin installation screen.

The plugin has been installed, and WILL activate from the Installed Plugins page, but not from the plugin Activate link displayed right after the plugin is installed.

This may be dependent on where files are found. My plugin has the main plugin .php file on the plugin root directory, while the TGMPA php file is in a /includes sub-directory,

In my opinion, WP should NOT do this. If the WP plugin uploader finds a valid plugin header in the plugin root, it shouldn't keep looking in sub-directories, but apparently it does, and apparently the last file found with a valid Plugin Name: descriptor is used.

But that standard plugin header still does not belong in a library file such as TGMPA.

[jrfnl]

@weavertheme If you have the file in a subdirectory, you should not get any conflicts. This may be a core bug.
Could you mail me a copy of the zip of your plugin so I can test to see what's going on ? You can mail it to me AT [removed].

What would I need to do to reproduce the issue once I've got the zip ?

[weavertheme]

I agree that this is a core bug, but other reports of having a valid
plugin header description in a sub-directory seem to indicate that the
core team thinks they have it right. I reported it anyway.

Here's what happens (in the attached Show Posts 1.3.4 version - I've
fixed in the the currently live version by commenting out TMLPA's header):

1. Use the standard Plugin Install New Plugin : Upload sequence to
   upload the plugin. You get the normal successfully uploaded screen, with
   the Activate link included. If you click that link, WP issues "The
   plugin does not have a valid header."

This is because the Installer has found the TGMPA plugin header which is
included in the /includes subdirectory class file, and used it instead
of the real header contained in the plugin's single php file in the
root. The only way I figured this out was finding that message in the
core code and adding a debugging output to see what was really going on.
To my surprise, it showed TGMPA as the plugin's name instead of Show
Sliders. Was then a small step to find the header code in the class file.

1. On the other hand, the Activate option from the usual Installed
   Plugins will activate the plugin as it seems to find the proper plugin
   header info from the root file.

Just the fact that these two operations give different results seems to
me to indicate that WP core is at fault.

That being said, there is some indication they won't see it that way and
fix it.

And I don't know how many plugins actually use TGMPA to recommend other
plugins. In my case, I have a required companion plugin (Show Posts)
that I use TGMPA to load. When I recently updated to 2.5.2 (because I
got a notice directly from WP to do that!), I didn't notice (and should
not have had to notice) the newly included Plugin header info in the
class library file.

I really don't know why it needs to be there, frankly. So, even though I
think this is a WP core issue, it will be a while before that goes away
(if ever), and so I think the plugin header info doesn't belong in the
TGMPA class file.

Juliette mailto:[email protected]
December 31, 2015 at 12:54 PM

@weavertheme https:/weavertheme If you have the file in
a subdirectory, you should not get any conflicts. This may be a core bug.
Could you mail me a copy of the zip of your plugin so I can test to
see what's going on ? You can mail it to me AT adviesenzo DOT nl.

What would I need to do to reproduce the issue once I've got the zip ?

—
Reply to this email directly or view it on GitHub
#499 (comment).

---

Bruce Wampler, Ph.D.

Software developer
Creator of first spelling checker for a PC
Creator of Grammatik(tm), first true grammar checker
e-mail: weaver at weavertheme dot com

[jrfnl]

Unfortunately attachments don't come through when you mail to GH. Could you please mail me the file directly ?

[GaryJones]

Since 2.5.2 isn't a plugin, I do agree that these headers should not be there.

They were added in 2004a2e

[jrfnl]

I agree, they were only put in to make the initial .pot file generation easier. Other than that they serve no purpose unless and until TGMPA would ever get accepted as a feature plugin, so let's take them out for now.

All the same, I'd still appreciate a copy of the plugin to test with to see what actually happens.

For reference - the issue @weavertheme created in trac: https://core.trac.wordpress.org/ticket/35277

[weavertheme]

Will be happy to send directly, but would need an e-mail address as this
one is a GH address.

Juliette mailto:[email protected]
December 31, 2015 at 5:50 PM

I agree, they were only put in to make the initial .pot file
generation easier. Other than that they serve no purpose unless and
until TGMPA would ever get accepted as a feature plugin, so let's take
them out for now.

All the same, I'd still appreciate a copy of the plugin to test with
to see what actually happens.

For reference - the issue @weavertheme
https:/weavertheme created in trac:
https://core.trac.wordpress.org/ticket/35277

—
Reply to this email directly or view it on GitHub
#499 (comment).

---

Bruce Wampler, Ph.D.

Software developer
Creator of first spelling checker for a PC
Creator of Grammatik(tm), first true grammar checker
e-mail: weaver at weavertheme dot com

[jrfnl]

@weavertheme Already posted one for you in #499 (comment)

[weavertheme]

Got an official reply from the WP core team:

"Although it isn't really a best practice and not allowed in the plugin
directory, multiple plugin files can be bundled in a single directory. For
example, foo/bar.php and foo/baz.php can both contain valid plugin headers
and can therefore be activated separately."

So, WP does not consider this a bug and won't change it.

[jrfnl]

In general yes: however, as far as I know, in that case the "main" file for each plugin should be in the root directory of the plugin subdirectory, i.e.:

/wp-plugins/plugin-name/
- plugin-1.php
- plugin-2.php
- ....

Not - as I gathered from your message was the case - in a subdirectory of the plugin directory. In that case, it should be ignored.

Anyway, I received your file. It may be a little while before I have proper time to investigate, but will look into this.

In the mean time, I'm removing the header for now.