Write update script for child-theme settings change

[JiveDig]

I have multiple add-ons activated for different child themes installed. These are all child themes using the same parent theme (Genesis) if that matters. Customizations from 1 add-on are showing in the other... basically they are synced. I'm guessing because the same markup is used.

Simple answer is to deactivate or delete one add-on, but that isn't a good situation.

If Styles is used in a multisite environment, or if a user is unsure which theme they want to use for their website, they may have multiple child themes and styles add-ons activated while they decide.

Each child theme activated should act independently, even if others are still activated.

[pdclark]

Expected functionality is that settings should only merge if multiple plugins target the exact same theme or theme parent.

More specifically:

• Consider a plugin to be for a theme if the plugin header Plugin Name: Styles XXX matches a theme's Theme Name: XXX OR if the plugin folder name styles-XXX matches the theme folder name themes/XXX
• Only display options if a plugin's target theme is active
• If a plugin targets a parent theme, display settings for the parent and all children.
• If a plugin targets a child theme, only display for the child theme.
• If multiple plugins target the same theme at the same time, naming collisions might occur.

Are you seeing different behavior for auto-registration? It became clear in testing for notices over the last few days that covering all the possible combinations in testing manually can be unreliable, so I wouldn't be surprised if something is out of alignment.

In cases where auto-registration of a child theme doesn't make sense, it is possible to register plugins manually. The documented method for themes should work for most use cases, though, especially Networks. In my testing environment, I usually have several Styles plugins enabled without conflicts. (But again, parent-child relationships aren't as well tested.)

Manual registration of options is more meant for use cases like if we wanted to add options for Gravity Forms or some other plugin.

[JiveDig]

I am seeing different behavior.

My testing install specs:

Parent theme installed
Child theme XXX installed and/or activated
Child theme YYY installed and/or activated

Styles activated
Styles: XXX activated (targeting styles-child-xxx)
Styles: YYY activated (targeting styles-child-yyy directory)

It doesn't matter which child theme is activated (XXX or YYY), or which add-on is activated (Styles: XXX or Styles: YYY), the settings are always synced (the settings that share the same markup, which is most of them since they are base off the same parent theme).

With this setup, the add-ons are not acting independently.

[pdclark]

Can you share you real directory names, plugin headers, and theme directory names and headers? (The Git comments allow attaching a zip too).

[JiveDig]

Just emailed you a zip.

[pdclark]

Found the issue — it's storing the database key under the the template name, not the stylesheet name. (e.g., styles-genesis, not styles-sixteen-nine-pro). Should be a quick fix. I'm getting on a plane this evening; will see if I can patch it during the flight.

[pdclark]

Nevermind on waiting — you should see this resolved now in the current develop branch: https://github.com/stylesplugin/styles/archive/master.zip

On naming of the sections, is there any chance you can update some of the names to mirror the TwentyXXX naming more closely? We tried really hard to have all the names mirror exactly what users unfamiliar with CSS would know them as, specifically by taking the wording from the WordPress admin, and then ordering them from top-to-bottom as they appear on most pages top-to-bottom.

For example:

Headings
I realize this is new, and can understand why you'd want it.

• Perhaps split into Global — Defaults and Global — Headings (the emdashes are there to provide a scannable divider on the labels.)
• Name "Heading 1", instead of "h1" for the label, because that's what users see in the WordPress content editor drop-down menu. People who don't know CSS have never seen "h1" before.

Navigation
Name Menu — Primary... I realize Genesis doesn't use a menu position, but users will find it in WP Admin under Appearance > Menus, and the naming convention in core themes for the main menu is "Primary".

Pagination
Entry — Pagination

Sidebar
Move above Entry, and rename to Widgets — Sidebar, because users find it under Appearance > Widgets, in the "Sidebar" section.

Plugins
Move each plugin into a "Plugin — eNews" and "Plugin — Gravity Forms" (or just "eNews" and "Gravity Forms"). Possibly move both into their own plugin, rather than grouping into the child theme.

[JiveDig]

Oh interesting, I didn't realize the name mattered. I was basing the names as a general thing, and some of them based off the class name in the markup. I can rearrange them before I launch my shop.

[pdclark]

Reopening. This change wasn't ready for prime-time. I need to create a migration script to keep current users of child themes from losing their settings when they upgrade.

[pdclark]

Support thread: http://wordpress.org/support/topic/just-updated-the-styles-plugin-wiped-out-all-my-settings