Plugin Dependencies #1674

afragen · 2021-09-13T23:16:40Z

This PR based on https://github.com/afragen/wp-dependency-installer and https://github.com/collizo4sky/persist-admin-notices-dismissal.

Need to load the new dependency installer class in all plugins and themes where dependencies exist.
require_once ABSPATH . '/wp-admin/includes/class-wp-plugin-dependency-installer.php';

Uses either a JSON config file or an array of data passed in code.

JSON config file named wp-dependencies.json resides at the root of the plugin or theme.
Call as follows. WP_Plugin_Dependency_Installer::instance( __DIR__ )->run();

[
  {
    "name": "Query Monitor",
    "slug": "query-monitor/query-monitor.php",
    "uri": "https://wordpress.org/plugins/query-monitor/",
    "required": false
  },
  {
    "name": "WooCommerce",
    "slug": "woocommerce/woocommerce.php",
    "uri": "https://wordpress.org/plugins/woocommerce/",
    "required": true
  }
]

Array example
Call as follows. WP_Plugin_Dependency_Installer::instance( __DIR__ )->register( $config )->run();

$config = array(
	array(
		'name'     => 'Hello Dolly',
		'slug'     => 'hello-dolly/hello.php',
		'uri'      => 'https://wordpress.org/plugins/hello-dolly',
		'required' => true,
	),
);

Example images. Plugin Dependency Feature (modified to use patch) and TwentyNineteen theme both have dependencies. Theme only has dependency for Hello Dolly.

Clicking on the Install link for Hello Dolly shows the following.

Page reload

After clicking on Activate link for Hello Dolly

Page reload

Query Monitor installed via link

Feature Plugin
https://github.com/afragen/plugin-dependency-feature

Trac ticket: https://core.trac.wordpress.org/ticket/22316

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

afragen · 2021-09-15T20:46:19Z

Add differentiation between required and recommended plugin dependencies.

tomjn · 2021-09-15T22:59:13Z

There's discussion in the other PR that's relevant here:

There was a lot of discussion around composer and that a dependency .json file is redundant, lots of people were opposed to the idea
A dependency JSON file would be obsolete and an additional tech debt burden if a wp-plugin.json or wp-theme.json file was introduced
Precedents already exist for using the plugin header to define plugin slugs, and the other PR adopted such a field for defining .org plugin slugs
A URI implies that 3rd party plugins can be specified, but the tickets scope is confined to .org repo plugins
including the name and URL in the JSON file opens this up to malicious actions, for example:

[
  {
    "name": "Super Safe Plugin Monitor",
    "slug": "site-deleter-plugin/delete-site.php",
    "uri": "https://wordpress.org/plugins/safe-plugin/",
    "required": true
  }
]

This PR adds recommendations, it would be good to have an off switch for these via a filter

afragen · 2021-09-15T23:21:49Z

@tomjn I did read all of the discussion on the other ticket. Respectfully, I disagree with the concept that having a JSON configuration file means "we should just use composer". There are huge differences and the ability to use a JSON config file, or in this PR, an associative array, provides for much more flexibility.

I believe that using a plugin header is much more restrictive and less performant. There is no need to loop through every installed plugin just to find the appropriate header and act on it.

Notice that this PR can also be used by themes.

There is no ability to designate a recommended plugin in a header. There is here.

Entering data into the configuration that does not conform to an actual plugin in the dot org repository will result in an installation failure. The PR specifically is restricted to dot org plugins. There is no ability to successfully designate an plugin that is not hosted on dot org.

@tomjn install the test plugin. Change the configuration and see what happens.

tomjn · 2021-09-16T10:27:35Z

Respectfully, I disagree with the concept that having a JSON configuration file means "we should just use composer".

That is not what I said, a dependency file duplicates composer functionality. The consensus on the other PR was that if we add a JSON file it should be general replacement for the plugin header in the future.

There is no ability to designate a recommended plugin in a header. There is here.

Recommendations were not a part of the tickets scope.

I believe that using a plugin header is much more restrictive and less performant. There is no need to loop through every installed plugin just to find the appropriate header and act on it.

WP would already do this, and caches the result, it's necessary in order to identify which file is the plugin file and which isn't. There is no performance cost that isn't already being paid.

The PR specifically is restricted to dot org plugins.

This does not eliminate the scope of abuse or mismatched expectations.

ideag · 2021-09-16T11:08:21Z

One thing I'd like to point out about JSON files is that they will be publicly accessible in plugin directories and will contain information about other plugins in the system and maybe even their versions. In plugin header that information is automatically protected from outside access, with JSON, there would need to be an additional .htaccess rule to restrict that.

afragen · 2021-09-16T14:08:34Z

@tomjn I will revise the PR to remove recommended plugins. It is out of scope.

Respectfully, I disagree with the concept that having a JSON configuration file means "we should just use composer".

That is not what I said, a dependency file duplicates composer functionality. The consensus on the other PR was that if we add a JSON file it should be general replacement for the plugin header in the future.

Creating a JSON replacement for all plugin headers is way out of scope and not like to happen.

Why does it matter if a JSON file duplicated composer functionality? Composer isn't used for core.

afragen · 2021-09-16T14:12:10Z

@ideag the only data in the JSON file is data related to plugins in dot org. How is that sensitive.

Given that we actively encourage keeping plugins up to date, installing an old, outdated version seems unwise.

tomjn · 2021-09-16T14:31:17Z

Why does it matter if a JSON file duplicated composer functionality? Composer isn't used for core.

There was an enormous discussion about this in the other ticket, initially started precisely because core does not use composer. A wp-dependency.json file is reinventing the wheel that is composer.json. It would make more sense to just implement composer.json, or, implement a wp-plugin.json. Both are outside the scope of the ticket. There are lots of reasons not to use a dependency JSON file in this case, and lots of existing precedents supporting the plugin header approach.

afragen · 2021-09-16T20:34:04Z

Honestly it's not simply a choice between composer or a header. I really did read the other discussion and the moment using a JSON config was mentioned the discussion went to that duplicates composer functionality.

It's not reinventing composer. The point that it does we should transition to using composer. That time is not now.

Composer isn't used it core, it's a non-starter. That doesn't mean a configuration file cannot be used.

We all admit that a configuration file is more flexible for future use. Why not just start there?

tomjn · 2021-09-16T23:11:32Z

As a part of a wp-plugin.json yes, as a wp-dependency.json file no. Right now the only non-problematic value in the file is the plugin slug, and no benefits have been outlined for putting it in a separate file.

There's also nothing to distinguish the dependency between a plugin and a theme other than the file extension on the end of the slug value. The slug also doesn't map to .org plugin slugs.

ensure all calling plugins/themes are listed

afragen · 2021-09-17T04:17:16Z

As a part of a wp-plugin.json yes, as a wp-dependency.json file no. Right now the only non-problematic value in the file is the plugin slug, and no benefits have been outlined for putting it in a separate file.

The slug is used internally, I could change it to the basename( $slug ), what is usually thought of as the slug, woocommerce or query-monitor.

There's also nothing to distinguish the dependency between a plugin and a theme other than the file extension on the end of the slug value. The slug also doesn't map to .org plugin slugs.

The slug isn't to tell the difference between a plugin and a theme.

Have you tried actually running the code? Do you have actual issues with it or is this really all about preferences?

I really don't mean to sound snarky, it's just been a long day fighting Darwin in the trauma center.

afragen · 2021-09-18T04:52:44Z

Latest commit removes JSON in favor of config array. @tomjn I use the slug (woocommerce/woocommerce.php) to target the plugin row.

Having some issues with the dismissible notice giving me a console error that dismissible_notice.nonce is undefined. 😖

afragen · 2021-09-18T16:11:09Z

🙌 JS should be working again.

afragen · 2021-09-19T23:01:09Z

State of the PR1674

Core aspects of #22316

Designate plugin dependencies for plugins
Notify the user or the plugin dependency
No versioning, latest version of dependencies are installed from dot org
Not allowing a dependency to be deleted or disabled once it is installed and/or activated
On re-activation of a plugin with dependencies, ensure user is notified that dependencies exist

Uses a configuration array and command to initialize. slug is used to target the plugin row to deactivate the ability to delete or deactivate installed activated dependencies and to designate the dot org download link. This PR uses a class instance so that multiple configuration sources may be properly used.

