From the docs:
Exportable objects have several reserved keys that are used by the CTools export API. Each key can be found at $myobj->{$key} on an object loaded through ctools_export_load_object(). Implementing modules should not use these keys as they will be overwritten by the CTools export API.
[SNIP]
type
A string representing the storage type of this object. Can be one of the following:* Normal is an object that lives only in the database.
* Overridden is an object that lives in the database and is overriding the exported configuration of a corresponding object in code.
* Default is an object that lives only in code.
Is that really the case? Because that's a pretty big DX WTF -- most things in Drupal have a type, a lot of things you might want to define in a custom module have a type, and that's a pretty generic key to take over.
Perhaps something more descriptive like export_status instead?
Comment | File | Size | Author |
---|---|---|---|
#8 | 1094014.ctools-6x.export-type-string.patch | 7.19 KB | joachim |
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedI agree, I run into this every now and then and it's one of those things that is difficult to change, because a not insignificant amount of code relies on it.
I can't really classify this as a bug. It functions, it is just a WTF.
Comment #2
joachim CreditAttribution: joachim commentedYeah, I wasn't sure what category to put it into :)
Looking at the ctools code it looks like it's only ever used for holding translated strings, eg t('Local'), t('Overridden'). So it looks like it's just providing the string that modules can choose to show on their admin listing of objects.
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedRight. Which is still used by the majority of modules utilizing the export UI.
Maybe if we put some kind of versioning flag in so that we could change it and if you set that you're using the 2.0 version of the API, it'd be export_type and if not, it'd be type, and thus we wouldn't break all existing code in one swell foop.
Comment #4
joachim CreditAttribution: joachim commentedThat sounds like a plan :)
I'll see about working on a patch in the next few weeks.
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedCommitted a patch and documentation in export.html
Comment #6
joachim CreditAttribution: joachim commentedThat's great!
Sorry I didn't get round to this once myself.
Would you backport this if I work on the patch?
Comment #7
merlinofchaos CreditAttribution: merlinofchaos commentedSure.
Comment #8
joachim CreditAttribution: joachim commentedYou forgot to close the I tag in the help file BTW ;)
Here's the patch for 6.x.
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedCommitted the backport, fixed the unclosed
<i>
tag. I assume your patch closed that tag in D6 so I don't have to fix it manually there (I admit I didn't look)Comment #10
joachim CreditAttribution: joachim commentedYes, it did.
Thanks! :)