-
Notifications
You must be signed in to change notification settings - Fork 9
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
Write update script for child-theme settings change #29
Comments
Expected functionality is that settings should only merge if multiple plugins target the exact same theme or theme parent. More specifically:
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. |
I am seeing different behavior. My testing install specs: Parent theme installed Styles activated 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. |
Can you share you real directory names, plugin headers, and theme directory names and headers? (The Git comments allow attaching a zip too). |
Just emailed you a zip. |
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. |
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
Navigation Pagination Sidebar Plugins |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: