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?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

Category: bug » feature

I 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.

joachim’s picture

Yeah, 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.

merlinofchaos’s picture

Right. 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.

joachim’s picture

That sounds like a plan :)

I'll see about working on a patch in the next few weeks.

merlinofchaos’s picture

Status: Active » Fixed

Committed a patch and documentation in export.html

joachim’s picture

That's great!
Sorry I didn't get round to this once myself.

Would you backport this if I work on the patch?

merlinofchaos’s picture

Sure.

joachim’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Fixed » Needs review
FileSize
7.19 KB

You forgot to close the I tag in the help file BTW ;)

Here's the patch for 6.x.

merlinofchaos’s picture

Status: Needs review » Fixed

Committed 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)

joachim’s picture

Yes, it did.

Thanks! :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.