Convert "Who's new" block to a View

Working on it.

Working on it, because fgm have other things to do.

I create a new view

views.view.who_s_new

Fields:

• User: Name

selected filter:

• User is active: yes
• last user access: > 1970-01-01

sort criteria:

• User Created: Desc

Also delete old block:
UserNewBlock.php

We can now override the items per page, let's get this issue up to speed again.

I just noticed this. There should not be any permission checks in the view, because there are no permission checks in the original block settings.

I consider this as a bug in the first place. Let's reroll the patch and see what happens.

Let's also login a user to show first access.

Here is the reroll. I tested the patch it worked fine. I don't know perhaps a usablity review will help. It is ready to fly just one point.

+++ b/core/modules/user/config/views.view.who_s_new.yml
@@ -0,0 +1,165 @@
+          operator: '>'
...
+            value: '1970-01-01'

+++ /dev/null
@@ -1,84 +0,0 @@
-    $uids = db_query_range('SELECT uid FROM {users} WHERE status <> 0 AND access <> 0 ORDER BY created DESC', 0, $this->configuration['whois_new_count'])->fetchCol();

access > 1970-01-01 and access <> 0

old query is
SELECT uid FROM {users} WHERE status <> 0 AND access <> 0 ORDER BY created DESC LIMIT 0, 5
new query is

SELECT users.name AS users_name, users.uid AS uid, users.created AS users_created
FROM 
{users} users
WHERE (( (users.status <> '0') AND (users.access > -18000) ))
ORDER BY users_created DESC
LIMIT 5 OFFSET 0

No screenshot to review?

Add tag, but well, there should not be a huge change.

Please also share the screenshot of block configuration page.

Block config page.
img

I have added block category.(Maybe a followup)

And It shows up like this

I just wanted to show it under both categories maybe we can add this feature or we should mention it in field description only on category is allowed. My point is autocomplete made me think it is multi value field.

Here is another issue. (escaping much)

NW for changing block category from views to user.

Assigning to me to try and tackle this as part of the DrupalCon Prague Code Sprint.

New patch, only change against #17 is the added block category (User):

Sorry, wrong patch was attached to #22, this should be the correct one. The interdiff in #22 is correct (diff #17 vs this patch).

Created #2100959: Views secondary action links escapes html twice for escaping issue mentioned in #19.

This does not seem to be a highly critical feature, see http://www.w3.org/TR/wai-aria/roles#complementary though I guess on the longrun we need to add this to either the block UI or just to
the views UI so people can configure it, if needed.

Patch still applies.

Let's mark this as RTBC and wait on the feedback of jbeach.

dawehner brought up in chat a problematic bit of code in the user module:

/**
 * Implements hook_preprocess_HOOK() for block templates.
 */
function user_preprocess_block(&$variables) {
  if ($variables['configuration']['module'] == 'user') {
    switch ($variables['elements']['#plugin_id']) {
      case 'user_login_block':
        $variables['attributes']['role'] = 'form';
        break;
      case 'user_new_block':
        $variables['attributes']['role'] = 'complementary';
        break;
      case 'user_online_block':
        $variables['attributes']['role'] = 'complementary';
        break;
    }
  }
}

So this brings up two issues.

In these three cases, the roles are inappropriate. The complementary role is meant for content that is related to the main content. Blocks displaying data about users have, most likely, nothing to do with the content on the page. And the form role on the log in block should really be on the form element, not that block wrapper. Not having an aria form role on a form element is not terrible.

So, in the interest of getting this issue unblocked, I'm fine with removing this preprocess function and the roles it adds to various user blocks.

I would like to see a way for us to add attributes, and thus role attributes and other aria-* attribtues, to views wrappers so we can mark up content appropriately for accessibility through the GUI. I'll add that issue and link it here.

Created #2135341: Views should provide a means to add arbitrary attributes (such as aria-* attributes) to a view's wrapping element.

28: vdc-2020395.patch queued for re-testing.

I just did a big honkin' review of the sister issue at #2020399-54: Convert "Who's online" block to a View. There's a chance much of it applies here. We'll know in a few minutes! :)

Oops. No we won't. #26 no longer applies, and #28 is a 0 byte patch.

Tagging as an alpha target. Now that #1957276: Let users set the block instance title for Views blocks in the Block UI is in, I think we just need a re-roll and then this one is good to go.

Re-roll

Thank you for providing the most recent version of the patch.
Let's fix the failure.

Back to RTBC.

Thanks!

Committed and pushed to 8.x, apart from the category change, per UX guidelines.

Reverted d2478e9 and pushed to 8.x.

Drupal\views\Tests\DefaultViewsTest and Drupal\comment\Tests\Views\DefaultViewRecentComments

Seems like another patch was committed in the same commit - see http://drupalcode.org/project/drupal.git/commit/f7e75db

38: vdc-2020395.patch queued for re-testing.

38: vdc-2020395.patch queued for re-testing.

Reuploading the last patch.

Back to RTBC again.

No longer applies :(

Mh, I should have retested.

Reupload.

Back to RTBC

Great work!

Committed and pushed to 8.x. Thanks!