I've edited and changed the default taxonomy term view and taxonomy term panel. I would like to package this as a feature and move it to my production site.

For the views, there is an option to check the taxonomy_term view when creating the feature, but then the view doesn't appear in the feature code. By looking at the name of the issue it looked like this would be relevant #709608: CTools: don't export default components from other modules/features but it didn't quite seem to apply to this situation. Maybe my situation (wanting to include default views when they are altered) got caught up in trying to fix something else.

The panel seems to be functioning as I expected (the panel in the feature code is being used).

Any thoughts or tips in the right direction?

Comments

mstef’s picture

mstef commented

I'm having a similar problem. I edited most of the views that Organic Groups ships with. Features isn't letting me export/override them. It makes sense that it doesn't but it's a little annoying.

That was done on purpose, right? Any way around this besides creating all new views and disabling the OG-shipped views?

Thanks

mstef’s picture

mstef commented

Anyone out there??

yhahn’s picture

yhahn commented
Status: Active » Closed (won't fix)

This is a current limitation of many exportable objects -- if an object is already an export (e.g. default Views provided by Views or OG), you cannot export a second, "overriding" version of that view.

To make this clear in the UI, see #650292: Limit export options only to current feature's components & 'normal' objects

sime’s picture

sime
any/any
Location Melbourne
commented
Status: Closed (won't fix) » Active

I don't know all the background but here is how I assumed it would work.

The first view, the default one in code, is represented in the feature by creating a dependency to the module that provides it. Straightfoward.

The second view, the overriding view that lives in the database. This is exported and placed in code, but *not* as a default view. When the feature installs (if that's what you call it) the default view is loaded, replaced by the exported view, and then the view is saved. This should effectively replicate the initial state -- in views we see the default view is enabled, overridden and customized.

yhahn’s picture

yhahn commented
Status: Active » Closed (won't fix)

Features will never write an override to the database for fully exportable components. It's just not part of our mission atm (see API.txt).

Addressing this issue fully requires concepting on how to best handle alters in a programmatic way to exportable components, would love to see some hard thinking on this front.

donquixote’s picture

donquixote commented

For now, I think I would just clone the view, and disable the original.
Problem: Disabling the original, also needs to be shared via git. hook_install?

would love to see some hard thinking on this front.

Nice.. where is this to happen? In gdo? Or right here?

jmev’s picture

jmev commented

I'm needing to do this with OG views, but if they can't be added to features, I have to have a way to update changes to them on target servers. Any thoughts?

5n00py’s picture

5n00py commented
Version: 6.x-1.0-beta6 » 7.x-2.x-dev
Issue summary: View changes
Status: Closed (won't fix) » Active

Maybe situation is changed since 2010 & 2011 years?

hefox’s picture

hefox commented
Category: Bug report » Support request
Status: Active » Closed (won't fix)

Nope, check out features override module