At the user "Scheduled" tab, if you view another user profile and go to their "Scheduled" page the empty results of scheduler_list display message "There are no scheduled nodes for @username." using current user name instead of the user that correspond to the viewed page. The query that builds the scheduled list is correctly using the appropriate user that is retrieved from argument from user menu. This user should also be used for the message.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 2771613-9.no_results_text_for_scheduled_content_view.patch | 1.29 KB | jonathan1055 |
| #6 | 2692435-6.fix_incorrect_user_at_empty_scheduler_nodes_message.7x.patch | 1.46 KB | jonathan1055 |
Comments
Comment #2
citlacom commentedIn order to display the correct username we need to use the user from menu arguments not the global user that not neccesarily correspond to the viewed scheduler user items list.
Heres is the patch generated based on 7.x-1.4 version.
Comment #3
jonathan1055 commentedHi citlacom,
You are right. I don't know how I missed that. Thanks for the patch - setting to 'needs review' so that the automated tests are run, but this functionality is not actually covered by any tests.
In 8.x the view is created differently and we just get a plain 'No scheduled content available' message. That could be confusing - it would be nicer to show the users name. I will take a quick look at the 8.x code to see if it is simple to fix. Either way, this will definitely be committed at 7.x
Jonathan
Comment #4
jonathan1055 commentedI have been trying to do this in 8.x and it's been very unproductive so far. In 'No results behavior' the Replacement Tokens from the context filter are:
But these only give the user id, not the name. In 'Global Tokens' we only get site: and view fields. There is no php input filter in D8, this has been removed in favour of theming via twig replacement. I can't find out how to load the user entity to get the name, and I can't find out how to create a custom token to make it available directly.
I don't know if this is my lack of knowledge of D8 or whether it really is a regression of functionality that was available in D7. Any ideas?
Comment #5
jonathan1055 commentedI find it hard to believe that when using a view on a users profile page, the user's name is not readily available for use in the view, for example in the title or header, not relying on getting the user data via returned rows. But I have not found a way to get it yet. I did see that you can specify a separate view to be used in the 'no results' section, so I created a user view (i.e. based on the user table) which returns the user data, and that works fine. But it does seem like a very loong way round just to get the users name.
I will keep investigating. It must be easier than that.
Or we could just ignore the proper fix for 8.x, and change it to something like 'No scheduled content by this user' and fix 7.x as in the patch in #2, which is a trivial change.
Comment #6
jonathan1055 commentedNot giving up on the 8.x fix yet, but here is a modified patch for 7.x. The
user_load($args[1])has to be done only when there is a user id in the arguments, otherwise an error is produced. Simple to move that line. I also took the opportunity to document the parameters of the function being changed.Comment #8
jonathan1055 commentedI still intend to find a way to get the user name in the 8.x view, but this should not delay the 7.x fix. It will be no further loss of functionality if the 8.x version cannot be fixed, as it is currently not showing the user name at all.
Hence committed to 7.x, so that this fix can be in the upcoming 1.5 release. Thanks @citlacom for noticing this and providing the initial patch.
Comment #9
jonathan1055 commentedAt 8.x if the user name cannot be retrieved then it is better to say 'No scheduled content for user x' rather than 'No scheduled content availbale'. Can still change this in future if anyone finds a way, but better to make progress and move on.
Comment #11
jonathan1055 commentedCommitted at 8.x
Already fixed for 7.x so setting this issue to 'Fixed'.
Comment #12
jonathan1055 commentedFixed typos in original summary.