Update Commons Features for cosmetic/syntactic changes [#2086905]

Several Commons features may appear overridden on a Fresh install of Commons. For the underlying cause and in-progress resolution of each issue, see:
#2065211: Cleanup commons browsing widget views
#2093413: Commons notify appears overidden: commons_search_solr_user_entity_info_alter changes field definitions to include search_results

Original summary
hello, i am in the process of doing the update from 3.2 to 3.3. I am following the instructions at https://docs.acquia.com/commons/upgrade
There are several features I cannot get to revert. I have run the command dozens of times, cleared all caches, tried using the web interface instead, applied --force option, etc, and the features remain overridden. (Other features not mentioned below did revert successfully.)
The revert command seems to complete without error, but has no effect on the feature state.
Can I continue with these features in overridden states?
Or how can I succeed in reverting them?

% drush -y fr commons_events commons_q_a commons_follow_term
Do you really want to revert field_instance? (y/n): y
Reverted field_instance.                                             [ok]
Do you really want to revert variable? (y/n): y
Reverted variable.                                                   [ok]
Do you really want to revert flag? (y/n): y
Reverted flag.        [ok]

% drush cc all
'all' cache was cleared in XXXXXX    [success]

% drush -y fr commons_events commons_q_a commons_follow_term
Do you really want to revert field_instance? (y/n): y
Reverted field_instance.                                             [ok]
Do you really want to revert variable? (y/n): y
Reverted variable.                                                   [ok]
Do you really want to revert flag? (y/n): y
Reverted flag.                                                       [ok]

Any help appreciated, since i'm not sure if these are acceptable and i should continue with the rest of the upgrade path, or i'm stuck here until I figure out how to resolve this issue.

thanks.

Comment	File	Size	Author
#25	2086905-featureapi2update-25.patch	144.07 KB	ezra-g
#24	2086905-featureapi2update-24.patch	144.1 KB	ezra-g
#16	2086905-featureapi2update-16.patch	149.92 KB	japerry
#14	2086905-featureapi2update-13.patch	154.82 KB	japerry
#9	2086905-featureapi2update.patch	205.08 KB	japerry

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

WebSinPat CreditAttribution: WebSinPat commented 11 September 2013 at 17:23

not sure if my issue is the same as this other features revert issue #2021897: Unable to revert several features for commons_*

Comment #2

ezra-g CreditAttribution: ezra-g commented 11 September 2013 at 19:32

Status:

Active

» Postponed (maintainer needs more info)

Have you tried the following?

drush features-revert-all --force -y

Comment #3

anemirovsky CreditAttribution: anemirovsky commented 13 September 2013 at 18:34

Having the same issue here and tried to force revert with the drush command to no avail.

Comment #4

WebSinPat CreditAttribution: WebSinPat commented 13 September 2013 at 20:19

Status:

Postponed (maintainer needs more info)

» Active

@ezra-g drush fra --force command succeeds and claims to revert, but again has no real effect on the features that are stuck.

@anemirovsky: are you having the issue with the same overridden features as my example, or is your case different features that are stuck?

Comment #5

WebSinPat CreditAttribution: WebSinPat commented 19 September 2013 at 01:57

I do not know if this is related or not but ---
one place where my features will not revert is in commons_follow_term, where flag feature will not revert.

In looking around the commons_follow_term directory, i was reminded that I applied a patch on commons_follow_term.module related to a bug in flag #1871602: The following token types are not defined but have tokens: $info['types']['taxonomy_term']. I don't know if that is causing a difference somewhere that is preventing the revert, or if it's just a coincidence involving those two modules.

also, it seems like the 3.3 version of commons_follow_term in my directory does NOT actually include the changes made in #1871602. I don't know why that would be since i thought the code was committed, or if it has anything to do with the revert problems.

Comment #6

japerry

KVUO

CreditAttribution: japerry commented 19 September 2013 at 17:53

Title:	unable to revert all features on 3.3 update	» Multiple features are out-of-date in commons 3.3
Assigned:	Unassigned	» japerry
Category:	support	» task

We need to make numerous tweaks to most features in commons. There is at least one issue with flags that we need to apply to make flag features not show as overridden.

https://drupal.org/node/1971980#comment-7878287

Comment #7

ezra-g CreditAttribution: ezra-g commented 19 September 2013 at 17:57

#2090167: Features not reverting - possible solution is marked as a duplicate of this issue.

Comment #8

japerry

KVUO

CreditAttribution: japerry commented 19 September 2013 at 19:37

Issues related to causing features to be overridden

#2065211: Cleanup commons browsing widget views
#2093405: Convert panel features without UUIDs to use new UUID schema for translatability
#2093413: Commons notify appears overidden: commons_search_solr_user_entity_info_alter changes field definitions to include search_results

Comment #9

japerry

KVUO

CreditAttribution: japerry commented 20 September 2013 at 16:57

Status:

Active

» Needs review

File	Size
2086905-featureapi2update.patch	205.08 KB

Here is an initial patch, it doesn't resolve the above issue, it just re-exports to the new standards of features ~~1.0~~ 2.0. Test and see if some overridden panels are working now, this should fix it and not require UUID.

Comment #10

ezra-g CreditAttribution: ezra-g commented 20 September 2013 at 15:28

it just re-exports to the new standards of features 1.0.

I believe this refers to 2.0. Since this is actually the patch for #2093405: Convert panel features without UUIDs to use new UUID schema for translatability, I marked that issue as "needs review" and updated the issue summary for the present issue.

Comment #11

japerry

KVUO

CreditAttribution: japerry commented 20 September 2013 at 16:58

Status:

Needs review

» Active

Yes 2.0. the 1 and 2 keys are too close to each other ;-)

Comment #12

japerry

KVUO

CreditAttribution: japerry commented 20 September 2013 at 16:58

Yes 2.0. the 1 and 2 keys are too close to each other ;-)

Comment #13

japerry

KVUO

CreditAttribution: japerry commented 20 September 2013 at 19:16

This patch updates all features besides the ones in the UUID issue, because I think its best to test these separate.

This still needs issues in #8 to be resolved in order to be default. With this patch you should still see the following:

 Commons Groups                       commons_groups                   Enabled   7.x-3.0               Overridden 
 Commons Like                         commons_like                     Enabled                         Overridden        
 Commons Notify                       commons_notify                   Enabled                         Overridden 
 Commons Polls                        commons_polls                    Enabled                         Overridden 
 Commons Posts                        commons_posts                    Enabled                                Overridden 
 Commons Profile Base                 commons_profile_base             Enabled                           Overridden 
 Commons Profile (Social fields)      commons_profile_social           Enabled                         Overridden 
 Commons Q&A                          commons_q_a                      Enabled                                 Overridden 
 Commons Trusted Contacts             commons_trusted_contacts         Enabled   7.x-3.0     Overridden     
 Commons Wikis                        commons_wikis                    Enabled                         Overridden

Comment #14

japerry

KVUO

CreditAttribution: japerry commented 20 September 2013 at 19:17

Status:

Active

» Needs review

File	Size
2086905-featureapi2update-13.patch	154.82 KB

gah. hit attach.. =P

Comment #15

ezra-g CreditAttribution: ezra-g commented 20 September 2013 at 20:26

Status:

Needs review

» Needs work

This is a great start - The changes here indeed are mostly cosmetic.

A few issues:

A) These instances are dynamically defined (see commons_groups_system_info_alter) and shouldn't appear in the info file:

+features[field_instance][] = node-group-field_group_logo
+features[field_instance][] = node-group-field_og_access_default_value
+features[field_instance][] = node-group-field_og_subscribe_settings
+features[field_instance][] = node-group-group_access
 features[field_instance][] = node-group-group_group
+features[field_instance][] = node-group-og_roles_permissions

B) Looks like some pagers change IDs. If this reflects a predictable pager ID as is dynamically assigned in #2065211: Cleanup commons browsing widget views, that seems OK to export (though we should still sort out that issue since enabling different combinations of Commons content type modules will result in differing pager IDs between sites).

-  $handler->display->display_options['pager']['options']['id'] = '0';
+  $handler->display->display_options['pager']['options']['id'] = 1;
   $handler->display->display_options['pager']['options']['quantity'] =

-  $handler->display->display_options['pager']['options']['id'] = '0';
+  $handler->display->display_options['pager']['options']['id'] = 3;

C) If these revisions, while cosmetic, will cause features to appear overridden for upgrading sites, we should consider reverting them.

Comment #16

japerry

KVUO

CreditAttribution: japerry commented 20 September 2013 at 20:47

Status:

Needs work

» Needs review

File	Size
2086905-featureapi2update-16.patch	149.92 KB

okay these should fix those issues. We still need to come back to #2065211: Cleanup commons browsing widget views, but this should answer those concerns in #15

Comment #17

ezra-g CreditAttribution: ezra-g commented 20 September 2013 at 21:23

@japerry: What's your take on 15 C?

Comment #18

japerry

KVUO

CreditAttribution: japerry commented 21 September 2013 at 06:37

ahh nope, they won't need to be reverted. They're currently showing as overridden because features 2.0 is automatically applying the formatting changes. So either they will show as default (if its just formatting changes) or if they were previously overridden, they should show as default now.

Comment #19

japerry

KVUO

CreditAttribution: japerry commented 21 September 2013 at 06:38

Component:	Installer	» Code
Assigned:	japerry	» Unassigned

Unassigning since I'll be out until the 30th.

Comment #20

WebSinPat CreditAttribution: WebSinPat commented 21 September 2013 at 19:06

Status:

Needs review

» Needs work

I applied the patch from #16, and it has had no effect on my overridden features.

my directory structure does not match that in the patch
--> a/modules/commons/commons_activity_streams/

but I applied it in
--> /profiles/commons/modules/contrib/commons_activity_streams

if that seems ok, then I think the patch applied fine.

However, it has no effect on my features. I have cleared cache, run drush fra --force, but I still get 3 or more modules that will not revert, usually with field_instance, flag, and variable.

% drush fra -y
The following modules will be reverted: commons_groups, commons_events, commons_follow_term, commons_like, commons_wikis
, commons_group_privacy
Do you really want to continue? (y/n): y
Do you really want to revert field_instance? (y/n): y
Reverted field_instance.                                                                                     [ok]
Do you really want to revert field_instance? (y/n): y
Reverted field_instance.                                                                                     [ok]
Do you really want to revert flag? (y/n): y
Reverted flag.                                                                                               [ok]
Do you really want to revert variable? (y/n): y
Reverted variable.                                                                                           [ok]
Do you really want to revert field_instance? (y/n): y
Reverted field_instance.                                                                                     [ok]
Do you really want to revert field_instance? (y/n): y
Reverted field_instance.                                                                                     [ok]

i have run the command near a dozen times and features never really get reverted.

Comment #21

WebSinPat CreditAttribution: WebSinPat commented 21 September 2013 at 19:11

Also I would love some clarity on whether this issue is in fact blocking my progress on my upgrade and I should stay in maintenance mode until all features can be successfully reverted, or can i continue with the remaining steps in the upgrade process and bring my site back online while this is getting worked out?

i've been stalled and offline for over a week due to this, and just want to make sure. (it's a dev site, not production, but meanwhile any development is stalled.)

thanks.

Comment #22

ezra-g CreditAttribution: ezra-g commented 23 September 2013 at 18:09

Hi @WebSinPat,

It's difficult to answer your question definitively without being familiar in detail with the customizations on your site, however in general it's likely that these overrides are mostly superficial and that as long as you've properly exported configuration changes to code, you should be OK.

Comment #23

ezra-g CreditAttribution: ezra-g commented 23 September 2013 at 19:11

Assigned:

Unassigned

» ezra-g

Taking this issue on.

2 revisions so far that I can see to #16:

A) Commons Like's variable component is overidden because we removed its definition from commons_like.info. We should restore it.
B) Features shows field_group_logo as missing from group nodes due to removal of this line from the info file in #16, however, this field instance is actually defined dynamically for all group bundles (not only nodes) with commons_groups_field_definition(). Commons_groups.info should define this instance dynamically correspondingly.

Comment #23.0

ezra-g CreditAttribution: ezra-g commented 23 September 2013 at 19:11

Issue summary:

View changes

Including referenced issues in summary.

Comment #24

ezra-g CreditAttribution: ezra-g commented 23 September 2013 at 20:59

File	Size
2086905-featureapi2update-24.patch	144.1 KB

To track the incremental progress here:

Features that appear overridden on a fresh install of Commons 7.x-3.x before any patches:

Commons Polls commons_polls Enabled Overridden
Commons Posts commons_posts Enabled Overridden
Commons Q&A commons_q_a Enabled Overridden
Commons Wikis commons_wikis Enabled Overridden

After #16 (additional features are overridden):

Commons Groups commons_groups Enabled 7.x-3.0 Overridden

Commons Like commons_like Enabled Overridden
Commons Polls commons_polls Enabled Overridden
Commons Posts commons_posts Enabled Overridden
Commons Q&A commons_q_a Enabled Overridden
Commons Wikis commons_wikis Enabled Overridden

With the presently attached patch:

Commons Polls commons_polls Enabled Overridden
Commons Posts commons_posts Enabled Overridden
Commons Q&A commons_q_a Enabled Overridden
Commons Wikis commons_wikis Enabled Overridden

However, the contents of diffs for each feature appear to be reduced to the Views issues from #2065211: Cleanup commons browsing widget views and some additional dependencies. Interestingly, adding the listed new dependency as a features_exclude results in a new and different module being listed as a dependency. I'll turn to that next. I'll likely commit #24 as a progress commit to simplify patches towards this issue.

Comment #25

ezra-g CreditAttribution: ezra-g commented 23 September 2013 at 21:28

File	Size
2086905-featureapi2update-25.patch	144.07 KB

Revised patch from #24 that retains the display of user follow flags on the user entity.

Comment #26

ezra-g CreditAttribution: ezra-g commented 23 September 2013 at 21:40

#25 is committed as a progress commit: http://drupalcode.org/project/commons.git/commit/ac85e20.

Comment #27

ezra-g CreditAttribution: ezra-g commented 24 September 2013 at 18:45

Title:	Multiple features are out-of-date in commons 3.3	» Update Commons Features for cosmetic/syntactic changes
Status:	Needs work	» Fixed

Retitling to reflect the action item here. In reality on a fresh install of Commons 3.3 only the Commons_Q_A feature is overridden and shows only superficial (eg, not effecting functionality) changes from default status.

With the progress commit in comment 26 and #2065211: Cleanup commons browsing widget views, all of the Commons features that are enabled on a fresh install are now in their default states after a fresh install.

Marking as fixed.

Comment #28

japerry

KVUO

CreditAttribution: japerry commented 4 October 2013 at 22:39

Marking a note here about our update to features 2.0-rc4, committed here:

http://drupalcode.org/project/commons.git/commit/dfd1f16

Comment #29

WebSinPat CreditAttribution: WebSinPat commented 4 October 2013 at 23:21

I applied the patch in #16 and it had no effect on my features, so I'd like to try the patch in 25. Can I apply 25 if I've already applied 16?

@ezra-g: "as long as you've properly exported configuration changes to code, you should be OK." um, I"m pretty sure I have not exported anything, as I'm not quite sure what you mean. Can you say a bit more about when and how I should do this?
(I hope it was not something I was supposed to do before upgrading. Before upgrading I did back up my codebase and database, according to the instruction on https://docs.acquia.com/commons/upgrade )