To Infinity 1.2 and beyond

[MrMaz]

Hi Guys!

I have been chipping away at Infinity 1.2 over the past several months as time has allowed. Here are the highlights...

• No more dynamic/cache files.
• Passes theme check.
• Simplified options control panel (still in progress).
• Starting to get a handle on i18n.

I'm not sure how much you guys have tweaked the templates, etc but I doubt it will be a trivial merge as much has changed. I suggest a conversation be started about how to handle this.

Best,
Marshall

[BoweFrankema]

Sweet! I think those improvements will get rid of most reported issues and requests. Not much has changed in terms of templates over the last few point. I remember making a few small changes to the base CSS files, but those were very minimal. Merging back the changes should indeed be trivial.

Boone and I will both be going to WordCamp Europe end of this week, so we can then talk about the next release of Infinity/CBOX and see where we are at. Maybe we can schedule a short Skype meeting to talk this through? If not we can use this issue to work through getting to 1.2. Pretty excited :-)

[MrMaz]

I had to make some pretty massive changes to how the CSS is organized to get away from cache files. Basically it uses name spacing (via body classes) to toggle CSS off. Check out the Infinity master branch (not yet merged with buddypress branch) to see the changes.

[christianwach]

No more dynamic/cache files

Yay++ @MrMaz that'll make working with the theme a whole heap easier.

[MrMaz]

Here is the pot file I added after doing a bunch of clean up if anyone wants to start playing around with it.

https://github.com/PressCrew/infinity/tree/master/languages/infinity.pot

[r-a-y]

Check out the Infinity master branch (not yet merged with buddypress branch) to see the changes.

I've taken a quick test-drive of Infinity 1.2-bleeding and there's some nice work done to the options panel.

The media uploader still appears to be problematic though when selecting files. This is probably due to WP 3.6's media overhaul and is conflicting with Infinity's JS.

Also, master branch looks looks surprisingly decent with BP's theme compat!

@MrMaz - Can you summarize what the problems are with the potential merge?

Regarding BuddyPress templates, I don't believe much has changed from Infinity to CBOX Theme so we should be pretty safe here.

Regarding the regular page templates, I've noticed that the infinity_get_header(), infinity_get_template_part(), etc. functions have been replaced with WP's native functions in Infinity. Other than that, there might be some other differences in the page markup. @BoweFrankema would know more about this though.

I see a few things:

• Textdomain changes - this might sound as simple as doing a find and replace, but I'm wondering if there is anything we need to be aware of.
• CSS changes and how it will affect existing child themes - Bowe will probably have a better grasp on this than anyone else.

Overall, I think Infinity 1.2 is looking pretty good! Let us know if you have anything you want us to look at.

[BoweFrankema]

@MrMaz took a better look at your changes and I really like the new approach. Using a pre-fix body class is a good solution. There is going to be backwards compatibility issues though. By removing the front-end dynamic caching and re-organising the CSS, some child themes would have to move some stuff around. Some quick question:

1: Does infinity still look for the child theme folder for similar named assets (CSS/JS)?
2: Can styles and scripts still be enqueued through the ini files?

I've been looking into existing front-end development frameworks, and going to play around with Bootstrap 3. With BuddyPress 1.9 coming in the near future, and the increasing flexibility for BuddyPress theming, I think it's time to find a framework with great documentation and an active community of users. Not to mention full mobile/responsive support. Bootstrap seems to be the best option for that. For now I'll be playing around with it in a seperate branch, and see how hard it would be to convert the templates to Bootstrap.

[MrMaz]

@r-a-y Well, sir. I have nothing to add. You are bang on with all your points. Bowe's follow up pretty much answers your question about potential merge issues... but specifically: any CSS changes to Infinity core stuff in CBOX will probably have to be merged manually since files have since been combined. Also, some of the feature names have been changed to get them all in line with a similar naming convention.

@BoweFrankema The only thing that changed as far as file locating is the get_header() type of stuff in templates. The old get_infinity_* functions still exist, and can be used as needed for projects. All of the asset paths configured in INI files still use the stack for locating and enqueueing files.

Regarding a new design/responsive framework...

