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

Slider plugin migration #7

Open
boonebgorges opened this issue Jun 9, 2015 · 3 comments
Open

Slider plugin migration #7

boonebgorges opened this issue Jun 9, 2015 · 3 comments

Comments

@boonebgorges
Copy link

1fc791a removes the slider from cbox-theme/infinity and moves it to a separate plugin.

Among various backward-compatibility concerns with the theme rewrite, this one (along with settings migration, which is already handled quite elegantly) is critical. Users who upgrade their theme should be able to migrate with minimal effort - ideally zero effort.

A couple of ideas for discussion:

  1. Modify commons-in-a-box to support the following workflow: the cbox-theme theme will require the infext-slider plugin, so that when activating cbox-theme, infext-slider will be automatically installed and activated. @r-a-y How much work would this be?
  2. Add infext-slider to the list of Recommended plugins, to be installed when commons-in-a-box is updated/installed.
  3. Do (1) for existing users of the slider (as determined by, say, querying for the CPT), and (2) for other installs.
  4. As part of the cbox-theme distribution build process, grab infext-slider from its separate repo. Put it somewhere into the theme itself, where it can be included. (This allows development to be separate, but doesn't help with the issue of distributing a plugin inside of a theme.)
  5. Do nothing automatic for existing users, but show them a notice that they should install infext-slider. Presumably this would go hand-in-hand with (2). (I strongly recommend that we don't do this, but just throwing it out there.)
@MrMaz
Copy link
Member

MrMaz commented Jun 9, 2015

As part of trying to make Infinity compatible with a popular theme store, I encountered a requirement that plugins NOT be bundled, but that the TGM api be used to download, install, activate the plugins from external resources instead of bundling them:

http://tgmpluginactivation.com/

I was already going to play around with it, at the very least to see if it makes theme-check puke. If there are no objections to this kind of solution, then I will move forward with testing it out.

@boonebgorges
Copy link
Author

Sure, something like that would be fine. commons-in-a-box has some
internal logic to handle stuff like this (that's the whole purpose of
the plugin) but if Infinity handled it all by itself, all the better.

On 06/09/2015 11:34 AM, Marshall Sorenson wrote:

As part of trying to make Infinity compatible with a popular theme
store, I encountered a requirement that plugins NOT be bundled, but that
the TGM api be used to download, install, activate the plugins from
external resources instead of bundling them:

http://tgmpluginactivation.com/

I was already going to play around with it, at the very least to see if
it makes theme-check puke. If there are no objections to this kind of
solution, then I will move forward with testing it out.


Reply to this email directly or view it on GitHub
#7 (comment).

@MrMaz
Copy link
Member

MrMaz commented Jun 9, 2015

Yes... I don't intend on rolling a sweet interface like cbox has, at least to start. Hopefully it's not too difficult to just make a callback available so a fork or child theme can say "try to activate supported plugin: xyz" in cases where it's critical for back compat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants