Posted by bibstha123 on November 13, 2009 at 11:29am
I've just stumbled into features / contexts recently and it is simply awesome.
I am wondering if synchronization of settings are possible using features / context?
I have a test machine and a deployment machine, where files are synchorinized using a git.
i'd like a way to easily synchronize menu settings, example i use the admin module and enable / disable menu items's visibility. Also, i change the input filters settings. Now to migrate those to production machine, have to manually do everything.'
What techniques do everyone use for such tasks?
Bibek Shrestha
Nepali Drupal Developer
http://www.yipl.com.np
Comments
Not exactly what you looking
Not exactly what you looking for, but for general settings you can try strongarm project: http://drupal.org/project/strongarm
Open Atrium has description of particular usage:
https://community.openatrium.com/documentation-en/node/449
Look for
6. Export any necessary variables (node type settings, etc.) using strongarm:
Maybe you can add some specific logic into your hook_strongarm() method.
Just an idea...
Thanks.
Strongarms works with variables
Strongarms works with variables, but does anyone know how to set some settings which are in the database?
I'm asking because I'm using features and strongarm to build a profile feature, and I have managed to set almost everything with them. Currently I have user profiles with lots of different fields (text, numbers, links, dates, location etc.) and panels are used to display them. I have hobbies and interests as taxonomies and I'm using taxonomy_redirect module to redirect these tags to user listing, so that by clicking another user's hobby, all the other users with the same hobby will be listed. The problem is, that I don't know how to include the redirect paths from taxonomy_redirect module's settings, because it stores them in the database.
If taxonomy_redirect stores
If taxonomy_redirect stores its settings in its own database table, then it needs to be patched to support features. A lot of modules are doing this by implementing the ctools export hooks. If someone hasn't already, I'd suggest that you file a feature request at the taxonomy_redirect issue queue asking for features integration.
--
Tom
www.systemseed.com - drupal development. drupal training. drupal support.
In the same boat
@bibstha123 I'm in the same boat.
I've been doing drupal dev for a few years, and just figuring out (now that I have a few sites up) that versioning small changes like that is a problem.
I see the "Feature" module as handling the larger elements. But I'm not quite sure how to handle the fiddle-y bits.
Perhaps we're having these issues because there is not enough structure/siloing (each feature independent) in our sites.
The question stands: What techniques does everyone use for versioning/pushing-live such tasks (menu changes, moving blocks around, input filter changes, etc.)?
using features hacks
i've been trying to use solutions that are intentionally integrated with features - context to handle block positioning, strongarm for variables, etc. but as you say, that leaves a number of things.
what seems to be working for other things is using a custom module that takes advantage of the features module's update and revert capabilities. the module does not really create anything. for the render output, it returns an array of miscellaneous information from the system - messaging templates, menu definitions, and so forth. then the custom module's revert function knows how to use that array to update the database. the code that does that exporting and importing is pretty hacky - direct database queries, form API calls, and the like - but it's still an improvement over the "write down what you did and then go do it again and don't forget anything" import method...
the useful part of that is that i can move changes back and forth, as our users make modifications directly on the live server as well as on the development site.
We usually write one-off
We usually write one-off updates in the .install file of our glue-code module, though Features is covering more and more of what we want.
I think what we really need to solve this problem is a central API for system settings in core. This API could also track some metadata that could make it easier to figure out what settings are relevant to the specific features you're interested in moving. I've started working on one at http://github.com/tizzo/system_settings (patches welcome!). The API is already locked for D7 so this will be for D8, though we could probably make a D7 install profile (with a series of core patches, unfortunately) to make it useful before then...
I'll release it on D.O once is complete/bug-free enough to provide a decent demo.