This PR does not try to control plugin activation. Every plugin developer should be responsible and ensure that their plugin degrades gracefully if a required dependency is not present and active. This is the current state of core and I believe it is out of scope to address this particular aspect. This PR does not force anything. If the user does not wish to install or activate a dependency all they must do is dismiss the admin notice and it will not reappear for a specified period of time.

Circular dependencies should not be an issue if plugin devs gracefully degrade their plugins. If they don't, this is an issue with the plugin requiring the dependency. This issue exists today.

Dependent plugins may be in either other plugins, themes, or both. In this example Hello Dolly is a required plugin for both Plugin Dependency Feature and TwentyNineteen.

Admin Notices designate what is requiring the dependency and a link to install or activate the dependency. If the same dependency is in a theme, that is listed as themes load first.

After the dependency is installed an admin notice to activate it will display. The dependent plugin will show itself as a Required Plugin and list what plugins or themes it is Required by

If a dependency is not in dot org, though it can have an install link, it will result in a failure.

All admin notices are dismissible. The default is for 14 days, but this can be modified by a filter for anywhere from 1 day to forever. All that must be done is click the dismiss button. Notice the WooCommerce notice is no longer present.

Once activated a dependent plugin cannot be deactivated or deleted until the dependent plugin or theme is deactivated.

In this case the theme was changed and the plugin deactivated.

The additional benefit of this PR is that it includes code for time dismissible admin notices that may be used for admin notices outside of this scope.

To test, either apply the PR or download and activate the Plugin Dependency Feature plugin.

Please let me know your thoughts on this PR.

BrianHenryIE · 2021-09-20T20:09:43Z

Request: filter.

I don't like the instant install without any explanation of why the plugin is needed or any way to assess the required plugin.

Before I discovered your dependency library I had started to write a similar solution, where the admin notice brought the user to the plugins install page and opened the modal for the plugin

wp-admin/plugin-install.php?s=WooCommerce&tab=search&type=term&open-plugin-details-modal=woocommerce

// Open the plugin details modal on plugin-install.php.
$(function() {
	let url = location;
	let searchParams = new URLSearchParams(url.search);

	var pluginName = searchParams.get('open-plugin-details-modal');
	if(pluginName != null) {

		// Should maybe be hooked to jQuery( document.body ).trigger( 'post-load' );
		setTimeout(
			function()
			{
				jQuery('.plugin-card-' + pluginName + ' .open-plugin-details-modal').click();
			}, 2500);

	}
});

Similarly, I would redirect users to the WooCommerce store to purchase missing plugins.

$shipment_tracking_url = 'https://woocommerce.com/products/shipment-tracking/';
$shipment_tracking_url = add_query_arg(
	array(
		'wccom-site'          => site_url(),
		'wccom-back'          => rawurlencode( '/wp-admin/admin.php?page=' . $this->get_plugin_name() ),
		'wccom-woo-version'   => WC_VERSION,
		'wccom-connect-nonce' => wp_create_nonce( 'connect' ),
	),
	$shipment_tracking_url
);

So it would be great to have a filer on the action link. Something ~class-wp-plugin-dependency-installer.php:470 like apply_filters( 'plugin_dependency_action_url', $action, $notice ); would allow me to extend your code to include my changes above.

afragen · 2021-09-20T21:23:16Z

I'm definitely in favor of filters. But what I understand your ask is to be able to modify what is installed and from where. Honestly this is out of scope for core as it could be used to install plugins it in dot org.

@BrianHenryIE there is a solution in afragen/wp-dependency-installer to install from elsewhere. My plan is to update that code with some of the improvements here.

dd32 · 2021-09-20T23:57:50Z

Need to load the new dependency installer class in all plugins and themes where dependencies exist.
require_once ABSPATH . '/wp-admin/includes/class-wp-plugin-dependency-installer.php';

It would make more sense to not have that call in the plugin, but have it always loaded in the proper contexts for plugins to call it - for example, it wouldn't make sense to call it / load it on front-end requests.

Plugins would then either a) run on a certain hook or b) check if the class is loaded before calling it.

Uses either a JSON config file or an array of data passed in code.

Having an array of passed in data in code has two main disadvantages to me:
a) Can't show information prior to the plugin being activated (or after it's deactivated)
b) Can't be easily detected by the WordPress.org plugin directory

[
  {
    "name": "Query Monitor",
    "slug": "query-monitor/query-monitor.php",
    "uri": "https://wordpress.org/plugins/query-monitor/",
    "required": false
  },
  {
    "name": "WooCommerce",
    "slug": "woocommerce/woocommerce.php",
    "uri": "https://wordpress.org/plugins/woocommerce/",
    "required": true
  }
]

First two things that I see here:

required being false kind of suggests that this is not a plugin dependencies, but rather a plugin suggestion. I can see that being abused by ACME Blocks suggesting ACME SEO and ACME CRM plugins very quickly. (Note: I recognise that Themes are where this is probably wanted)
slug should really be just that - a slug, woocommerce and should not reference the filename. The plugin filename can theoretically change, as well as, it being installed in a different location (for example, mu-plugins/woo/woocommerce.php). That's really something that would be only in a 0.01% of user type thing, but core does know the proper slugs of all the loaded plugins via the update api calls (I can't recall the transient that the slugs are stored in - it's not the update transient).

Example images. Plugin Dependency Feature (modified to use patch) and TwentyNineteen theme both have dependencies. Theme only has dependency for Hello Dolly.

Themes are the obvious use-case for suggested plugins, as currently WordPress.org-hosted themes cannot require a plugin, but can suggest it.

It might make sense to have support for it in core, but have the WordPress.org directories reject suggested plugins for plugins, and reject required plugins for themes. But it kind of makes me hesitate as to whether it should be supported at all in core due to the abuse that pro/premium plugins could do.. but I guess they do whatever they want anyway.

afragen · 2021-09-21T16:31:11Z

@dd32 as always I appreciate your insight.

Need to load the new dependency installer class in all plugins and themes where dependencies exist.
require_once ABSPATH . '/wp-admin/includes/class-wp-plugin-dependency-installer.php';

It would make more sense to not have that call in the plugin, but have it always loaded in the proper contexts for plugins to call it - for example, it wouldn't make sense to call it / load it on front-end requests.

Plugins would then either a) run on a certain hook or b) check if the class is loaded before calling it.

Last commit pre-loads relevant classes. No longer any need to require this class in plugins/themes.

Uses either a JSON config file or an array of data passed in code.

Having an array of passed in data in code has two main disadvantages to me:
a) Can't show information prior to the plugin being activated (or after it's deactivated)
b) Can't be easily detected by the WordPress.org plugin directory

Is there a need to show dependencies prior to the dependent plugin/theme being activated? The user can easily look at the plugin/theme code to discern this, alternatively the developer can/should put this information in the plugin/theme readme description.

[
  {
    "name": "Query Monitor",
    "slug": "query-monitor/query-monitor.php",
    "uri": "https://wordpress.org/plugins/query-monitor/",
    "required": false
  },
  {
    "name": "WooCommerce",
    "slug": "woocommerce/woocommerce.php",
    "uri": "https://wordpress.org/plugins/woocommerce/",
    "required": true
  }
]
First two things that I see here:

required being false kind of suggests that this is not a plugin dependencies, but rather a plugin suggestion. I can see that being abused by ACME Blocks suggesting ACME SEO and ACME CRM plugins very quickly. (Note: I recognise that Themes are where this is probably wanted)

slug should really be just that - a slug, woocommerce and should not reference the filename. The plugin filename can theoretically change, as well as, it being installed in a different location (for example, mu-plugins/woo/woocommerce.php). That's really something that would be only in a 0.01% of user type thing, but core does know the proper slugs of all the loaded plugins via the update api calls (I can't recall the transient that the slugs are stored in - it's not the update transient).

The array has been vastly simplified and only contains, name and slug. Thought core plugins are referenced in arrays by their slug/file_name. I can easily change this if it's confusing. Do you have a suggestion?

Example images. Plugin Dependency Feature (modified to use patch) and TwentyNineteen theme both have dependencies. Theme only has dependency for Hello Dolly.

Themes are the obvious use-case for suggested plugins, as currently WordPress.org-hosted themes cannot require a plugin, but can suggest it.

