Giter VIP home page Giter VIP logo

wds-required-plugins's Introduction

WDS Required Plugins

A library you can use to make any plugins required and auto-activate.

  • Nobody can de-activate the plugin from the WordPress Admin
  • They are auto-activated when required

To use, place this library in your mu-plugins/ directory (if you don't have one, create one in wp-content/), then use the example below:

WebDevStudios. WordPress for big brands.

Installation & Update

With Composer

Add the following to your composer.json

{
    "extra": {
        "installer-paths": {
            "mu-plugins/{$name}/": ["type:wordpress-muplugin"]
        }
    }
}

Then use:

composer require webdevstudios/wds-required-plugins

This will install the mu-plugin, e.g. mu-plugins/wds-required-plugins in wp-content based projects.

You will have to require it in e.g. mu-plugins/wds-required-plugins-list.php:

<?php

require WPMU_PLUGIN_DIR . '/wds-required-plugins/wds-required-plugins.php';

function wds_required_plugins_add( $required ) {
    return array_merge(
      $required,
      [
        'my-plugin/my-plugin.php',
      ]
    );
}
add_filter( 'wds_network_required_plugins', 'wds_required_plugins_add' );

Example Usage

<?php

/**
 * Add required plugins to WDS_Required_Plugins.
 *
 * @param  array $required Array of required plugins in `plugin_dir/plugin_file.php` form.
 *
 * @return array           Modified array of required plugins.
 */
function wds_required_plugins_add( $required ) {
  return array_merge(
    $required,
    [
      'jetpack/jetpack.php',
      'sample-plugin/sample-plugin.php',
    ]
  );
}
add_filter( 'wds_required_plugins', 'wds_required_plugins_add' );

Use the following filter instead to network activate plugins:

add_filter( 'wds_network_required_plugins', 'wds_required_plugins_add' );

Change the Text:

To change the label from Required Plugin to something else, use the following filter/code:

/**
 * Modify the required-plugin label.
 *
 * @param  string  $label Label markup.
 *
 * @return string         (modified) label markup.
 */
function change_wds_required_plugins_text( $label ) {

	$label_text = __( 'Required Plugin for ACME', 'acme-prefix' );
	$label = sprintf( '<span style="color: #888">%s</span>', $label_text );

	return $label;
}
add_filter( 'wds_required_plugins_text', 'change_wds_required_plugins_text' );

Hide Required Plugins (off by default)

To hide your required plugins from the plugins list, use the following filter/code:

add_filter( 'wds_required_plugins_remove_from_list', '__return_true' );

This will make any plugin that is required simply not show in the plugins list.

wds-required-plugins's People

Contributors

aubreypwd avatar blobaugh avatar bradp avatar daveromsey avatar garyjones avatar gregrickaby avatar jaywood avatar jtsternberg avatar phatsk avatar pmgarman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wds-required-plugins's Issues

Make plugin required from the plugin itself.

Modifying the filter list is a pain in the a$$ and often people add new plugins that should be required to projects and forget to modify the filter. I want to add an easy bulletproof way to make a plugin required when WDSRP is installed w/out having to:

  1. Load up Sublime
  2. Figure out where the filter is
  3. Figure out the path, copy the name of the path
  4. Add the path to the filter somewhere (when you find it)
  5. Bleh, go get some fresh air, because that was TOO hard

What if, to make a plugin required was really simple:

  1. Open the plugin file
  2. Add Required: True

Oh wait, did you just pee a little? Yes, it could be that easy! If WDSRP is installed, it will automatically find that plugin and make sure it's added to your list. How awesome.

Fix compatibility issue with WP Migrate DB Pro

From Delicious Brains support:

Hey Greg,

Thanks for that - we’ve now been able to replicate the issue and figure out what’s going on.

It’s definitely a conflict between WP Migrate DB Pro’s “Compatibility Mode” code and the WDS Required Plugins code. The reason we were unsuccessful before is because we were assuming that you were running the Required Plugins init from the theme’s functions.php file, but this site is actually initializing it in another MU plugin - which makes sense in retrospect since our compatibility code actually bypasses the theme code in addition to plugin code for our migration requests - the only thing it can’t avoid running is other MU plugins.

Long story short, we have two options to fix this:

  1. We can (and will) include a patch in the next release of WP Migrate DB Pro that will just remove the WDS Required Plugins activate_if_not action during compatibility mode requests. This will just prevent the Required Plugins code that is causing this conflict from running during WP Migrate DB Pro’s migration requests and won’t affect its intended functionality.

  2. In the meantime, you can update the WDS Required Plugins code to include the following code at the beginning of the __construct() method:

// Bail if this is a WP Migrate DB Pro AJAX Request
if ( ( defined( 'DOING_AJAX' ) && DOING_AJAX ) && ( isset( $_POST['action'] ) && false !== strpos( $_POST['action'], 'wpmdb' ) ) ) {
    return;
}

That code will, as the comment indicates, prevent the Required Plugins actions from being applied during WP Migrate DB Pro migration requests - and again won’t have an effect on the intended functionality of the plugin.

Alternately, you can just continue to leave WP Migrate DB Pro’s compatibility mode disabled - but we do recommend running WP Migrate DB Pro with it enabled as it usually speeds things up and avoids conflicts with (non-MU) plugins and theme code.

Cheers,
Jeff

Cannot switch site to multi-site.

When using the plugin, if you're upgrading from a regular site to multi-site, you must clear the filtered array before you can continue. Not a huge issue, but an issue nonetheless.

image

Bulk Action: Deactivate creates header sent errors

When doing a Bulk Action: deactivate on all plugins (select all - including wds-required plugins), I get the following errors:

On my installation I have an mu-plugin wds-requiring 2 plugins.
One of these plugins also wds-requires other plugins when loaded (and some of these plugins also wds-require other plugins. That's it. 3 levels deep)

On refresh (after the first bulk-deactivate error page) all plugins are deactivated except for the 2 mu-requires.
On consecutive iterations all my other wds-required plugins get activated (which I guess is a separate issue. wds-require-plugins can hook onto plugins_loaded really late (1000?) and wp_redirect to self, if some of its requires are not active yet).

Doing a bulk deactivate again repeats these errors (tho it does deactivate the plugins - which might be a feature, allowing a soft reset of plugins that have activation hooks, or it might be considered a bug).

Warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in wp-includes\class-wp-hook.php on line 286

1 | 0.4060 | 549632 | {main}( ) | ...\plugins.php:0
2 | 3.5152 | 35973776 | deactivate_plugins( ) | ...\plugins.php:234
3 | 3.5272 | 35992960 | do_action( ) | ...\plugin.php:792
4 | 3.5272 | 35993336 | WP_Hook->do_action( ) | ...\plugin.php:465
5 | 3.5272 | 35993336 | WP_Hook->apply_filters( ) | ...\class-wp-hook.php:310

Warning: Cannot modify header information - headers already sent by (output started at wp-includes\class-wp-hook.php:286) in wp-includes\pluggable.php on line 1251

1 | 0.4060 | 549632 | {main}( ) | ...\plugins.php:0
2 | 3.5452 | 35997976 | wp_redirect( ) | ...\plugins.php:247
3 | 3.5472 | 36001272 | header ( ) | ...\pluggable.php:1251

Warning: Cannot modify header information - headers already sent by (output started at wp-includes\class-wp-hook.php:286) in wp-includes\pluggable.php on line 1254

1 | 0.4060 | 549632 | {main}( ) | ...\plugins.php:0
2 | 3.5452 | 35997976 | wp_redirect( ) | ...\plugins.php:247
3 | 3.5482 | 36001376 | header ( ) | ...\pluggable.php:1254

Ability to require a plugin w/out code

My dream here is that we can do something like wp plugin require <plugin-file> and it is suddenly a WDS required plugin. And, of course you can wp plugin unrequire <plugin-file> and it will disable it.

This would probably modify some mu-plugin to add to the filter, or it could actually distribute to the DB, but I'm not sure how that would get reflected via after a deploy, so maybe that's a bad idea.

Of course we could ditch the whole modify a PHP file thing, and instead maybe use a .file instead, e.g. .../plugins/.required which is simply a GLOB list of plugins that are required. Of course we would have PHP detect the files in that file and add them to the overall filter. Then this would offer these overall features:

  1. Instead of adding a filter, you just create a plugins/.required file and track that in code vs the way we do it now with an mu-plugin

  2. Running the wp commands will modify that file easily, adding and removing the required plugin to the file

Might be a good thing for 5ftf!

Add UI to hide Required Plugins

Right now you have to programmatically do that. Maybe the client is annoyed with seeing WDS Required Plugins in a list they really can't do anything about. They just want to know what plugins they are working with that they use, not the one's we built for them.

A UI option to hide them would be nice. A simple toggle somewhere on the plugins screen.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.