Patch whisks away all CCK fields associated with Features that are Spaces-aware but not enabled in the current Space.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | spaces.887272-6.patch | 1.2 KB | Grayside |
| #3 | spaces.887272-2.patch | 972 bytes | Grayside |
| #2 | spaces.887272.patch | 976 bytes | Grayside |
| spaces.cck_.patch | 918 bytes | Grayside |
Comments
Comment #1
Grayside commented>.>
Comment #2
Grayside commentedFieldgroups too.
Comment #3
Grayside commentedWrong module prefix. Copy and paste errorism!
Comment #4
hefox commentedOkay, eye's paining so not making a patch atm but this is what I just altered to it.
For performance sake, I think it should be restrained to edit or be configurable.
Comment #5
Grayside commentedGood advancement. I'm not sure about integrating the nodereference in this way. There could be solid use cases for using a nodereference field to target nodes outside the current space. Contradicting that use case, this check does not evaluate Views-based referencable types, which is what I usually use in a Spaces environment when I care about limiting the values to local content.
Performance-wise, I'm a bit on the fence. It would be nice to hide the CCK values from the user if you no longer want them to show up.
The results of
features_get_component_map()is a static that should be available in memory on full node pages.spaces_access_feature()is cached and also a static. I haven't done actual performance testing, but this check should not be a big impact per field.Marking as Needs Work to at least reroll with improved basic integration.
Comment #6
Grayside commentedReroll with some tweaks from #4. I skipped the node reference validation and the suggestion to limit it to edit only pending further discussion.