Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There is some movements to make module's settings exportable to support things like the Features module and migration and deployments better.
It would be really great if the Better Formats module could take care of exporting input formats and its settings and do the Features integration. This way one could package input formats into Features in a very powerful way.
I'll look into providing a patch for this.
Comment | File | Size | Author |
---|---|---|---|
#39 | better_formats-6.x-1.2.patch | 4.85 KB | moritzz |
#36 | better_formats.6-x.1.2.patch | 4.61 KB | tangent |
#34 | better_formats.6.x-1.2.patch | 4.77 KB | tangent |
#32 | 616496-better_formats-features.patch | 5.29 KB | dkingofpa |
#25 | 616496-better_formats-features.patch | 5.24 KB | dkingofpa |
Comments
Comment #1
catchI'm also interested in this, most standard way would be to use ctools exportables. I'm unlikely to have time to write a patch, but would definitely review / test one to get it rtbc.
Comment #2
nedjoInput formats are already included in features via the features.filter.inc file, though it doesn't yet include a hook_features_export_options() implementation so filters don't appear as a component that can be added to features.
Add this to get filter formats at least showing up:
Of course, the additional data from better formats isn't included.
Comment #3
catchHere's a very rough patch. Doesn't yet attempt to integrate with features' own input format integration. Also relies on hard coded user roles etc. and reverting isn't working yet with latest features beta. Hopefully gets things off to a start though.
Comment #4
dragonwize CreditAttribution: dragonwize commentedGood work catch. I will review this and hopefully be able to help out soon.
Comment #5
catchReverting now works. So within itself, this is somewhat there, the real problems are how to deal with numeric / arbitrary user roles and format ids. I'm using this for upgrading a site from Drupal 5 to Drupal 6 (which it's perfect for) rather than trying to build features to deploy on multiple different sites so this is likely as far as I'll take it at this point. However I'll continue to try to keep an eye out on this issue, and I also need wysiwyg module support for exactly the same reason.
Comment #6
mrfelton CreditAttribution: mrfelton commentedregistering my interest in this...
EDIT: The seems to do nothing for me (using very latest features)... I see no option to export better formats settings from within features.
EDIT2: I take it back... works perfectly!
Comment #7
rickvug CreditAttribution: rickvug commentedtagging.
Comment #8
DeeLay CreditAttribution: DeeLay commentedsubscribe
Comment #9
wik CreditAttribution: wik commentedsubscribe
Comment #10
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #11
Mac Clemmens CreditAttribution: Mac Clemmens commentedsubscribing
Comment #12
ManyNancy CreditAttribution: ManyNancy commentedSubscribing
Comment #13
dagmarI have recently uploaded http://drupal.org/project/input_formats to deal with the numeric ids for input formats. Please, take a look to this module and provide some feedback :)
Maybe we can make an integration with this patch and import better formats settings using machine_names instead of numeric ids.
Comment #14
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedsubscribing
Comment #15
FiNeX CreditAttribution: FiNeX commentedsubscribing
Comment #16
nedjoSee #624018: Exportables and Features support for WYSIWYG 7.x on Wysiwyg module for relevant approaches and discussion.
Comment #17
lolmaus CreditAttribution: lolmaus commentedSubscribing
Comment #18
wizonesolutionsHi - do you guys think this will make it into Better Formats 2.x? Seems like I'll be applying the patch for now. 1.2 doesn't appear to have it.
Thanks,
Kevin
Comment #19
YesCT CreditAttribution: YesCT commenteda lullabot article on a wysiwyg feature mentions this issue is necessary before better formats could be used in a feature.
http://www.lullabot.com/articles/wysiwyg-feature
I mention this because I was setting up a new site, and I thought, Oh great! A Feature I can just grap, they probably use better formats ... but alas they could not. (also subscribing)
Comment #20
Josh Benner CreditAttribution: Josh Benner commentedsubscribing
Comment #21
DamienMcKennaThe patch still works with Features v6.x-1.0-rc1. +1
Comment #22
DamienMcKennaThe UI works but the output is incorrect.
Problem 1: This should instead have only listed the two roles I had selected.
Problem 2: Clearly this should only list values where "rid" was one of the two roles I selected.
Comment #23
nedjoShould not be applied without suitable machine names. Most promising model is the approach used in #624018: Exportables and Features support for WYSIWYG 7.x.
Comment #24
pearcec CreditAttribution: pearcec commentedsub
Comment #25
dkingofpa CreditAttribution: dkingofpa commentedReworked patch from #5. The numeric IDs are still exported, but not used for the revert/rebuild.
1) Now uses machine names from the roles table for roles.
2) Now uses machine names from the exportables table for input formats.
3) Only the selected better formats are exported as requested by #22.
4) Exported defaults are now placed in their own file: [module].features.better_formats.inc
I did this against 6.x-1.2 since that was the last released version.
Comment #26
scottrigby@dkingofpa: why is there a left join on {exportables}? I may be missing something
Comment #27
dkingofpa CreditAttribution: dkingofpa commented@scottrigby: There is a left outer join on {better_formats_defaults} and {exportables} because better formats stores a non-existent input format, 'site default', as id 0. The {exportables} table only stores machine names for existing input formats (for example filtered_html and full_html). Without the left outer join, better formats for all the selected roles may not be exported.
Comment #28
dkingofpa CreditAttribution: dkingofpa commentedHaven't heard anything more so I'm moving this back to 'needs review'.
Comment #29
scottrigby@dkingofpa: Nice - this does seem to work smoothly from testing so far... after enabling exportables & input_formats modules :)
The problem is those aren't set as dependencies; resulting in two errors: missing {exportables} table, and call to undefined function (input_formats_load_by_name()). We could wrap the query/functions in module_exists() - but then users would wonder why exports aren't working.
Personally I'd just add dependencies to better_formats since we always use features to store configs - but not everyone does. Maybe put this in an optional sub-module (better_formats_export) or something?
Either way, features would then need to add better_formats (or submodule) to dependencies[] in the feature when exporting. Then it seems like we'd be covered!
Comment #30
scottrigbyAlso in better_formats_features_export_render() the table needs to be aliased, otherwise it fails with db prefixes:
I'd re-roll the patch for further discussion, but i think it needs more work, per #29.
Comment #31
dixon_Really nice to see some work on this! I'll jump in later today and review and test the latest patch!
Comment #32
dkingofpa CreditAttribution: dkingofpa commentedRe-rolled patch from #25.
Fixed table alias as noted in #30 (good catch).
Fixed call to watchdog in export_rebuild to provide useful info.
As per #29...I guess that's an issue for the maintainer, dragonwize. I don't think I'm going to be working on that for a multitude of reasons (module stagnation, D7, don't know what solution dragonwize wants).
Comment #33
dragonwize CreditAttribution: dragonwize commentedJust to give my thoughts on this:
This is a feature that I personally do not need to see the value in, at least in its current form. However, I do see that many people do and that is great. I see and read every post made in the issue queue, unless the notification fails for some reason, so even though I may not comment on every thing I will chime in when asked or I feel the need.
That being said my opinion, which can always be debated, is that this work continue in this thread with the people who care about the feature participating.
I do not see a patch to the core BF module with these features except to add any API level support for this feature.
I would support this being a separate module as suggested in #29 especially in D6.
D7 has built-in support for string format IDs and much better format support in general. So depending on the level extra changes needed in D7 to make this happen I could see it integrated or as a separate module.
When the code in this queue is sufficiently tested and is reviewed by several people, I will commit it.
Comment #34
tangent CreditAttribution: tangent commentedI would really like to see this feature get added.
I've created a modified version of the patch, created against 6.x-1.2 but it should also apply to 2.0-dev I believe. It moves most features hooks to a separate include and changes some of the hooks to show friendly names. Better Formats global settings are just drupal variables that can be handled with strongarm so they aren't handled here. This patch works well enough for me.
Comment #35
DamienMcKennaNeeds some formatting updates per the Drupal coding standards.
Comment #36
tangent CreditAttribution: tangent commentedI've re-rolled the patch with code style fixes.
Comment #37
tangent CreditAttribution: tangent commentedCan someone please give my patch a test run (or a review at least) so we can move this issue forward?
Comment #38
logaritmisk CreditAttribution: logaritmisk commentedIt does what it is suppose to do, I had no issues.
Comment #39
moritzz CreditAttribution: moritzz commentedAs far as I can tell this patch didn't work on "per node" format settings. I therefore optimized and extended it. Check it out. (Because the exported defaults array is now keyed by config type, node type and role issues mentioned above should be fixed.)
Comment #40
moritzz CreditAttribution: moritzz commentedThanks @nedjo. I posted a patch to features' issue queue that adds your code: See #1156778: Export Filters (Input Formats) With Features for Drupal 6
Comment #41
alberto56 CreditAttribution: alberto56 commentedsubscribing
Comment #42
mikebell_ CreditAttribution: mikebell_ commentedI've applied and tested the patch from #39 and can confirm it's working as expected.
Comment #43
lpalgarvio CreditAttribution: lpalgarvio commented+1 for this
Comment #44
mikebell_ CreditAttribution: mikebell_ commentedAfter using this patch for a few weeks it always seems to be overridden, not had chance to look into this further.
Comment #45
Crom CreditAttribution: Crom commentedI've used the patch at #39 and experienced:
Settings were correctly exported to the feature as far as I can tell.
admin/settings/filters/defaults - roles present and in correct priority order but defaults not correctly set
This caused the settings page to not to be imported properly as the roles didn't have proper permissions for the different formats.
Hope this helps,
Crom
UPDATE: Also, better formats now appears twice in the exported feature .info file. You can delete it of course but it gets re-exported each time you create a new version
Comment #46
Robert Castelo CreditAttribution: Robert Castelo commentedSubscribing.
Comment #47
Elijah LynnIs any of this in 6.x-2.x-dev?
Comment #48
dragonwize CreditAttribution: dragonwize commented6.x is now unsupported.