-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. |
Sure, something like that would be fine. commons-in-a-box has some On 06/09/2015 11:34 AM, Marshall Sorenson wrote:
|
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. |
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:
include
d. (This allows development to be separate, but doesn't help with the issue of distributing a plugin inside of a theme.)The text was updated successfully, but these errors were encountered: