Consider a force_activation argument about tgm-plugin-activation

[thomasgriffin]

I completely agree. Having a plugin automatically installed is one thing - having it installed and activated is another. That would begin to scare people away if all of a sudden they activate a theme and they have 5 new plugins installed and activated.

If we go this route, I think there should be some type of message by either us or the developer to let users know that when their theme is installed, if X plugin is installed but not activated, X will be activated upon theme activation. Otherwise I think it does have its uses, especially for multisite.

[GaryJones]

Considering our code (and the registered plugins) isn't parsed until the theme is activated, how do you plan to pre-warn users?

[thomasgriffin]

Magic, of course. :)

Touche - then I suppose it would land upon the developers to do that when the user purchased the theme. At any rate, having a plugin automatically installed and activated without them knowing is a no go.

[jkudish]

I would recommend hooking in the page that display all the themes and display each theme's plugin dependencies on there [not sure if there's a hook for it, but hopefully yes]

[GaryJones]

Even if there was a hook, again, we can only show the plugins registered for the currently active theme, since that's the only set of files that will be getting parsed.

We don't really want to be manually reading the whole theme folders on the off-chance that they've got a class-tgm-plugin-activation (which they could rename) present, which might indicate they've registered some plugins, somewhere within all the theme files.

[jkudish]

That's definitely a good point. Perhaps you could implement something in the plugin stylesheet header like:

/* 
Theme Name: Some name
Author URL: http://example.com
....
Plugin dependencies: optionsframework, wp-e-commerce, etc...
*/

What do you think?

[GaryJones]

That's an interesting idea - but it would also mean the theme author / site administrator having to keep two lists of required plugins (and no way to mark your list as only recommended).

I'd also rather not have the public .css file being used to indicate what .php plugins are needed for the theme - that seems like a mis-use.

As things currently stand, it would be possible for a site administrator effectively drop the class file, and plugin registration for all the different themes the site supports, into a separate plugin, and activate it network-wide - meaning no themes (especially if they are automatically updatable) need to be edited to take advantage of the class. You solution requires that all themes that need required plugins registering, are edited manually.

[jkudish]

That's a pretty cool use-case actually.

I agree that the style.css header implementation is probably not the best solution, just an idea :)
I guess if a theme author absolutely wants to indicate that a plugin is required to run the theme, they can always just put it in the description of the theme.

[thomasgriffin]

Assigning this to Gary as well. I guess I can see the use behind this if the user already has the plugin installed but not activated, but again I still don't think it's a good idea. It's one thing to de-activate a plugin when activating a new theme because of potential issues or whatever the case may be, but it's another to re-activate something that they have already de-activated for whatever reason.

Again, it's up to the developers ultimately, so I'll trust your judgment on this one.