In this PR, required plugins are really only suggestions as there is not automatic installation/activation. The user can always dismiss the notice of the requirement.

It might make sense to have support for it in core, but have the WordPress.org directories reject suggested plugins for plugins, and reject required plugins for themes. But it kind of makes me hesitate as to whether it should be supported at all in core due to the abuse that pro/premium plugins could do.. but I guess they do whatever they want anyway.

There are no longer recommended plugins, only required plugins. Required plugins only come from dot org.

SergeyBiryukov · 2021-09-21T19:46:02Z

Is there a need to show dependencies prior to the dependent plugin/theme being activated? The user can easily look at the plugin/theme code to discern this, alternatively the developer can/should put this information in the plugin/theme readme description.

I think there is some benefit in having the dependencies displayed in a standardized way in advance, before activation and without looking at the code, so that the user knows what to expect when they attempt activating the plugin or theme.

afragen · 2021-09-21T19:53:41Z

@SergeyBiryukov is there a current standardized way?

The View details iframe or something else?

How is this currently being accomplished prior to plugin activation?

afragen · 2021-09-21T22:38:19Z

@SergeyBiryukov without attempting to activate a plugin, if the dependencies were in a JSON file it might be possible to read that, should it exist, and create some additional plugin group for dependencies.

Unfortunately there will be those who immediately discard this idea solely based on it using a JSON file. 😥

tomjn · 2021-09-21T23:37:21Z

@afragen displaying the slug would be an immediate improvement. I know you want a JSON file so you can specify a pretty name field but that would introduce security consequences, and it's simply not necessary.

I also oppose the snark, and the mischaracterisation.

I am happy for a JSON file, but it would be a plugin JSON file, e.g. plugin.json that was a replacement for a plugins header. Such a file would mean a wp-dependencies.json would be a temporary stopgap and additional technical debt. This combined with the fact that the only field the JSON file added that didn't have issues was the plugin slug, the use of a dedicated file could be whittled down to [ "woocommerce", "jetpack" ] which could be included in the plugiin header without the additional overhead/complexity of loading and processing another file.

I don't see why it can't be a future enhancement, or why it's necessary for this PR. There's no need, it's a preference.

But ignoring that, the file is dangerous and misleading, lets pick it apart line by line:

