[META] Convert listings to Views

[quicksketch]

We should convert the core listings into views. Converting the following lists to views requires:

1. Click together an identical view in Backdrop.
2. Add it's config file to the appropriate module.
3. Provide an upgrade path for those D7 sites that were using the non-view alternative.

Conversions

Pages:

• [DX] Convert /node to a View #162 | Convert /node to a view (converted to a layout + a default view)
• Convert the taxonomy listing and feed at /taxonomy/term/%term to Views #145 | Convert /taxonomy/term/% to a view
• Remove the page for RSS settings #669 | Remove the settings for RSS

Blocks:

• [D8] Convert "Recent content" block to a View  #146 | Convert "Recent content" block to a View in comment module
• Convert "Recent comments" block to a view #330 | Convert "Recent comments" block to a View in comment module
• Remove "Who's new" block from core #147 | Remove "Who's new" block from user module
• Remove "Who's online" block from core. #148 | Remove "Who's online" block from user module

Administrative pages:

• Replace admin/people with a View #149 | Convert admin/people with a View in user module
• Convert admin/content to a View #150 | Convert admin/content to a View in node module
• Convert admin/content/comment to a View #549 | Convert admin/content/comments to a View in comment module
• Convert /admin/content/book to a View #3735 | Convert admin/content/book to a View in book module

Other things:

• Remove views-more.tpl.php (use theme_more_link instead) #547 | Remove views-more.tpl.php (use theme_more_link instead)

Upgrade paths

Providing an upgrade path is not necessarily a novice task, but the code examples below should get you close. Please note, the code below has not been tested and is here for reference purposes only :)

1. Write an update hook for the appropriate module in it's .install file.

2. Assemble the data needed for the view.

• read in the values of the config file for the view
• json_decode so you get a PHP array
• var dump the contents of the PHP array
• copy/paste this array and hard code it as $data.

// Remove below this line after the array is generated.
$file = file_get_contents('path/to/views.view.whatever.json');
$view = json_decode($file);
print backdrop_var_export($view);
// Remove above this line after the array is generated.
$data = array(
  'hardcoded' => 'stuff goes here',
);

3. Check the associated variable settings for the view (if there are any)

• if there aren't any, or if they aren't set, do nothing.
• if they are set, update the appropriate parts of the $data array.
• if the display is a block, also check if the block was in use. If so, make sure the enabled part of $data is set to TRUE.

4. Save the view to config.

// Save the view as config.
$config = config('views.view.'. $machine_name);
$config->setData($data);
$config->save();

5. delete associated variables, if any exist.

update_variable_del('whatever');

Related

Relevant issues needed for some conversions:

• Add a dropbutton field handler to Views #143 | Dropbutton Handler
• Implement "Simple" Views Bulk Operations (VBO) #142 | Implement "Simple" Views Bulk Operations (VBO)

Relevant Drupal.org issue: [Meta] Convert core listings to Views

[ghost]

In creating all these default views for entities in Backdrop, should we decide on a standard naming system for both the administrative view name and the machine name? Also, should these all be separate views, or should views for the same entity types be combined? E.g. make the "Who's new" block a block display on the 'admin/people' view (which would be a page display)...

[quicksketch]

Should we decide on a standard naming system for both the administrative view name and the machine name?

If we're shooting for consistency, perhaps we try [module_name]_[block_delta] for blocks and [module_name]_[admin_path] for paths? That might end up with long, awkward view names for admin paths like user_admin_people, where I might prefer user_admin_listing or even just user_admin. I'd say let's just start with prefixing the views by the module that ships them, then go from there.

As for displays vs. separate views, these should definitely be separate views. Displays within a single view can be difficult to locate, especially if there are multiple page or block displays on the same view. The overall admin-listing isn't capable of displaying multiple paths at the same time, so finding the right view is hindered when they are combined. In addition, the "overridden" vs. "default" experience is still really difficult for new and experienced users alike, which we should avoid in our out-of-box views.

[tarekdj]

@quicksketch it's better to use var_export($view); the output is cleaner than var_dump().

[tarekdj]

@quicksketch I think it's update_variable_del() not variable_del() ?

[quicksketch]

@quicksketch it's better to use var_export($view); the output is cleaner than var_dump().

Thanks! And actually we should use backdrop_var_export, as that will format the export according to our own coding standards. Updated the docs.

@quicksketch I think it's update_variable_del() not variable_del() ?

Also correct. Updated.

[quicksketch]

Marked #1101 duplicate of this one.

[klonos]

The fact that the "Who's new" and "Who's online" blocks are missing has been brought up on Gitter today. Perhaps we should consider shipping core with a view that includes those 2 blocks?