When I upgraded to ds-6.x-1.x-dev, after #1168130: Backport D7 data storage techniques for display settings was committed, I lost several of my node display layouts during the process. You may want to take another look at the update code.

First, it turned out that a few of my content types did not have corresponding settings variables in the variables table and those layouts didn't transfer at all. I don't know exactly how that happened, but it may have something to do with me using Features to store all of my DS configurations. I was able to work around this by exporting and then importing all of my content types using DS's import/export tools.

Then, when I tried the conversion again, most of my layouts transferred correctly, except for the layouts associated with custom build modes. They were completely missing and had to be recreated manually.

Comments

andyf’s picture

andyf commented

subscribe, wanting to avoid very large variables, and waiting for the next release and a clean update path.

xtfer’s picture

xtfer commented
Priority: Normal » Major

Bumping the priority on this as it can remove data.

xtfer’s picture

xtfer commented
Version: 6.x-1.x-dev » 6.x-2.x-dev
xtfer’s picture

xtfer commented

I have tested several variations with custom build modes and features and I haven't yet had a situation where they didn't transfer correctly, however there are three possible reasons why this might happen, that I have not yet tested...

Custom build mode added programatically but menu not rebuilt
If a custom build mode is added via HOOK_content_build_modes, but the menu is not rebuilt (through a cache flush, saving a custom build mode or other mechanism), then it wont appear in the list of current build modes accessed by the update hook, and thus will not be inserted into the database.

Custom build mode name longer than 32 characters
If a buildmode has a name longer than 32 characters, the drupal_write_record operation in the update hook would silently fail.

Reverting displays from Features used the wrong module name
This would create the appearance of a display disappearing, when in fact it was just saved to the database with the wrong module name. This was fixed in #1234070: Reverting a feature doesn't revert DS layouts.

@jstoller: If you can identify any of those circumstances that would help me knock this one over. I'm also not sure how you could have active ds build modes with no variables entry... are you using Object Cache?

jstoller’s picture

jstoller
he/him
commented

My longest build mode name is ten characters (front_page).

I am currently using Object Cache, but was not at the time I encountered this error.

In addition to the Features module, I am using Strongarm, which allows me to store variables from the variables table in my features. I did this with many of the DS variables, so that is likely why they had no entry in the table itself. They were in code. (at least, I think that's how that works)

Have you tried crating a Feature with custom build modes (and corresponding layouts), then installing that feature on a different Drupal install (so the layouts only exist in code) and then updating to ds-6.x-1.x-dev? Given Display Suite's rocky relationship with Features, I'm not sure if that would work on several levels, but it might bring the bug to the surface.

It looks like you're testing with ds-6.x-2.x-dev, which I know you completely refactored recently, so perhaps you fixed this bug without realizing it?

xtfer’s picture

xtfer commented

The tests were all done with 1.x installation and the tests included features across sites, as you describe.

The way ds works, all Features does is provide settings which are written to the variables table on install or revert. ds takes all its information from the record in the variables table, never directly from the feature, so you have to have a variables entry for it to work.

So I suspect the problem you have relates directly to storing ds configuration using strongarm (which, as I understand it, was not considered in the ds features process). Specifically, your issue might occur if you have strongarmed ds_all_build_modes prior to adding a new custom build mode, as this would trigger a condition similar to Custom build mode added programatically but menu not rebuilt (above).

I think strongarming build mode variables is probably a legitimate use of that functionaliy, it just wasn't accounted for, so i you can let me know which variables you strongarmed, I can test that configuration.

jstoller’s picture

jstoller
he/him
commented

Hmm. I don't think I had ds_all_build_modes in there, but I definitely had nd_build_modes, nd_buildmodes_exclude, nd_fields, nd_display_settings_[type] and nd_type_[type]. Basically any ND variable that looked like it might be important I stuck in a Feature. Variables and DS settings related to content types were in the same feature as the content type itself, spread over ten different features.

xtfer’s picture

xtfer commented

nd_build_modes might do it as well. I'll take a look.

xtfer’s picture

xtfer commented
Status: Active » Postponed (maintainer needs more info)

I can't replicate this currently. I suspect any cases of build modes not transferring result from one of the problems listed in #4, or from some other unusual configuration. I'll have to mark it postponed till some more information comes up.

fuzzyjared’s picture

fuzzyjared commented

I was able to replicate this issue outside of features. I had a long views title and it resulted in the layout from rendering or saving.

I created a new issue specific to the name length.

http://drupal.org/node/1427794

xtfer’s picture

xtfer commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Thanks FuzzyJared. Your issue is related, but I think this issue was really a collection of other smaller problems, like yours, most of which have been fixed. I'm going to close this properly and address your issue separately.