[
  {
    "name": "Query Monitor",

there is no enforcement, or updating. If a plugin changes hands this can and does change. Slugs do not change, adding bitrot. This field is superfluous. On top of that malicious actors can lie. What if we put Yoast SEO in here, and the user mistakenly believe it's been uninstalled and clicks it to reinstall, not realising it's actually for an unrelated plugin that has upsells.

    "slug": "query-monitor/query-monitor.php",

this implies a https://wordpress.org/plugins/query-monitor/query-monitor.php/, this is meant to be a .org plugin slug, not a plugin active main file to load. Also, plugins get refactored, if Query monitor ever switched to query-monitor/plugin.php this would break. The query-monitor part never changes though.

    "uri": "https://wordpress.org/plugins/query-monitor/",

this field has an ambiguous meaning, if it's exposed to the user it could be abused, but also lead to mismatched expectation, e.g. is this the .org URL because that's the QM site? Or because they thought it was the install URL? What if I put a link to cheap betting $$$? Can't this field be generated based on the .org slug? What happens if I put a paypal support link here? Or my personal website?

    "required": false

This is great, I can now list all my other products and spam you with free advertisements powered by core itself, and on every update I'll tweak the URI and name so it catches the user.

The format is ripe for abuse and malicious intervention. I expect plugins on .org that go through review will get caught, but aside from bitrot, every 3rd party plugin, every product on code canyon, is going to add this JSON file with a long list of recommendations of questionable value.

This is the future this file format will give us:

[
  {
    "name": "WooCommerce",
    "slug": "woocommerce/woocommerce.php",
    "uri": "https://wordpress.org/plugins/woocommerce/",
    "required": true
  },
  {
    "name": "Hypercharge Plugin Utilities",
    "slug": "dependency-marketing/campaigns.php",
    "uri": "http://wp-plugin-analytics.com",
    "required": true
  },
  {
    "name": "WooCommerce Membership Pro Offer Code MEMBERS20",
    "slug": "woocommerce-members",
    "uri": "https:/woosellers.tk/memberships",
    "required": false,
    "campaign-tracking-id": "GK92-18ED"
  },
  {
    "name": "WC Product Gallery Plus",
    "slug": "wc-product-gallery",
    "uri": "https:/woosellers.tk/product-gallery",
    "required": false,
    "campaign-tracking-id": "XK92-18SD"
  },
  {
    "name": "Star Sponsor: Turbopack, turbocharge your site",
    "slug": "jetpack",
    "uri": "https:/turbopack.com",
    "required": false,
    "campaign-tracking-id": "LLCJ-18SD"
  },
.....
]

tomjn · 2021-09-21T23:49:02Z

If you really want a JSON file, a plugin.json file that mirrors the theme.json added by FSE would be the best approach, and have its own ticket. I would advise that it use a single array of slugs as used by wordpress.org to define dependencies to avoid the security and abuse issues detailed above. This also opens the door to some rather pleasant integrations with FSE, global styles, and code reuse.

But such a file is not necessary to implement the ticket, nor is it within the scope. It would need a new ticket and a new PR.

As for the displaying of dependencies in advance, I would suggest the slug, as a clickable hyperlink that when clicked opens the same modal dialog that the plugin UI already uses to show the wp.org page when searching for plugins from WP Admin:

This allows the user to see what they're installing, not what the file "claims" it's installing, as well as a link to click through and see more detail and an up to date name. It even gives them a well tested install UX they're familiar with.

tomjn · 2021-09-21T23:55:21Z

I would also note, that plugin headers are loaded by get_plugin_data. This function is called by get_plugins which goes through every file looking for a plugin header, and loading it. The results are cached, so no additional performance cost is paid. This happens regardless of wether you use or do not use a JSON file, and it must be done to keep plugin compatibility and identify the main plugin file. Any claims of improved performance by using a JSON file for this are unfounded.

https://developer.wordpress.org/reference/functions/get_plugins/

peterwilsoncc · 2021-09-22T01:30:39Z

Two PRs with similar names are confusing.

I left a review on the other PR about 24 hours ago, some of which applies here for UI considerations. #1547 (review)

I also posted a comment on the ticket at around the same time detailing a way forward and requesting further architecture discussions before continuing to code up the PR. I think it might be best to hold off on cutting further code until some of these discussions are had.

afragen · 2021-09-22T04:57:38Z

@tomjn I apologize. If we ever get the opportunity to meet, the beers are on me.

The mostly current state of the code in this PR is outlined in #1674 (comment).

Fundamentally @aristath and I are working to the same goal with slightly different implementations and slightly different UI. Honestly I started along my path due to it's similarity to my other project for installing plugin dependencies.

Currently there is no JSON, only an array. There are only 2 elements to the array. If you don't like the variable names we can discuss that. But certainly there is no security risk to anything in those arrays. If the developer want to misrepresent the name of a plugin, they can. Not sure why they would but they can. In fact, the malicious entry I added to test your previous suggestion, results in a "failure to download". No harm, but a foul.

If a dependency has changed its file path the developer requiring the dependency should be aware and fix it. I use the <dir><file name> so that I can more easily target the plugin row without cycling through get_plugins(). For the other project it simply made more sense.

Plugins, once active, have full reign over the site. I know you know this; I repeat it only to say that an improperly coded plugin can and may cause damage. The plugin developer is responsible for the code they release. We all know of plugins that have changed developers and have become something other than what they were initially. The community finds out and people move on. If the developer isn't maintaining their plugin that's problematic on many different levels.

Can we discuss something other than how the dependencies are defined? I give up. I see that the preferred method defining dependencies will be a plugin header. This still leaves lots to discuss.

Should we concern ourselves with plugins that don't degrade gracefully when dependencies are missing? My feeling is no. It's a near impossible task to fix and adds unnecessary complexity.
What's the best method to inform user's of a dependency, an admin notice, a dependencies tab in the plugin page, something else?
How do we display the dependency information in the plugin row? Both Ari and I have different approaches.

There are weekly meetings Tues 1500 UTC for #core-auto-updates. I encourage everyone to join us.

afragen added 10 commits September 12, 2021 13:55

pass at plugin dependency installer

877182e

remove

4cc3833

add factory/singleton to accomodate mulitple input sources

1c98541

update for WPCS failures

c26bfa6

WPCS fixes

8d02adf

typo

7d67b01

hopefully this fixes

732080c

oops, shouldn't have removed 'data'

52e5fcd

add instructions to docblocks, style recommended vs required

5e11616

match style for recommended vs required

ce83b71

afragen added 3 commits September 16, 2021 21:04

initialize within class

3ed4475

only required dependencies

5c469ca

overwrite with most complete data

25d2f0c

ensure all calling plugins/themes are listed

remove JSON, use config array

cdf1d88

afragen added 4 commits September 17, 2021 21:58

fix WPCS

bd2f19e

fix JS 🤞

be96e73

pass ajaxurl to JS

2de95ec

variables used in window scope

2029c8b

remove JSON

ebe37fb

afragen added 3 commits September 20, 2021 09:38

update instructions to use WooCommerce,

eac7c90

fix closing tag

22649fb

remove mostly duplicate comment

d5ff0f9

pre-load classes

d195e2e

update instructions for admin notice

986418c

afragen changed the title ~~Implement WP Admin UI for Installation/Activation of Plugin/Theme Dependencies~~ Plugin Dependencies Sep 22, 2021

afragen closed this Feb 16, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Plugin Dependencies #1674

Plugin Dependencies #1674

afragen commented Sep 13, 2021 •

edited

Loading

afragen commented Sep 15, 2021

tomjn commented Sep 15, 2021 •

edited

Loading

afragen commented Sep 15, 2021 •

edited

Loading

tomjn commented Sep 16, 2021 •

edited

Loading

ideag commented Sep 16, 2021

afragen commented Sep 16, 2021

afragen commented Sep 16, 2021

tomjn commented Sep 16, 2021

afragen commented Sep 16, 2021

tomjn commented Sep 16, 2021

afragen commented Sep 17, 2021

afragen commented Sep 18, 2021

afragen commented Sep 18, 2021

afragen commented Sep 19, 2021 •

edited

Loading

BrianHenryIE commented Sep 20, 2021

afragen commented Sep 20, 2021

dd32 commented Sep 20, 2021

afragen commented Sep 21, 2021

SergeyBiryukov commented Sep 21, 2021

afragen commented Sep 21, 2021

afragen commented Sep 21, 2021

tomjn commented Sep 21, 2021

tomjn commented Sep 21, 2021

tomjn commented Sep 21, 2021

peterwilsoncc commented Sep 22, 2021

afragen commented Sep 22, 2021

Plugin Dependencies #1674

Plugin Dependencies #1674

Conversation

afragen commented Sep 13, 2021 • edited Loading

afragen commented Sep 15, 2021

tomjn commented Sep 15, 2021 • edited Loading

afragen commented Sep 15, 2021 • edited Loading

tomjn commented Sep 16, 2021 • edited Loading

ideag commented Sep 16, 2021

afragen commented Sep 16, 2021

afragen commented Sep 16, 2021

tomjn commented Sep 16, 2021

afragen commented Sep 16, 2021

tomjn commented Sep 16, 2021

afragen commented Sep 17, 2021

afragen commented Sep 18, 2021

afragen commented Sep 18, 2021

afragen commented Sep 19, 2021 • edited Loading

BrianHenryIE commented Sep 20, 2021

afragen commented Sep 20, 2021

dd32 commented Sep 20, 2021

afragen commented Sep 21, 2021

SergeyBiryukov commented Sep 21, 2021

afragen commented Sep 21, 2021

afragen commented Sep 21, 2021

tomjn commented Sep 21, 2021

tomjn commented Sep 21, 2021

tomjn commented Sep 21, 2021

peterwilsoncc commented Sep 22, 2021

afragen commented Sep 22, 2021

afragen commented Sep 13, 2021 •

edited

Loading

tomjn commented Sep 15, 2021 •

edited

Loading

afragen commented Sep 15, 2021 •

edited

Loading

tomjn commented Sep 16, 2021 •

edited

Loading

afragen commented Sep 19, 2021 •

edited

Loading