Nothing really even comes close to jQuery mobile from a "it just works" standpoint, but as usual they are all geeks first, designers second... errr 5th lol, so not sure how designer friendly it is. Not many know this, but its actually not a "mobile only" thing. Its meant to be "mobile first" and "desktop responsive" which is the new way of thinking I guess. Makes sense to me, since desktops are dying off, although you won't ever tear mine away from me! It has built-in touch support for handhelds and lap/desktop touch screens. Anyways, check out the list of mobile platforms and browsers they unit test against, and your jaw will hit the floor: http://jquerymobile.com/gbs/

Bootstrap is just awesome for design and rapid dev, but as usual they think they own the planet and STILL don't support class namespacing which causes me soooo many problems when, for instance, a plugin loads their own bootstrap theme on wp_head priority 99999. I haven't taken a deep dive into 3, so going to reserve judgement on some of my other outstanding gripes.

Thanks for the feedback guys. I am looking forward to moving forward with this!

[MrMaz]

Just a heads up in case anyone is doing anything super crazy.
PressCrew/infinity#90

[MrMaz]

I have updated issue PressCrew/infinity#90 and referenced the latest commit of the new kill-ini branch (PressCrew/infinity@aacbf65) which replaces INI config files with PHP config files that return arrays.

There is more work to be done to completely remove all traces of the hacky INI syntax from array keys and values, etc... but this opens to door to much cleaner and simpler configuration that utilizes big ole' nested arrays as popularized by "The WordPress Way."

Testing and feedback would be appreciated 😺

[boonebgorges]

Hey @mazftw - This seems pretty cool. But I'm wondering what this means
for backward compatibility. If I'm already using .ini files to customize
my site, this change will require me to reapply my modifications in the
new php format, right?

On 01/23/14 14:41, Marshall Sorenson wrote:

I have updated issue PressCrew/infinity#90
PressCrew/infinity#90 and referenced the
latest commit of the new kill-ini branch (PressCrew/infinity@aacbf65
PressCrew/infinity@aacbf65)
which replaces INI config files with PHP config files that return arrays.

There is more work to be done to completely remove all traces of the
hacky INI syntax from array keys and values, etc... but this opens to
door to much cleaner and simpler configuration that utilizes big ole'
nested arrays as popularized by "The WordPress Way."

Testing and feedback would be appreciated 😺

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

[MrMaz]

The INI files were only intended for theme developers to mess with, so there shouldn't be much blowback from end users. Its easy to convert the INI files to the new syntax :)

[boonebgorges]

True enough, but it's still something to prepare for and think about
when it comes time to release. Maybe this could correspond with Commons
in A Box 1.1? That'd suggest that it's a fairly large change, which
might alert people to any documentation we'd have in support of the change.

On 01/28/2014 09:11 AM, Marshall Sorenson wrote:

The INI files were only intended for theme developers to mess with, so
there shouldn't be much blowback from end users. Its easy to convert the
INI files to the new syntax :)

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

[MrMaz]

Just replaced the color picker script with the native Iris color picker which has been bundled with WP since 3.5: PressCrew/infinity@bd76c1c

[MrMaz]

Does anyone have an issue with dropping bp-default support? I would really like to clean up the theme and put all template overrides in a buddypress/ folder of the theme, which requires at least BuddyPress 1.7. Its been nearly a year since the 1.9 release which forced themes to turn on bp-default support if they still relied on it, so I'm comfortable switching to the "modern" theme compat.

[boonebgorges]

No problem here. Commons In A Box ships with BP 2.0.x, soon to be 2.1.x.

On 11/24/14 13:11, Marshall Sorenson wrote:

Does anyone have an issue with dropping bp-default support? I would
really like to clean up the theme and put all template overrides in a
buddypress/ folder of the theme, which requires at least BuddyPress 1.7.
Its been nearly a year since the 1.9 release which forced themes to turn
on bp-default support if they still relied on it, so I'm comfortable
switching to the "modern" theme compat.

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

[r-a-y]

The only problem I have is backward compatibility.

There are going to be some users that have overriden some templates in a
child theme. Once we move over to BP's theme compatibility, those users
will need to make adjustments to their child theme.

We also have to make sure the styling and / or markup is almost exactly
the same as before. Probably good to do this for CBOX 1.1.

[boonebgorges]

The only problem I have is backward compatibility.

Oh crud. We can probably create some magic that'll identify templates that are compatible with each other, and swap them out magically. Most of the non-top-level templates can be swapped out in this way.

