Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #231: Added notifications when plugins are force activated #569

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

creativecoder
Copy link

I've added this with the goal of providing feedback to users that indicates why plugins are being automatically reactivated.

Updated from #232

@@ -371,6 +380,9 @@ public function init() {
'The following recommended plugins are currently inactive: %1$s.',
'tgmpa'
),
'notice_force_activation' => _n_noop(
'The following plugin has been automatically activated because it is required by the current theme: %s', 'The following plugins have been automatically activated because they are required by the current theme: %s'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This string will also need to be added to the example.php file for potential overruling.

@jrfnl
Copy link
Contributor

jrfnl commented Apr 24, 2016

Hi @creativecoder Thanks ever so much for updating the PR! I've added some inline notes about the code itself.

One thing I'm wondering about is whether the 'generic' TGMPA notice is the best place to advise a user about a force activated plugin. Or should a force activated plugin have it's own admin notice ?

IMHO I think splitting them off would be the more user friendly. The generic TGMPA notice is basically a call to action and the notice you've now added is a FYI.

Also, I can imagine that the notice should only be shown to admin users (who may have tried to deactivate the plugin) and not to the wider range of users who get to see the call to action notice.

What are your thoughts on this ? @GaryJones want to weight in as well ?

@GaryJones
Copy link
Member

I'm in agreement. It's a great feature, but it should be a separate notice, shown to just the relevant group of users.

@@ -2023,6 +2039,7 @@ public function force_activation() {
} elseif ( $this->can_plugin_activate( $slug ) ) {
// There we go, activate the plugin.
activate_plugin( $plugin['file_path'] );
$this->force_activated_plugins[] = $slug;
Copy link
Contributor

@jrfnl jrfnl Apr 24, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking a transient should be set with this information. The situation - a plugin being force (re-) activated - could come up during a bulk-install which uses frames which would prevent the message from becoming visible. Similarly, another program could with code try to silently deactivate a plugin.

So, what about setting a transient with the slugs of force-activated plugins whenever this occurs ? Then having an admin_notice action which checks if such a transient exists, that we're in the WP back-end (or maybe even check that we're on the WP admin plugins page) and that the current user can activate activate plugins and if so, shows a one-time notice to that user about the plugin(s) which were force activated ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the thoughtful feedback. I like all of these ideas, both from
a UX and engineering perspective. I'm aiming to get to these changes and
additions in the next week or two and will update the pull request.

@jrfnl
Copy link
Contributor

jrfnl commented May 2, 2016

@creativecoder Just a quick question - we're about ready to release TGMPA v2.6.0 and I'm wondering whether we should hold off another week or so to include this PR or not. What do you think ?

@creativecoder
Copy link
Author

creativecoder commented May 3, 2016 via email

@jrfnl
Copy link
Contributor

jrfnl commented May 3, 2016

@creativecoder OK, will hold off until after the weekend.
Reminder to self: We may need to ping the translators (again) for the extra string as well.

@creativecoder creativecoder force-pushed the feature/231-notify-on-forced-activation branch 3 times, most recently from 364a5a2 to 16241d1 Compare May 14, 2016 20:58
@creativecoder
Copy link
Author

creativecoder commented May 14, 2016

@jrfnl @GaryJones Sorry for the delay! I've update my pull request, as suggested. Please let me know if you see any issues that need to be addressed before merging.

@@ -371,6 +371,9 @@ public function init() {
'The following recommended plugins are currently inactive: %1$s.',
'tgmpa'
),
'notice_force_activation' => _n_noop(
'The following plugin has been automatically activated because it is required by the current theme: %s', 'The following plugins have been automatically activated because they are required by the current theme: %s'
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_n_noop() needs the text-domain as the last argument.

@jrfnl
Copy link
Contributor

jrfnl commented May 15, 2016

Hi @creativecoder I'd like to take the time to properly look at what you've done now and as we've already started the process now of releasing v 2.6.0, I'm inclined to not rush this through and leave it for v2.6.1 if you don't mind.
Added two small remarks so far, but will try and look your PR over properly & test it over the next week or so.

@jrfnl jrfnl added this to the 2.6.1 milestone May 15, 2016
@@ -448,6 +451,11 @@ public function init() {
if ( true === $this->has_forced_deactivation ) {
add_action( 'switch_theme', array( $this, 'force_deactivation' ) );
}

// Display forced activation notice, if present.
if ( current_user_can( 'manage_options' ) && is_admin() ) {
Copy link
Contributor

@jrfnl jrfnl May 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for the action if there are no plugins with the force activated flag set to true
if ( true === $this->has_forced_activation && ...

Edit: or is there ? the force activated flag might have been removed, but there may still be a lingering transient which hasn't been displayed .. ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right... the property has_forced_activation indicates if there are plugins that need to be force activated, where the the transient and message are displaying only if they have already been force activated, but we still need to notify the user.

@jrfnl
Copy link
Contributor

jrfnl commented May 15, 2016

@creativecoder Very much like what you've done now! Added some thoughts to the code, but they are mainly about the details, not the principle of it. This is shaping up to be a great PR!

@jrfnl
Copy link
Contributor

jrfnl commented May 15, 2016

@GaryJones Quick question - looks like Scrutinizer is not running for PRs from external forks... any ideas ?

*
* @since 2.6.0
*
* @param array $message Associative array of actions: each key is an action and each value is an array of plugin slugs that need that action.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to be a pain, but the parameter comments should line up, so the text Associative.. needs some more spaces before it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, only a single space is needed after @param.

Yes, that means it won't line-up with the type in the @return string, but that's what WP does.

@GaryJones
Copy link
Member

Quick question - looks like Scrutinizer is not running for PRs from external forks... any ideas ?

No idea. Didn't you recently update the config for that?

@GaryJones
Copy link
Member

The @since values will need updating - perhaps put them as 2.x.x, so they'll be easier to find amongst the real 2.6.0 values later on?

protected function build_message( $message, $line_template = '%s' ) {
$message_output = '';

krsort( $message ); // Sort messages.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment is redundant.

@jrfnl
Copy link
Contributor

jrfnl commented May 15, 2016

No idea. Didn't you recently update the config for that?

I did, but that shouldn't have any effect on when it's run, just what checks it runs.
If I look at the Scrutinizer website, it looks like it does actually run the checks on PRs, but GH does not show them in the check bit... weird

@creativecoder creativecoder force-pushed the feature/231-notify-on-forced-activation branch 5 times, most recently from 450a017 to 6b84370 Compare May 15, 2016 15:26
@creativecoder creativecoder force-pushed the feature/231-notify-on-forced-activation branch from 6b84370 to 83cf630 Compare May 15, 2016 15:29
@creativecoder
Copy link
Author

Thanks for the feedback. I've responded and made several updates. Let me know if you see anything outstanding.

@jrfnl jrfnl removed this from the 2.6.1 milestone May 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants