search

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.75k stars 431 forks source link

Add option 'strict_versions' #779 #780

Closed lwxbr closed 5 years ago

lwxbr commented 5 years ago

Add 'strict_versions' option to the TGM Plugin Activation. That allows to install the strict version of plugins defined in 'version' field of each plugin.

jrfnl commented 5 years ago

@lwxbr Thank you for your PR. Unfortunately this is not a feature we want to support.

TGMPA is designed to allow both themes as well as plugins to require/recommend dependency plugins. Each of these can set a (different) minimum version.

A strict_versions option does not allow for both a theme as well as a plugin to require the same dependency with different (minimum) versions. To be able to support that we'd need a far more complex system to figure out which version would meet the requirements of each theme/plugin requiring a certain dependency. This is not covered by your PR and is not something we would currently want to add or support.

lwxbr commented 5 years ago

@jrfnl, it's your call! I feel really sad that you as a mantainer didn't accept the feature. It's strange a person that mantains a open source project cannot "support" a feature and say that like if it was a hard thing to do (what I'm doing here trying to help you?). The lack of interest is visible, so why mantain the field 'version' in the plugin? It's useless if you can't install the version you specified in plugin's field. Well, I will close this pull request for now, feel free if you want to pull or not, the decision is yours. I will continue mantaining my fork. Thank you!

jrfnl commented 5 years ago

@lwxbr I'm sorry you feel this way, but can't say I appreciate the accusatory tone of your reply message.

I've tried to explain above in a friendly and patient manner why this PR is not acceptable, but as you don't seem to understand it, let me be blunt:

This PR does not solve anything, instead it introduces a major bug into TGMPA.

You are of course welcome to have your own fork of TGMPA, but in this case, I would strongly recommend against using your version as per this PR as it will cause problems and those are problems I, for one, am not willing to provide support for.

If you didn't understand the explanation above, you're welcome to ask me questions and I will try to answer them in an attempt to help you understand the problem this PR causes, but please don't expect me to merge a PR which purposefully introduces a bug into a system as widely used as TGMPA.

GaryJones commented 5 years ago

@lwxbr What is your use case for this feature? What advantage is pinning your dependency against a particular version (that may then cause dependency conflicts with other plugins or themes that require the same dependency)?

lwxbr commented 5 years ago

@GaryJones. I think there is a mistake here. See npm or composer as an example. How many times you have to fix the version of a dependency to do not break the entire aplication? It is very common in programming, i didn't invented that.

Well, I use WooCommerce 3.4.7 and I can't update it freely. There are hooks in the new version (3.6.4) that will break the plugins I developed for the platform. So I need the exactly the version 3.4.7. But is not only WooCommerce. I will update WooCommerce later but until there it will have to wait. I'm developing a theme for it. I understand if you should set the version of a plugin in TGMPA, it should download that version strictly (I don't see another meaning of the field, if you want the latest version, you should left the field 'version' empty).

@jrfnl, show me the bug then, let's fix them together! I tested here and it works! There's no way to implement a new feature without failure, it's how programming works and the way it is. I just don't understand your resistance to accept the feature. We can create a branch to test the feature without crash the stable version of the plugin.

GaryJones commented 5 years ago

See npm or composer as an example.

They both have very complex dependency resolution solutions.

They are also tools built for developers - not for someone who is setting up their first site with a theme and plugin from ThemeForest who frankly doesn't even care about what version something is.

TGMPA can't be compared to npm or Composer. Dependency management is hard, and it's why it's not yet been done in core.

Well, I use WooCommerce 3.4.7 and I can't update it freely. There are hooks in the new version (3.6.4) that will break the plugins I developed for the platform.

It sounds more like that you need to fix your plugins to work with multiple versions, rather than trying to restrict your customers / clients to old (and possibly insecure) versions of WooCommerce.

I understand if you should set the version of a plugin in TGMPA, it should download that version strictly (I don't see another meaning of the field, if you want the latest version, you should left the field 'version' empty).

As per our documentation, if the version is set, it is the minimum version. If a dependency is installed, but not at a new enough version, then TGMPA shows a different notice.

show me the bug then

The problem is that we don't isolate requirements in TGMPA.

We basically just override any previously set registration with a later registration to TGMPA (both for the plugins array as well as for the settings).

So if you have a theme and plugin both using TGMPA and one adds the strict_versions option, it will also be enforced for the other, which leads to unexpected (and undesired) results. Your PR doesn't address this.

This isn't a trivial issue to solve (see the previously mentioned fact that we don't have a comprehensive version resolution). With the current code, it isn't an issue, but introducing strict_versions, it would be.

Does that make sense?

There's no way to implement a new feature without failure, it's how programming works and the way it is.

I'm going to disagree on that. Bugs do happen of course, but introducing known bugs to something that has been relatively stable for a long while, for the sake of a "feature" that is ultimately flawed in its concept given the multi-use support of TGMPA, is a way to failure that we won't be taking.

I just don't understand your resistance to accept the feature.

We're not trying to be difficult here. Between myself and @jrfnl, we have about 45 years of combined development experience, and we appreciate contributions to projects like TGMPA. The use case you've presented however, and the implementation that comes with it, is focused on just your needs, of a single instance of TGMPA / single dependency of WooCommerce, and would give a potential negative impact to a much wider group of users.