We also have to make sure the styling and / or markup is almost exactly the same as before. Probably good to do this for CBOX 1.1.

+1

[MrMaz]

I don't have a problem with rolling the newest version with theme compat, and having a short lived (< 6 months) back compat branch with the templates in the old locations for installs that can't port over their templates easily/quickly.

The current Infinity branches are too long lived, and a detriment to the project because back porting is very tedious. Theme compat will allow Infinity to use one mainline of development with very short lived topic branches.

[MrMaz]

I am still chipping away at merging the changes between the core Infinity theme and the most recent BuddyPress legacy templates.

This task is complicated because we forked the BuddyPress theme CSS before it was reformatted by Paul, so I have to compare the histories twice (two different trees), and then compare the result of those against the legacy CSS which has undergone even further changes.

But there is some good news. After I compared the Infinity template changes to the default, there are ZERO diffs that need to be pushed forward into the legacy templates (you read that right). There might be for CBOX, but if there are, it should be easy to port them over.

At this point, I'm not sure if it makes sense to copy all of the legacy templates into a buddypress/ subdir since, as of yet, no tweaks are required. I think it could be beneficial to do so regardless, so that the templates are in a fixed state which could make support/debugging much easier, as well as allowing themers to easily grab templates from the parent theme instead of hunting for them in the plugin. Not many people understand the whole "locate template file in plugin sub folder" concept.

[MrMaz]

Had a brief conference call with @boonebgorges this morning regarding high level strategy with regards to Infinity/CBOX theme architecture. I wanted to summarize the main points for the rest of the team.

The goal is to:

1. Improve short/medium/long term BuddyPress UI compatibility.
2. Make the CBOX theme's ongoing maintenance less complex.
3. Make the CBOX theme's plugin UI compatibility layer available to more than just CBOX users.

The steps to take are:

1. Infinity core will adopt the majority of the CBOX theme's customizations as it's next generation base UI.
2. Infinity core will selectively, over several iterations, absorb the CBOX theme's curated plugin specific theme compatibility code, as determined by feasibility and time/effort required. Backwards compatibility wrapper functions will be provided (just in case).
3. Infinity core, and by extension the CBOX theme, will rely on the bp-legacy templates and design assets without copying/importing them. Ongoing backwards compatibility for the UI will be provided on an as needed basis as determined by the Infinity and CBOX teams.

Negative consequences:

1. There is a probability of regression issues that will need to be assessed and dealt with as encountered.
2. Manually overridden templates (via child theme) from the bp-default theme will have to be ported to the coinciding bp-legacy template.

Positive consequences:

1. The CBOX theme will become even more of a "skin" of Infinity, and it should become much easier to customize the design aspects.
2. Considerably valuable CBOX theming improvements to curated plugins like Docs, Wiki (and more) as well as general BuddyPress UI improvements will be accessible to a larger developer base via Infinity. These developer's contributions would then trickle up to the CBOX theme.
3. Infinity and CBOX teams will be able to collaborate on core code more easily, since a vast majority of the code will be in one repository. This could also lead to opportunities for CBOX team members and other CBOX developers to join the Infinity team.

Huge props to @BoweFrankema for originally suggesting the basis of this strategy many months ago.

If anyone has any feedback, questions or concerns, please comment on this issue and be heard :)

[mkgold]

This sounds great. Thanks so much, @MrMaz and @boonebgorges for charting this path, and thanks to @BoweFrankema for scouting it out at the beginning!

[BoweFrankema]

Awesome news, and I think it's a great move forward for CBOX & Infinity! Hope to jump into the development again in the near future, because this is some cool stuff happening!

[boonebgorges]

Awesome! Thanks for posting these notes.

On 12/09/14 13:47, Marshall Sorenson wrote:

Had a brief conference call with @boonebgorges
https://github.com/boonebgorges this morning regarding high level
strategy with regards to Infinity/CBOX theme architecture. I wanted to
summarize the main points for the rest of the team.

The goal is to:

1. Improve short/medium/long term BuddyPress UI compatibility.
2. Make the CBOX theme's ongoing maintenance less complex.
3. Make the CBOX theme's plugin UI compatibility layer available to
   more than just CBOX users.

The steps to take are:

1. Infinity core will adopt the majority of the CBOX theme's
   customizations as it's next generation base UI.
2. Infinity core will selectively, over several iterations, absorb the
   CBOX theme's curated plugin specific theme compatibility code, as
   determined by feasibility and time/effort required. Backwards
   compatibility wrapper functions will be provided (just in case).
3. Infinity core, and by extension the CBOX theme, will rely on the
   bp-legacy templates and design assets /without/ copying/importing
   them. Ongoing backwards compatibility for the UI will be provided on
   an as needed basis as determined by the Infinity and CBOX teams.

Negative consequences:

1. There is a probability of regression issues that will need to be
   assessed and dealt with as encountered.
2. Manually overridden templates (via child theme) from the bp-default
   theme will have to be ported to the coinciding bp-legacy template.

Positive consequences:

1. The CBOX theme will become even more of a "skin" of Infinity, and it
   should become much easier to customize the design aspects.
2. Considerably valuable CBOX theming improvements to curated plugins
   like Docs, Wiki (and more) as well as general BuddyPress UI
   improvements will be accessible to a larger developer base via
   Infinity. These developer's contributions would then trickle /up/ to
   the CBOX theme.
3. Infinity and CBOX teams will be able to collaborate on core code
   more easily, since a vast majority of the code will be in one
   repository. This could also lead to opportunities for CBOX team
   members and other CBOX developers to join the Infinity team.

Huge props to @BoweFrankema https://github.com/BoweFrankema for
originally suggesting the basis of this strategy many months ago.

If anyone has any feedback, questions or concerns, please comment on
this issue and be heard :)

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

[MrMaz]

Here are some notes and refs of what has changed so far with Infinity core. Mostly for tracking, but feel free to review and comment.

• Gutted Infinity BP support since bp-legacy handles 95% of it now, and assets are loaded from plugin: PressCrew/infinity@9d24625
• Stripped out custom BP css that was identical to the original bp-default theme: PressCrew/infinity@09a40e2
• Merged custom BP css with matching bp-legacy css blocks, removed tweaks that were not substantional (ie. font-size only 10% difference): PressCrew/infinity@459c94f
• Removed "text-rendering" rule from typography (and cleaned up indent): PressCrew/infinity@c913d6d
• Reorganized core responsive css and commented out BP specific tweaks (for now): PressCrew/infinity@d862444

There is still some design related eye sores but the goal for now is just to have it merged and working. We can pull out the microscope after the CBOX design is ported over to Infinity core.

[MrMaz]

Hi everyone.

I have made a ton of progress on this, getting very close to bundling up something for testing.

There is one issue that is giving me fits, which is the slider. There is nothing wrong with it, once its running really, except that it requires that two very large 3rd party libs to be bundled, and in the end is still difficult to set-up, configure and maintain.

I would really like to drop any kind of bundled slider in the theme, and instead move towards supporting a few of the most popular free slider plugins and list them as "supported" or "curated" or whatever. My gut is that this will be easier to support long term than maintaining a custom slider solution.

Please lmk your thoughts.

[christianwach]

+1 from me on this. I'm not a fan of the existing slider either. Which sliders have you been evaluating?

[boonebgorges]

Thanks, Marshall.

I'm sympathetic to your points about the slider, but we can't just pull
it out, as it'll break the home page of just about every Commons In A
Box installation in the world :)

If you don't want to ship it with cbox-theme, it'll have to be extracted
into a plugin, and there will have to be infrastructure in place to make
sure that anyone who upgrades a site using the slider will have the
plugin installed and activated. We could probably do some of this with
the existing Commons In A Box plugin installation architecture.

If we decide to go with this suggestion, I think we'll probably want to
pick what we think is the "best" slider plugin, and add it to the
Recommended slate of plugins installed when you set up your site.

On 02/23/2015 01:53 PM, Marshall Sorenson wrote:

Hi everyone.

I have made a ton of progress on this, getting very close to bundling up
something for testing.

There is one issue that is giving me fits, which is the slider. There is
nothing wrong with it, once its running really, except that it requires
that two very large 3rd party libs to be bundled, and in the end is
still difficult to set-up, configure and maintain.

I would really like to drop any kind of bundled slider in the theme, and
instead move towards supporting a few of the most popular free slider
plugins and list them as "supported" or "curated" or whatever. My gut is
that this will be easier to support long term than maintaining a custom
slider solution.

Please lmk your thoughts.

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

[MrMaz]

