TGMPA / TGM-Plugin-Activation

TGM Plugin Activation is a PHP library that allows you to easily require or recommend plugins for your WordPress themes (and plugins). It allows your users to install, update and even automatically activate plugins in singular or bulk fashion using native WordPress classes, functions and interfaces. You can reference bundled plugins, plugins from the WordPress Plugin Repository or even plugins hosted elsewhere on the internet.
http://tgmpluginactivation.com/
GNU General Public License v2.0
1.76k stars 429 forks source link

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

Closed weavertheme closed 8 years ago

weavertheme commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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:notifications@github.com December 31, 2015 at 12:54 PM

@weavertheme https://github.com/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 https://github.com/TGMPA/TGM-Plugin-Activation/issues/499#issuecomment-168239047.


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 commented 8 years ago

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

GaryJones commented 8 years ago

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

They were added in https://github.com/TGMPA/TGM-Plugin-Activation/commit/2004a2e1ba954899ec37495092ffa355060b34ac

jrfnl commented 8 years ago

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 commented 8 years ago

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

Juliette mailto:notifications@github.com 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://github.com/weavertheme created in trac: https://core.trac.wordpress.org/ticket/35277

— Reply to this email directly or view it on GitHub https://github.com/TGMPA/TGM-Plugin-Activation/issues/499#issuecomment-168269897.


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 commented 8 years ago

@weavertheme Already posted one for you in https://github.com/TGMPA/TGM-Plugin-Activation/issues/499#issuecomment-168239047

weavertheme commented 8 years ago

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 commented 8 years ago

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/

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.