Add has_notices on plugin level

[danyj]

This PR sets the has_notice on plugin level so that we can disable the notices for recommended plugins if we need to. Fixes #748

Usage

	'bbpress'=> array(
		'name'      => 'bbPress',
		'slug'      => 'bbpress',
		'required'  => false,
		'force_activation'   => false,
		'has_notices' => false // This plugin will not be visible in the TGMPA notice
	),

[jrfnl]

Hi @danyj Welcome and thanks for your first PR!

I realy like the idea of this change.

As we try to make sure the code in TGMPA is high-quality, for this PR to be acceptable a couple of changes are needed:

1. The code needs to comply with the WordPress Coding Standards - see the Travis output for the issues.
2. TGMPA uses the principle that all plugin options are always set. To comply with this:
   • Add the new option to the $defaults in the register() method:

     TGM-Plugin-Activation/class-tgm-plugin-activation.php

     Lines 1399 to 1409 in 2732e40

     	$defaults = array(
     	'name' => '', // String.
     	'slug' => '', // String.
     	'source' => 'repo', // String.
     	'required' => false, // Boolean.
     	'version' => '', // String.
     	'force_activation' => false, // Boolean.
     	'force_deactivation' => false, // Boolean.
     	'external_url' => '', // String.
     	'is_callable' => '', // String|Array.
     	);

   • Add validation for the input in the same method - see line1421 for an example:

     TGM-Plugin-Activation/class-tgm-plugin-activation.php

     Line 1420 in 2732e40

     $plugin['required'] = TGMPA_Utils::validate_bool( $plugin['required'] );

   • You can now remove the isset($plugin['has_notices']) from the condition you added.
3. It may be useful to add an example using this new option to the example.php file.
4. A sister-PR is needed for the gh-pages branch to adjust the configuration documentation: http://tgmpluginactivation.com/configuration/

Please let me know if you need help with any of this and I look forward to seeing this get into TGMPA.

[jrfnl]

@GaryJones As this adds a new feature - do you agree that if this is merged in, the next version will need to be called 2.7.0 (instead of 2.6.2) ?

[danyj]

@jrfnl on it , going trough suggested changes.

[danyj]

not sure why travis is failing

[danyj]

A sister-PR is needed f

where is that git ?

[danyj]

@jrfnl please check the travis , all those lines were there and are untouched. I simply pulled the git and changed 4 lines and they do not seem to be failing.

[danyj]

Checked travis , all the lines mentioned in both files were there before my PR.

[danyj]

finally :)

[jrfnl]

@danyj Thanks for all the changes. I'll try to have another look later today.

where is that git ?

Regarding the sister-PR, it is in this same repo, just on another (orphan) branch: https://github.com/TGMPA/TGM-Plugin-Activation/tree/gh-pages

[danyj]

All set. Submitted PR for it.

[jrfnl]

@danyj All looks good to me.

There's just one thing I'm wondering: should has_notices always be allowed/respected or only when required is false ?

If a plugin is required and not active, not showing the notice could easily cause the fact that the plugin is deactivated to go unnoticed, which - depending on the quality of the theme/plugin which requires it - could break sites with a WSOD.

What do you think ?

@GaryJones Have you got an opinion on this ?

If we would only allow it for recommended plugins, the if() within the notices() method would need to check the required setting as well + the explanation text in example.php would need to mention this too.

[danyj]

or only when required is false

good point , I think only when required is false because required true should always show notice.

@GaryJones @jrfnl , let me know and I can make changes if you agree