@christianwach I have been holding off on evaluating until I get a consensus from you guys. There are literally hundreds of them, but its seems like a quite a few of them are wildly popular and well supported.

@boonebgorges I wouldn't argue with leaving the existing slider in the cbox-theme with a deprecation notice about support being dropped in the future. I had a similar idea to pick the best slider plugin and install it via the CBOX plugin manager.

[BoweFrankema]

Should be relatively straightforward to extract the slider into a plugin. The only problem would be handling the configuration options.

I've always been a big fan on Meteor Slides.. it's very similar in functionality to what we have, but has a bunch more features. https://wordpress.org/plugins/meteor-slides/

[mkgold]

Hi All -- just want to second Boone's caution that we would need to proceed carefully with this, as the slider is a pretty central to the design of CBOX sites as they've been created so far.

Another option might be to develop an alternate theme that does not have a slider embedded from the start.

[MrMaz]

I don't want to drop the slider from the design. Just exploring a way to improve the slider experience all around. There definitely needs to be a transition from the existing solution to the next one that doesn't create any headaches.

[boonebgorges]

I do think that the transition will have to be more than a deprecation
notice - we will likely need to do something more automated than this.
But it's a bridge we can cross when we come to it.

On 02/23/15 14:35, Marshall Sorenson wrote:

I don't want to drop the slider from the design. Just exploring a way to
improve the slider experience all around. There definitely needs to be a
transition from the existing solution to the next one that doesn't
create any headaches.

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

[christianwach]

Presumably it would be possible to include the current slider by default even if there are filters (or other methods) which allow it to be switched out for a different one? Having delved into the slider in depth recently (see #230 which goes some way towards solving one of my biggest gripes with the slider at present) I suspect this is a non-trivial task. However, it seems to me that simply adding an alternative homepage template which is 'slider-agnostic' could provide a way forward which wouldn't require building an alternative theme.

[MrMaz]

I have also begun solving my biggest gripe with the slider on the back end. I found a tiny library to bundle which can handle back compat for dynamic image sizes. I am leaning towards a solution that goes something like: "The theme comes bundled with a basic slider. If you need more powerful features, try one of these 3rd party slider plugins that we are making an effort to support."

That leaves the door open to mothball it or improve it depending on how things go.

[BoweFrankema]

Simply providing a new template like @christianwach suggested might be the best solution. +1

[MrMaz]

I'm feeling like what I have is ready for testing. Hundreds of hours have gone into this, and an absolute truckload of code refactoring has been done. I expect some things to break in the beginning, but at this point I think throwing it in the fire will be more productive than continuing to analyze it.

If anyone has input on how to proceed, please chime in. Ray and Boone have a better idea than anyone on what backwards compatibility cases need to be tested, so maybe that should be the focus to start?

I am going to start putting together an automated build once I get some feedback on testing collaboration so that any fixes will be available to test immediately.

[boonebgorges]

@MrMaz - Thanks for your work on this. Am I correct that the master branch of https://github.com/PressCrew/infinity/ is what we should be testing?

I'll spend some time looking at it in detail next week.

[MrMaz]

@boonebgorges I actually haven't pushed anything yet. I have it on BitBucket for now, and I've already forward and back ported all of the changes between infinity and cbox-theme... so I didn't want to push to PressCrew/cbox-theme (which is a fork of cuny-academic-commons/cbox-theme) yet because I've restructured the directories to have all of the theme code under a src/ dir.

We should discuss whether we want to restructure the cuny-academic-commons/cbox-theme repo in the same manner and use ant to build then upload release zips, since simply tagging HEAD or a branch or whatever won't work under the new structure.

Another option would be to develop and build in a new development repo, then deep copy build/* to the cuny-academic-commons/cbox-theme repo and treat it as a "one way" repo for released code (ie not suitable for cloning and developing backports since it's a deep copy and not a fork).

HMU on Skype if you think this deserves a voice call to pound out the details.

[boonebgorges]

I'm not too concerned with how we build release zips, at least not at the moment. If you've been using ant to create builds for local development, then I'm happy to continue with it. WP and BP use Grunt, so that is another choice.

I think the best next step is probably for me and/or @r-a-y to start having a look at the changes, so that we can get a feel for backward compatibility issues. Can we get access to the repo where you've been doing your work?

[MrMaz]

I'm going to run one more round of upgrade tests and then I will push my repo to GitHub by tomorrow :)

[r-a-y]

Kind of related:
http://wptavern.com/wordpress-org-now-requires-theme-authors-to-use-the-customizer-to-build-theme-options

All themes on wp.org are now required to use the Theme Customizer for any theme options. I kind of hate this decision, but it's not a concern for us right now since we do not host cbox-theme on wp.org, but something to keep in mind.

[MrMaz]

Apologies for the delay. I ran into an issue with options not being imported correctly and I spent way to long trying to find a workaround. I'm just going to write the code to do it "the hard way" (read lots of copy and pasting option names, lol) today, so hopefully I can get this wrapped up.

[MrMaz]

I agree @r-a-y on the Theme Customizer decision.

I had already planned to make this possible for many of the global kinds of options, but the "Theme Optimizer Only" decision just absolutely REAKS of a move to make free themes work better on WordPress.com sites. I can't think of any other reason to completely take the choice away from end users that might want to make up their own mind about what works best for them.

[MrMaz]

Here is the repo: https://github.com/PressCrew/infinity-cbox

Simply running ant dist will build you a working theme at build/dist/cbox-theme.zip or you can just manually zip up the entire contents of the src/ dir into whatever zip prefix you need.

Any kind of back compat testing should really be done with the theme slug as exactly "cbox-theme" since the theme modifications api uses it internally as the suffix for the option key in the database.

I last did a fresh install test about a week ago, it seemed to be fine. Since then I have mostly been fighting with the option importing since I switched Infinity core to use the theme mod api.

I'm not really sure what to expect, but this was definitely not slapped together. Upgrading from 1.0.9 to this 1.1-bleeding works extremely well on my dev box. If you run into an issue, it's probably because I have been in a bubble for so long, or a compat issue that I didn't think of yet, lol.

Please post any issues to the infinity-cbox repo for now so we don't get confused about production vs bleeding issues until we can sort out how that will be handled moving forward.

Looking forward to working with you guys on this :)

[boonebgorges]

Awesome - thanks, Marshall! I'll take some time to look into this next week.

On 05/20/15 17:36, Marshall Sorenson wrote:

Here is the repo: https://github.com/PressCrew/infinity-cbox

Simply running |ant dist| will build you a working theme at
|build/dist/cbox-theme.zip| or you can just manually zip up the entire
contents of the |src/| dir into whatever zip prefix you need.

Any kind of back compat testing should really be done with the theme
slug as exactly "cbox-theme" since the theme modifications api uses it
internally as the suffix for the option key in the database.

I last did a fresh install test about a week ago, it seemed to be fine.
Since then I have mostly been fighting with the option importing since I
switched Infinity core to use the theme mod api.

I'm not really sure what to expect, but this was definitely not slapped
together. Upgrading from 1.0.9 to this 1.1-bleeding works extremely well
on my dev box. If you run into an issue, it's probably because I have
been in a bubble for so long, or a compat issue that I didn't think of
yet, lol.

Please post any issues to the infinity-cbox repo for now so we don't get
confused about production vs bleeding issues until we can sort out how
that will be handled moving forward.

Looking forward to working with you guys on this :)

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

[MrMaz]

Nobody is following the dev repo I created yet, so just a note here that last November the wordpress.org team apparently decided that themes are no longer allowed to register shortcodes or custom post types. Somehow I missed this with theme check, perhaps my plugin was out of date.

I already stripped out the custom shortcode stuff, it never really got off the ground anyways. I'm going to port the slider code from Infinity core to a plugin so that it can pass theme check. It will still be backwards compatible old themes, and use existing content. The settings might be trickier, will have to see how it goes.

It will need to be added to the list of bundled CBOX plugins. I'll post the plugin repo once I have working code in it.

[r-a-y]

Hi Marshall,

Just added myself as a watcher to the infinity-cbox repo. I plan to do some initial testing this week and will give you some feedback on it.

[MrMaz]

The slider has been removed from Infinity core and Infinity CBOX (bleeding).

Here is the new slider plugin that provides backwards compat, and could actually be pretty powerful going forward if it gets some love: https://github.com/PressCrew/infext-slider

In the interest of time, it has been developed to only work with Infinity based themes (there are enough slider plugins out there anyways). It is an excellent example of how a plugin can add new theme features and options that will show up in the control panel, all programmatically, using the new feature and option registration functions.