Import/Export settings (Features integration)

I tested this patch, and while I got some whitespace errors when I applied it, the functionality works beautifully! My megamenu settings can finally be exported properly as part of a feature; yay!

Unfortunately, the block settings for where the megemenu block appears in the theme still can't be exported as part of a feature, but that's easy enough to write into an install hook (it's just one row per theme in the block menu).

After using this patch a bit more, I discovered a bit of an oddity: it was saving the megamenu settings variable as a stdClass object. Checking the {variables} tables revealed that all other variables are saved as arrays.

At first, I thought that this stdClass thing was causing a minor problem with my feature, which led me to writing this patch. Although my problem turned out not to be caused by megamenu, I felt like it'd be worth posting this patch, since it changes the original patch to use an array for all the megamenu variables, instead of a stdClass, which appears to be the standard.

Oops, I messed up the file paths in the patch. Here's the corrected one.

Oh wow, I knew that I was supposed to make a complete patch, and I thought I had, but I totally misinterpreted what the diff was telling me. I'm still pretty new to this whole patching thing.

As for the whitespace issues, like I mentioned in my original reply to this issue, there were some whitespace errors reported by git when I applied your original patch. That's probably where those are coming from. Besides, the changes that the patch does to those lines just removes unneeded whitespace at the end.

Hopefully this reroll will be better.

Just applied 1598510-9.patch: works as expected, megamenu settings exported correctly, update hook successfully updated the database. Marking patch as reviewed & tested.

Patched worked for us as well.

I imagine it's because this issue is old, but #9 didn't work for me. This line in the proposed 7001 update hook:

$mm = db_select('megamenu', 'mm')->fields('mm')->execute()->fetchAll();

was returning an object instead of an array. I updated it to:

$mm = db_select('megamenu', 'mm')->fields('mm')->execute()->fetchAll(PDO::FETCH_ASSOC);

And that fixed it for me.

I'm re-rolling the patch and including an interdiff.

Whoops! Forgot to change the status.

@mariacha1, your interdiff patch causes an error:
Error: Cannot use object of type stdClass as array in
/Users/ravery/Sites/perspectives/sites/all/modules/contrib/megamenu/megamenu.install, line 21
The external command could not be executed due to an application error. [error]
Finished performing updates.

..why is it necessary, again?

your other patch works marvelously.

@reubenavery That was a mistake from me... The interdiff.patch should just be an interdiff.txt and is just there for documentation purposes. Only the megamenu-convert-settings-to-variables-array-1598510-12.patch should be applied.

Sorry for the confusion!

Then I do declare this to be reviewed and tested by community. :-)

Nice work, thanks.

Patch at #12 still has whitespace issues I'm afraid.

Also,

I see two possible solutions :
- write functions to allow export/import settings plus features' hooks integration
- drop megamenu table in favor of drupal variables

Given we already have a table of settings, with a unique key, there is a 3rd option here: use CTools exportables. This is a reasonably simple matter of declaring the table to CTools, and changing the functions that retrieve data from the table to go via CTools. CTools takes care of declaring everything to Features.

That would be less of a change to the module, as the data storage would not need to be changed. Furthermore, I do think that going from a module-specific table to the variable table is a retrograde step.

Sorry, but I think this should go back to needs work.

Here's a patch that adds CTools exportables support.

I've added a function _megamenu_get_menu_by_name(), to load settings for a single megamenu. The admin form for a single megamenu and the theme output for a megamenu use this to get the settings, rather than call a helper function for each megamenu property.

These helpers -- _megamenu_is_enabled() / _megamenu_get_menu_orientation_by_name(), _megamenu_get_skin_by_name() / _megamenu_get_slot_orientation_by_name() / _megamenu_get_slot_attributes_by_name() are all removed as they're no longer used. (Their names start with an underscore, therefore by Drupal convention they are private and changing them doesn't break API. Also, this module is still in dev!)

The way that this module creates a DB row for every single menu in the {megamenu} table, even if the megamenu isn't enabled, goes against the grain of how CTools and Features work, but I don't think it'll cause any problems. It just means Features will report a Megamenu component for every menu, even ones that aren't enabled.