Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Description
Because of the multi line approach too few views are visible at any one time in the table forcing a lot of scrolling.
Currently looks like this:
Proposed solution
Make the displays and machine name ordinary table columns as they are elsewhere.
Removes tag and makes the name of the view link to the view (at the path)
UI changes
Before
After
Comment | File | Size | Author |
---|---|---|---|
#136 | new_views_listing_page-2574767-136.patch | 20.71 KB | Manjit.Singh |
#136 | interdiff.txt | 740 bytes | Manjit.Singh |
#128 | new_views_listing_page-2574767-128.patch | 20.55 KB | Manjit.Singh |
#126 | interdiff.txt | 1.64 KB | Manjit.Singh |
#126 | new_views_listing_page-2574767-126.patch | 20.5 KB | Manjit.Singh |
Comments
Comment #2
tkoleary CreditAttribution: tkoleary commentedComment #3
tkoleary CreditAttribution: tkoleary commentedComment #4
tkoleary CreditAttribution: tkoleary commentedComment #5
tkoleary CreditAttribution: tkoleary commentedComment #6
tkoleary CreditAttribution: tkoleary commentedComment #7
saschaeggiI would love to see that +1
Comment #8
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #9
dawehnerI would love to see something like this!
Comment #10
rszrama CreditAttribution: rszrama at Centarro commentedIt's definitely a hard page to scan, but I do often find myself coming to the Views listing and searching by a known path to find the particular View I want to edit. I'm sure I can get over it if that changes, just wanted to share my use case. : )
Comment #11
dawehner@rszrama
Fair, for simplicity we could move the machine name to its own column and keep the path and maybe drop tag, given how rarely its used.
Comment #12
alphex CreditAttribution: alphex commentedfor #10
if you do the CSS right, you can just hide columns based on display width... (but I use browser 100% width admin themes, so maybe that doesn't fly).
Agreed, "/path/to/view/" is important for helping you realize which view you're wanting to deal with.
Comment #13
rachel_norfolkI like the concept but, looking back at a couple of built sites, a fair few views have multiple paths. If scanning for the paths to know which view to edit is a thing, how would we facilitate that?
Oh - how about a search filter at the top that we could enter a path into that then showed all views that we active on that path or lower?
Comment #14
delta CreditAttribution: delta commentedI use often a ctrl +f search for views path on this listing.. lots of site have poorly named views... Please keep the path on the views listing. However I agreed the long scrolling can be an issue too, but I don't think it worth to remove the path...
#13 yeah to add a javascript search filter.
Comment #15
tkoleary CreditAttribution: tkoleary commented@dawehner
+1 to removing tag. Could we also remove displays? that seems to me not a top level item. Remember, the more items there are on the page the more cognitive load on the user. If we could have only 5 columns that would be great.
Comment #16
dawehnerAgreed totally, so let's replace displays with path basically.
Given how this instant filter works we could still allow to search by displays or tags for example, even they aren't visible on the page.
Comment #17
howdytom CreditAttribution: howdytom as a volunteer commentedGood idea.. Let’s also change the order e.g.
View Name
Path
Description
Machine Name
Tag
Comment #18
yoroy CreditAttribution: yoroy at Roy Scholten commentedA list like in #17 is a good idea but the last couple of comments don't add up :-)
Comment #19
Gábor HojtsyI agree the list on #17 looks good :)
Comment #20
dawehnerI would propose this list to be honest.
Comment #21
tkoleary CreditAttribution: tkoleary commentedWhy do we need machine name? This is a human-readable UI after all. :)
Comment #22
dawehnerFor examples themers uses the machine name to determine the template they want to use, but sure, if people think its not useful for many people ...
Comment #23
DuaelFrAs a developer I also often use the machine name for views alterations. I know I can find it in the URL but it's easier to have it on the list.
Just a thought: why isn't this list a View so anyone could alter it to see what matters for him/her?
Comment #24
dawehnerNo reason beside a year of development in front of us
Comment #25
yoroy CreditAttribution: yoroy at Roy Scholten commentedFair point :)
What about the machine name in a title attribute on the View title?
I think we usually put a description first thing after the title. Interesting to see that path is considered more helpful so far. I'm not against it, just noticing.
Comment #26
dawehner+1 to that idea. Let's just ensure we don't forget the operations, but I doubt anyone disagrees with that.
Comment #27
Bojhan CreditAttribution: Bojhan as a volunteer commented@yoroy We should do the machine name typography then though.
Comment #28
eelkeblokWould it make sense to bundle the path and display columns? Paths are an artefact of page displays, after all. E.g. one View could have as its display column "Block, Feed", another could have "Block, Page (my/fancy/url)" (Edit: I disagree to remove Display, btw. I think it's a very important high level attribute of a View. Also, I've encountered a few sites where View naming is ambiguous and the available Displays are en important clue which View you are actually dealing with.)
Comment #29
yoroy CreditAttribution: yoroy at Roy Scholten commentedNot sure what that means @Bojhan. I don't think you can style title attributes, do you mean specific spelling? Hover this link for an example:
View name
Not ideal for mobile I guess.
Comment #30
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedI agree with #28 and would recommend:
Comment #31
eelkeblokIf we are putting the machine name in a title attribute for the sake of #22/#23, I doubt its usefulness. I'd say that if it's for the purpose of code, you'd want to be able to copy-paste the machine name easily, which I don't think is possible (or at least straightforward/easier than copying the link URL and trimming it) from a title attribute. I don't think it's a UX pattern anywhere else in Drupal, but maybe a little "copy to clipboard" icon would make sense. However, if Display and path are consolidated into one, maybe having a separate machine name column doesn't hurt so much.
Comment #32
DuaelFrWe could also keep the machine name on a second line below the human readable name.
As it's likely that Displays (merged with path) go multilines, it wouldn't hurt to make the name cell on two lines.
[my_view_machine_name]
[this_has_no_relation]
Comment #33
yoroy CreditAttribution: yoroy at Roy Scholten commentedNice mockup! :-) I think I'd prefer that the first column has only 1 line with just the title. Double lines will make this harder to scan/parse for people.
For the listing of displays + path I imagine it will be easier to read if it were an actual list instead of the comma seperated items.
I do wonder wether we're gaining any space with this approach though :) Will we have a more compact listing this way?
Comment #34
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedWell, many of these implementation are failing to address the original issue i.e. too few items...
How about something like the Extend page?
That way we can have just three columns: Name, description & operation with everything else crammed under description.
Comment #35
eelkeblok@yoroy The original is roughly 5-6 lines high. I rarely encounter views that have more than 2-3 Displays, often only one*. So I'd still say that's a net gain. One other possible optimisation is grouping non-path displays together. E.g.:
@dipakmdhrm Too few is a relative term. I think most of the options will result in a gain. If its enough, that's up for discussion, of course. The downside of a setup like the extend page is that it initially hides certain information. I like it, but I think the filtering would need careful consideration as I think that stuff that's hidden will not show in in a "cmd-f" search.
*: That does bring to memory a printout on a wall of shame which had a screenshot for a View with several dozens of displays, though; somebody didn't know about contextual arguments.
Comment #36
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedHow about something like this?
Tag column is now removed.
Displays and path are clubbed together in a single 'displays' column.
Search field can be used to search by name, description, machine name & path while all these also being searchable by "cmd-f" search
Comment #37
dawehnerI really really like it!
Comment #38
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedComment #40
eelkeblokAwesome. Thank you for this.
Comment #41
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedFingers crossed for this one!!
Comment #43
yoroy CreditAttribution: yoroy at Roy Scholten commentedStarting to look much better!
The machine name is shown in a title attribute of the view name *and* in its own column, that seems a bit too much :)
This is what it looks like without that column. I also added a list-style: none to the list of displays:
What do we think?
Comment #44
Gábor HojtsyLooks good to me personally. OTOH issue summary needed screenshot updating, so did that.
Comment #45
eelkeblokI like the list style none, I'm not a fan of the machine name in the title attribute. From my POV, listing the machine name serves two purposes:
Neither of these are served very well with the machine name hidden in a title attribute.
Comment #46
yoroy CreditAttribution: yoroy at Roy Scholten commentedIf as a title attribute is not helpful, do you think we should add it as its own column or leave it out entirely?
Comment #47
eelkeblokMy vote would go to a separate column.
Comment #48
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedIf this patch fails, I'm gonna cuss the nearest person...
FYI... This patch also has the fix for list-styling...
Comment #49
yoroy CreditAttribution: yoroy at Roy Scholten commentedLooks great!
Smaller screen:
Making this table responsive is something to look at in a followup.
I'm fine with keeping the machine name around, we're already winning a lot of space with this approach:
Comment #51
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedComment #53
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedThis additionally contains the modified tests to check for views split listing
Comment #54
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedOk, so there was a test for verifying the presence of escaped strings in the tag information of view. Since we are no longer displaying tags, it has been removed.
In another test, XPath query was updated to accommodate the new HTML structure.
Comment #55
dawehnerJust applied this patch on my local system and its looking really great!
Needs a bit of documentation.
Comment #56
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedAdded the required documentation.
Comment #57
yoroy CreditAttribution: yoroy at Roy Scholten commentedLovely. Thank you @dipakmdhrm. Looks ready to go.
Comment #59
Gábor HojtsyWas random fail with migrate. Added a retest. Moving back to RTBC.
Comment #60
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #61
Gábor HojtsyReviewed this in the UX meeting today. We agreed the title as a header is fine, although it is not like that elsewhere, it gives visual hierarchy. People found two things odd/unusual:
- The label was not called a label (like elsewhere). We already know its views.
- The machine name would look better as not monospaced, would be more consistent (like in field management).
Comment #62
yoroy CreditAttribution: yoroy at Roy Scholten commentedWe could argue that "View name" was already there and so not in scope, but hopefully an easy additional fix.
We also specifically requested the monospaced styling earlier but while reviewing it we concluded it does indeed attract too much attention.
Most importantly: we're all really happy with this design and are eager to get it in :-)
Comment #63
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commented'View name' -> 'Label'
machine_name
-> machine_nameComment #64
Gábor HojtsyLooks good. Using "Label" for the column also makes sense since the filter says "Filter by label, ..." so they match up :) Tested visually and it looks good. Back to RTBC then.
Comment #65
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commented@Gabor: The filter originally said "Filter by view name...". It was changed to match the label thing.. :)
Comment #66
tkoleary CreditAttribution: tkoleary commentedLooks much better to me.
Comment #67
alexpottAssigning to Cottser as the frontend specialist on the committer team.
Comment #68
dawehnerI'm not entirely convinced of the label change:
```/admin/structure/views/add``` still calls it view name, the views edit overview calls it view name, and the editing modal calls it "administrative name". At least none of those examples call it label.
Comment #69
Bojhan CreditAttribution: Bojhan as a volunteer commented@dawhner Is it possible to pick one for all places?
Comment #70
dawehner@Bojhan
Well for now I would just go with 'view name' and think about using "label" in the follow up?
Comment #71
Bojhan CreditAttribution: Bojhan as a volunteer commentedOk lets do it.
Comment #72
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #73
star-szrI am unassigned but here's a first pass at a review. Overall this seems low risk to change markup and such since it's an admin UI but we might break a contrib admin theme or something.
If this object has a toString (which I think it must if we're casting to a string) Twig will just print it so this seems unnecessary but I might be missing something.
There's an extra space before the
:
on both of these lines.It looks like we're linking the opening paren but not the closing one (one's inside the
a
tag and one is outside), is there any reason for this? Seems inconsistent/wrong.There's no space needed before printing attributes. Attributes print their own space, that way we don't have
<table >
(for example) in our markup if there are no attributes to print.This is not actually in the Twig coding standards but I'm fairly sure we should have a space after the comma here. http://twig.sensiolabs.org/doc/tags/for.html#iterating-over-keys-and-values
This line shouldn't be needed, we auto-convert attributes, title_attributes and content_attributes to Attribute objects. #2108771: Remove special cased title_attributes and content_attributes for Attribute creation.
This should stay the same in Stable.
Stable templates shouldn't have @ingroup themeable.
Comment #74
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedComment #76
star-szr@dipakmdhrm an interdiff and some words, for example: "Addresses #70 and #73" would be great :) thanks.
Comment #77
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedAddresses #70, #73 & failure in #74.
Also contains additional documentation, changes to comply with coding standard and some common-sense changes that should've been there in earlier patches.
@Cottser:
For additional reference, patch has one of the test removed from
views_ui/src/Tests/XssTest.php
.This test was to check for presence of Tags on the view list page, which we're not displaying anymore.
Comment #78
yoroy CreditAttribution: yoroy at Roy Scholten commentedThank you for the quick update @dipakmdhrm
Comment #79
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #80
star-szrSorry for the delayed review. Overall looks very good, I have one concern and a couple nitpicks.
This seems problematic, it's an API change. Anyone overriding this template (even just copying into their admin theme for example) will end up with a very broken Views UI following this change because their views-ui-view-info.html.twig will still be expecting the old variables. Can we keep views_ui_view_info as is and make a new theme hook to suit this purpose instead? I also think we can come up with a name better than views-ui-view-info considering what it's doing now :)
Minor: Needs spaces inside the curly braces per http://twig.sensiolabs.org/doc/coding_standards.html - in both templates.
Minor: double period.
Comment #81
star-szrOh also this is missing a trailing comma now per https://www.drupal.org/coding-standards#array.
Comment #82
imalabya@cottser: for point 1 in #80 the twig file (`views-ui-view-info.html.twig`) has all the new variables declared in the new theme_hook. I doubt that the views ui will break if the template is overridden.
I even tested that out to check if that breaks, but things are pretty much in place.
Am I missing something in understanding the concern?
Also, fixed all the point asked in #80 as well as #81
Comment #83
imalabyaOk, so the concern was the view UI might break if a contrib admin theme already has the views-ui-view-info.html.twig with old variables. My bad. Sorry for the confusion.
Comment #84
imalabyaComment #85
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commented@Cottser:
You made a very valid point of changing the theme file name from
views_ui_view_info
to something new (I am going withviews_ui_view_listing_table
) so that their existing copy ofviews_ui_view_info.html.twig
( from their admin theme and expecting older variables ) doesn't try to override our new implementation and thus doesn't brake anything.However, I don't get why should we need to "keep views_ui_view_info as is".
In my next patch I'll be changing the theme file name & removing the
views_ui_view_info
unless there is a reason we should keep it.??Comment #86
imalabya@dipakmdhrm:
IMO keeping the "views_ui_view_info as is" because if any contributed admin theme is currently using the views_ui_view_info twig file then the Views listing page will be broken because it will be looking for the previous Variables. So we should keep it there as in. So, in this case the views listing will look like the changes made in this issue but the contributed theme will have the older listing view, which is kind of an issue by itself.
But again, if we have to have a new theme file for the listing
views_ui_view_listing_table
then the existingviews_ui_view_info
will become obsolete. If we removeviews_ui_view_info
then also it makes the same scenario.Comment #87
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commented@malavya:
Had we made the UI changes that are needed here in the same template (
views_ui_view_info
), views listing page would break as the overriden template file in someone's admin theme, or thetemplate_preprocess_views_ui_view_info
would be expecting older variables.Now that we are changing the template from
views_ui_view_info
toviews_ui_views_listing_table
, broken view listing page shouldn't be a problem as thetemplate_preprocess_views_ui_view_info
wouldn't be invoked and the overridingviews-ui-view-info.html.twig
wouldn't be used.And thus I believe we don't need to keep views_ui_view_info as is.
Comment #88
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedAddresses #80 & #81
Additionally,
views_ui_view_info_display
template is now renamed toviews_ui_view_displays_list
.Comment #89
star-szrThe reason to keep the 'views_ui_view_info' theme hook is that any module can currently use that to output some data so it's API at this point and we can't just blindly remove it. All that's needed to exercise that functionality is a render array like this:
It's unlikely to happen but I don't want to make assumptions like that, it's not safe.
A couple nitpicks:
Minor: Missing trailing comma on the attributes line.
Minor: Extra blank line here below template_preprocess_views_ui_views_listing_table().
Comment #90
yoroy CreditAttribution: yoroy at Roy Scholten commentedWho can do these final changes please? It's such a nice design update, I'd love to see this committed :-)
Comment #91
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedComment #92
Dom. CreditAttribution: Dom. as a volunteer and at ACINO commentedJust simple patch: fixed the two nitpicks from @cottser.
Comment #93
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commented@Dom.'s fix doesn't bring back the
views_ui_view_info
theme hookComment #94
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commented@Cottser:
Should I just bring back the
views_ui_view_info
theme hook or do we need theviews-ui-view-info.html.twig
files as well (views_ui
module &stable
theme).??Comment #95
fgmI might be atypical in this, but I'll miss the tag field, which I've long been using to group views by site concern.
Comment #96
dawehner@fgm
Would it be enough for you to have this just searchable but not being exposed in the UI?
Comment #97
tkoleary CreditAttribution: tkoleary commented@fgm
Comment #98
tkoleary CreditAttribution: tkoleary commented@fgm
You could always write a module that makes a view of all views and configure it how you like. :)
Comment #99
star-szr@dipakmdhrm you need to keep the template files as well otherwise it's still a BC break at least in my opinion.
Comment #100
fgmAs @tkoleary mentions, my personal wishes don't have any reason to weigh much, but there's a more general perspective to this : filtering by tags provides a navigational UI, allowing point and click selection, whereas search requires actual data input. UX-wise, requiring more typing is probably a net loss.
Comment #101
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedAddresses #89.
Comment #102
dawehnerSo we keep the templates files etc. around while not using them anymore? This still feels a bit like a BC break, but if @Cottser is happy with that, I'm happy :)
Comment #104
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #106
yoroy CreditAttribution: yoroy at Roy Scholten commentedOnly 1 fail left to fix! Lets get this in for the 8.2 release :-)
Comment #107
Gábor HojtsyLooks like the problem is Stable has a views-ui-view-info.html-stable.twig which should be views-ui-view-info.html.twig, the test fail asserts that Stable overrides all the templates, and this way with views-ui-view-info.html-stable.twig it does not :) Easy fix? :) @dipakmdhrm can you take a look?
Comment #108
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedAddresses #107.
And the test failure above is probably what @Cottser meant when he said that twig files should also be kept if we are keeping the theme hook. Test would have failed if we had removed the twig file.
Comment #109
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedComment #110
Gábor HojtsyYay, thanks! That indeed fixes the fail, and I think all concerns so far have been answered. Assigning to Cottser for committer review, hopefully commit :)
Comment #111
star-szrI very likely won't have time to give this another thorough review in the near future but my big concerns were addressed so unassigning, this could be looked at by another committer as well. Thanks all :)
Comment #112
dawehnerI just want to remind people that this is not a user facing template change or anything which would break functionality for users. Its simply a change in the admin UI and help everyone to potentially feel less overwhelmed.
Comment #113
xjmEvery time we add a column to an admin listing, we should test mobile.
Here's this view on my iPhone, before and after the patch.
Before
After
So the patch actually improves that too. Nice.
It would be good to have a followup to make this table actually responsive (i.e. set some priorities on the columns). Not in scope here, though, because the problem also exists in HEAD.
I haven't reviewed the patch in depth yet; just wanted to document the mobile testing. :)
Comment #114
xjmAnd on not-mobile.
Before
After
Comment #115
xjmComment #116
xjmComment #117
xjmSome more feedback, some of which is actionable. Point 1 particularly.
What about RTL?
These numbers reassuringly add up to 100.
At first I was like "Whoa wait why are we removing this coverage?" but this was coverage for the view tag, which we are no longer displaying at all. That's fair enough. Are view tags used anywhere at all in the core UI now?
Minor: Missing serial comma.
The "machine name" is also now its own column in the new UI, which is also more semantic, and that is why this is changed.
Ditto re: serial comma.
So we are removing this method entirely?
It's protected, so that should be okay. CR? (Edit: for the whole change, not just this, but it could mention this.)
Thanks everyone!
Comment #118
xjmBTW I also tested the new filtering on four different fields, and it works really nicely.
Comment #119
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commented@xjm: About #117:
Is #2 a suggestion for change or just a comment?
And, Did not get #7. What's a CR?
Comment #120
fgm@dipakmdhrm: a Change Record. This is how we document changes to the API. They are listed at https://www.drupal.org/list-changes/drupal for core.
Comment #122
Gábor HojtsyAdded a site builder change notice draft at https://www.drupal.org/node/2781591. Not sure what to do about a coder change notice. Should it list the new templates, or?
Comment #123
Manjit.SinghComment #124
Gábor HojtsyAdded a themer/developer change record too at https://www.drupal.org/node/2782031. Still needs work for the rest of @xjm's feedback.
Comment #125
Gábor HojtsyFollowup submitted at #2782047: Listing of views is not a responsive table marked as related to this one. I think all is left are issues with the patch and @Manjit is working on that I believe.
Comment #126
Manjit.SinghHere are the changes as per #117.
Comment #127
Gábor HojtsyThanks, only found this:
You also need to undo the left margin and padding from RTL making it auto or the value it overrode.
Comment #128
Manjit.SinghComment #129
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #130
dawehner@Manjit.Singh
Ensure to include interdiffs in the future.
So we basically skip the existing template. I think its not a big problem, but still from a pure BC policy one could argue that its a problem,
but cotter in #2574767-111: Views listing page displays too few items on a page agreed with the proposal.
Comment #131
Gábor HojtsyYeah we need to keep the template for backwards compatibility but we don't need to use it anymore.
Let's get this in then! :)
Comment #132
Gábor HojtsyAttempting to assign to Cottser again.
Comment #133
star-szr@dawehner regarding #130:
We can change render arrays per https://www.drupal.org/core/d8-allowed-changes#minor.
This is on my list to review. Thanks all.
Comment #134
star-szrThis is looking very good, there's only one problem I can see: The Stable version of views_ui.admin.theme.css is missing the most recent RTL CSS changes from #128. We could have seen that easily with an interdiff, so they really are helpful!
Back to needs work for that touch-up.
Comment #135
Manjit.SinghComment #136
Manjit.Singhhere we go. I have made the suggested changes, Please review.
Comment #137
Gábor HojtsyYay thanks, looks like it is just the same change applied to stable as requested by @Cottser, so should be back to RTBC.
Comment #139
star-szrExcellent, thanks @Manjit.Singh and @Gábor Hojtsy.
Committed 3f8aa20 and pushed to 8.3.x. Thanks!
Comment #140
dawehnerNice, great work everyone!
Comment #141
yoroy CreditAttribution: yoroy at Roy Scholten commentedAh great, thanks everyone for seeing this through!
Comment #142
tkoleary CreditAttribution: tkoleary commented+1 great work
Comment #143
Manjit.Singhwoot :) Chak de
Comment #144
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer commentedGlad to see this committed to core!! Yay!
Great work everyone!
Comment #146
Gábor HojtsyComment #147
quietone CreditAttribution: quietone at PreviousNext commentedpublish change records
Comment #148
fgm