Cleanup commons browsing widget views

I've noticed this and a few other views where AJAX is turned off when it probably should be on. Not sure if a meta issue is needed, but maybe we should keep all of the AJAX view problems in this issue?

It looks like AJAX is only missing for documents but I've noticed a number of inconsistencies between the browsing widget views, so I think a cleanup to standardize all of the view options/properties would be nice.

The attached patch makes the following changes:

• Standardized the view human name, description and tags.
• Enables AJAX for the document view
• Makes the use of the lite pager consistent
• Adds the sticky sort to documents for consistency
• Adds the missing group type filter to documents
• Removes the radioactivity sort from the all view as it is added automatically
• Added translation support for the all view
• Removes the flag content relationship, radioactivity sort and flagged filter from the post view as they are added automatically

It also exposed the root of the current problem with using non-AJAX pagers in combination with the browsing widget #2039637: Pager on the main content stream does not inherit sort order. The BW pager IDs are all very high IDs and aren't unique. I think the best course of action would be to automatically alter all of the BW views to have a small unique ID. This would also help anyone who wants to add a new browsing widget view from accidentally overriding the ID of an existing pager.

I look forward to reviewing. Thanks! Adding to the 3.4 radar.

This looks solid to me. I like the approach of setting a dynamic pager ID for views that appear in the browsing widget.

Once question related to that functionality is whether we should consider implementing hook_module_implements_alter() to ensure that our implementation of hook_view_default_views_alter() runs after other modules have defined their views. My sense is that we can commit what we've got here and in the event that a site needs to alter hook implementation order, we can consider a patch (or a site-specific alteration of implementation order) at that time.

Marked #2085027: String Overrides not changing Nobody has posted into this group yet (b/c t() function is not used in commons_groups.views_defau) as a duplicate.

An updated version of #2 which changes the view tags to sentence case and adds update functions to revert the views.

I agree with #4; there might be a situation in which this implementation of hook_view_default_views_alter() doesn't run last but that could be addressed if someone runs into the issue or on a site-specific basis.

Tested #6 on a fresh and existing Commons install. I didn't come across any issues or errors and all of the update functions were detected and reverted the BW views as designed.

Committed #6 to Commons 7.x-3.x.

http://drupalcode.org/project/commons.git/commit/27f26d0

It seems that on an existing commons install, the pagers will show up as overridden.

Commons groups shows the following (so does q_a):

I'm looking into the overridden features.

Following https://drupal.org/node/2086905#comment-7891595, all features appear to be in their default states if we comment out the dynamic pager implemented in this issue.

If it's not practical to prevent this views alteration from causing features to appear overridden, an alternative would be to reserve a range of specific pager IDs for Commons default content types (eg, content types that ship with Commons could have pager IDs 10-20 or similar).

This patch implements static, non-colliding pager IDs for the BW views as proposed in #10. In my testing, this makes it possible to revert all of the Commons features to their default states.

I verified that features are in their default states with #11 and committed: http://drupalcode.org/project/commons.git/commit/48b02eb . Marking as fixed.

Both Devin and I have seen the views being overridden on RC1 and HEAD for views with pagers.

These features (content types) are affected:

• Commons Polls
• Commons Posts
• Commons Q&A
• Commons Wikis

My commit missed an all-important hunk of this patch:

http://drupalcode.org/project/commons.git/commitdiff/cc72320?hp=1e6b7c7f...

This should now be resolved.