Allow a custom HTML element to be selected for a grouping field [#1383696] | Drupal.org
Skip to search
Can we use first and third party cookies and web beacons to
understand our audience, and to tailor promotions you see
Allow a custom HTML element to be selected for a grouping field
Needs work
Project:
Drupal core
Version:
main
Component:
views_ui.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Needs manual testing
wcag131
Needs subsystem maintainer review
Portland2024
about tags
It affects the ability of
people with disabilities or special needs
(such as blindness or color-blindness) to use Drupal.
Needs manual testing
The change/bugfix cannot be fully demonstrated by
automated testing
, and thus requires manual testing in a variety of environments.
Needs subsystem maintainer review
It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see
the governance policy draft
for more information). Also, if you use this tag,
make sure the issue component is set to the correct subsystem
If an issue significantly impacts more than one subsystem, use
needs framework manager review
instead.
Reporter:
Reg
Created:
24 Dec 2011 at 11:53 UTC
Updated:
7 Apr 2026 at 19:38 UTC
Jump to comment:
Most recent
Most recent file
Problem/Motivation
As you can see from below the H3 tag which is generated from using grouping (@ Format: Unformatted list | Settings:Grouping field) has no divs around it like the regular fields. In my case I would like to wrap some HTML around it but I can't see where. On the fields it's easy, just override the output with what you want but on this generated group title I haven't found how to do this so any help will be much appreciated.
Internet Department
Steps to reproduce
Create a view, either list or table format
Choose Settings on format
Choose a grouping field to create a grouped display
The output sets the grouping label at a static
, which can cause heading structure inaccessibility by outputting grouping as incorrect heading levels. This creates possible WCAG violations with no way to remedy as a site builder.
Proposed resolution
Expose a grouping label tag for each grouping field where the user can specify a wrapping label element by which to group the records via the Views UI.
Remaining tasks
Contributor tasks needed
Task
Novice task?
Contributor instructions
Complete?
Create a merge request
Yes
Merge request instructions
Yes, see
gerardc/1383696-c
Get feedback on which tests should be created or modified (or grab tests from
related issue
No
Instructions
Yes
Write change record for the API changes
Yes
Change record Instructions
Yes
Manually test the patch or merge request
Novice
Patch test Instructions
No
Add steps to reproduce the issue
Novice
Instructions
Yes
User interface changes
Adding a grouping label tag to the style options dialog allows for adjusting the tag per grouping field
API changes
A new grouping label tag element is being added to the existing view templates where a static
was used to wrap a grouping label.
{% if title %}
{% if grouping_label_element is empty %}
{{ title }}
{% else %}
<{{ grouping_label_element }}>{{ title }}
{% endif %}
{% endif %}
This code is added to the following files:
views-view-grouping.html.twig
views-view-grid-responsive.html.twig
views-view-grid.html.twig
views-view-list.html.twig
views-view-unformatted.html.twig
The
{{ grouping_label_element }}
value comes from StylePluginBase.php, which adds a new grouping_label_element array key in the form grouping array and applies if
usesGroupingLabelElement = true
. The following PHP style templates have that value set to TRUE:
DefaultStyle.php
Grid.php
GridResponsive.php
HtmlList.php
By default the value of this key is an
element, which should prevent breakage of views that don't override the template.
Data model changes
No changes affecting the data model.
Release notes snippet
To be determined.
Comment
File
Size
Author
#110
1383696-nr-bot.txt
8.03 KB
needs-review-queue-bot
#81
1383696-81.patch
20.3 KB
carlygerard
#80
1383696-80.patch
19.52 KB
carlygerard
#57
MicrosoftTeams-image.png
125.35 KB
carlygerard
Issue fork
drupal-1383696
Show commands
Start within a Git clone of the project using the
version control instructions
Add & fetch this issue fork’s repository
Or,
if you do not have
SSH keys set up on git.drupalcode.org
Add & fetch this issue fork’s repository
drupal-1383696-82-11.x
plain diff
MR
!15366
Check out this branch for the first time
Check out existing branch, if you already have it locally
drupal-1383696-82
changes
plain diff
MR
!7351
Check out this branch for the first time
Check out existing branch, if you already have it locally
6 hidden branches
drupal-1383696-drupal-1383696-82
compare
Check out this branch for the first time
Check out existing branch, if you already have it locally
gerardc/1383696-c
changes
plain diff
MR
!2922
changes
plain diff
MR
!2927
Check out this branch for the first time
Check out existing branch, if you already have it locally
gerardc/1383696-9.5.x
changes
plain diff
MR
!2921
Check out this branch for the first time
Check out existing branch, if you already have it locally
packern/view-grouping-header
changes
plain diff
MR
!2711
Check out this branch for the first time
Check out existing branch, if you already have it locally
gerardc/1383696
compare
Check out this branch for the first time
Check out existing branch, if you already have it locally
1383696-how-to-change
compare
Check out this branch for the first time
Check out existing branch, if you already have it locally
About issue forks
Comments
Comment
#1
Reg
commented
24 December 2011 at 12:13
It looks like it's a matter of overriding the views template views-view-unformatted.tpl.php . Is there another way or is this it?
or
to post comments
Comment
#2
dawehner
German
commented
24 December 2011 at 12:15
Status:
Active
» Fixed
Even overriding a tpl doesn't help as this is not themable at the moment.
There is an issue
#477338: Multiple group: group by more than one field
which would allow you to theme that.
or
to post comments
Comment
#3
Reg
commented
24 December 2011 at 20:01
Status:
Fixed
» Active
Thanks for that, I think that issue is a little more complex than my needs however now seeing that it's an issue even for one group I'm thinking a little more creatively.
Have you ever considered using a view within a view as a solution? Perhaps it will put a wrapper around the inner view so we have some way of distinguishing what's group from a major heading. If so, in theory you can have an unlimited number of views in views so that may solve the issue of groups within groups as well.
or
to post comments
Comment
#4
dawehner
German
commented
24 December 2011 at 23:43
Status:
Active
» Fixed
Well you could try to use the views_field_view module, but it's probably kind of hard to get the groupby working with it.
or
to post comments
Comment
#5
Reg
commented
25 December 2011 at 00:23
If you do it correctly you won't need group by. In the parent view you make a simple list by what you would normally use as a group by and pass the value as an argument to the child view. Use the passed parameter to limit the results in the child view and you are mimicking a one to many relationship in the database. You should be able to do this to as many levels as you like barring any limitations in the module.
or
to post comments
Comment
#6
8 January 2012 at 00:51
Status:
Fixed
» Closed (fixed)
Automatically closed -- issue fixed for 2 weeks with no activity.
or
to post comments
Comment
#7
stephen Piscura
commented
9 February 2012 at 19:24
Status:
Closed (fixed)
» Active
Reg,
I'm dancing around with views grouping fields with strange results. I have a users view that creates a "staff" page with these fields:
Username
Image (image field on user entity)
Bio (long text field on user entity)
Title (authored-by-user relationship: title of node)
Subtitle (authored-by-user relationship: text field on node)
If i choose to group by username, the grouping gets surrounded by an H3. I then exclude this field from display so that it doesn't display in both the grouping
and
interior fields. But if i follow the same logic by adding the bio field as a second grouping field, then it gets the H3 and the username becomes a simple div. Obviously wrapping a long text field in a H3 is not what i want to do. What i ultimately want is something like this:
Username
![]()
image of user
was used to wrap a grouping label.
{% if title %}
{% if grouping_label_element is empty %}
{{ title }}
{% else %}
<{{ grouping_label_element }}>{{ title }}
{% endif %}
{% endif %}
This code is added to the following files:
views-view-grouping.html.twig
views-view-grid-responsive.html.twig
views-view-grid.html.twig
views-view-list.html.twig
views-view-unformatted.html.twig
The
{{ grouping_label_element }}
value comes from StylePluginBase.php, which adds a new grouping_label_element array key in the form grouping array and applies if
usesGroupingLabelElement = true
. The following PHP style templates have that value set to TRUE:
DefaultStyle.php
Grid.php
GridResponsive.php
HtmlList.php
By default the value of this key is an
element, which should prevent breakage of views that don't override the template.
Data model changes
No changes affecting the data model.
Release notes snippet
To be determined.
Comment
File
Size
Author
#110
1383696-nr-bot.txt
8.03 KB
needs-review-queue-bot
#81
1383696-81.patch
20.3 KB
carlygerard
#80
1383696-80.patch
19.52 KB
carlygerard
#57
MicrosoftTeams-image.png
125.35 KB
carlygerard
Issue fork
drupal-1383696
Show commands
Start within a Git clone of the project using the
version control instructions
Add & fetch this issue fork’s repository
Or,
if you do not have
SSH keys set up on git.drupalcode.org
Add & fetch this issue fork’s repository
drupal-1383696-82-11.x
plain diff
MR
!15366
Check out this branch for the first time
Check out existing branch, if you already have it locally
drupal-1383696-82
changes
plain diff
MR
!7351
Check out this branch for the first time
Check out existing branch, if you already have it locally
6 hidden branches
drupal-1383696-drupal-1383696-82
compare
Check out this branch for the first time
Check out existing branch, if you already have it locally
gerardc/1383696-c
changes
plain diff
MR
!2922
changes
plain diff
MR
!2927
Check out this branch for the first time
Check out existing branch, if you already have it locally
gerardc/1383696-9.5.x
changes
plain diff
MR
!2921
Check out this branch for the first time
Check out existing branch, if you already have it locally
packern/view-grouping-header
changes
plain diff
MR
!2711
Check out this branch for the first time
Check out existing branch, if you already have it locally
gerardc/1383696
compare
Check out this branch for the first time
Check out existing branch, if you already have it locally
1383696-how-to-change
compare
Check out this branch for the first time
Check out existing branch, if you already have it locally
About issue forks
Comments
Comment
#1
Reg
commented
24 December 2011 at 12:13
It looks like it's a matter of overriding the views template views-view-unformatted.tpl.php . Is there another way or is this it?
or
to post comments
Comment
#2
dawehner
German
commented
24 December 2011 at 12:15
Status:
Active
» Fixed
Even overriding a tpl doesn't help as this is not themable at the moment.
There is an issue
#477338: Multiple group: group by more than one field
which would allow you to theme that.
or
to post comments
Comment
#3
Reg
commented
24 December 2011 at 20:01
Status:
Fixed
» Active
Thanks for that, I think that issue is a little more complex than my needs however now seeing that it's an issue even for one group I'm thinking a little more creatively.
Have you ever considered using a view within a view as a solution? Perhaps it will put a wrapper around the inner view so we have some way of distinguishing what's group from a major heading. If so, in theory you can have an unlimited number of views in views so that may solve the issue of groups within groups as well.
or
to post comments
Comment
#4
dawehner
German
commented
24 December 2011 at 23:43
Status:
Active
» Fixed
Well you could try to use the views_field_view module, but it's probably kind of hard to get the groupby working with it.
or
to post comments
Comment
#5
Reg
commented
25 December 2011 at 00:23
If you do it correctly you won't need group by. In the parent view you make a simple list by what you would normally use as a group by and pass the value as an argument to the child view. Use the passed parameter to limit the results in the child view and you are mimicking a one to many relationship in the database. You should be able to do this to as many levels as you like barring any limitations in the module.
or
to post comments
Comment
#6
8 January 2012 at 00:51
Status:
Fixed
» Closed (fixed)
Automatically closed -- issue fixed for 2 weeks with no activity.
or
to post comments
Comment
#7
stephen Piscura
commented
9 February 2012 at 19:24
Status:
Closed (fixed)
» Active
Reg,
I'm dancing around with views grouping fields with strange results. I have a users view that creates a "staff" page with these fields:
Username
Image (image field on user entity)
Bio (long text field on user entity)
Title (authored-by-user relationship: title of node)
Subtitle (authored-by-user relationship: text field on node)
If i choose to group by username, the grouping gets surrounded by an H3. I then exclude this field from display so that it doesn't display in both the grouping
and
interior fields. But if i follow the same logic by adding the bio field as a second grouping field, then it gets the H3 and the username becomes a simple div. Obviously wrapping a long text field in a H3 is not what i want to do. What i ultimately want is something like this:
Username
![]()
image of user
user bio
posts by user
title
subtitle
I don't know how to build the kind of views parent/child relationship using contextual filters which you've described. Can you help me and others understand how this works?
or
to post comments
Comment
#8
Reg
commented
9 February 2012 at 19:56
I think the answer is I use a module called "views_field_view" (
) not contextual filters. Have a look at that module and see if it will do what you want.
or
to post comments
Comment
#9
stephen Piscura
commented
14 February 2012 at 04:14
Thanks for your reply Reg,
I was hoping to solve my use-case without an extra module, but if i absolutely cannot, then i'll definitely look into Views Field View.
or
to post comments
Comment
#10
rogerrogers
commented
26 June 2012 at 01:36
Category:
support
» bug
Personally, I think this could use a basic fix: Honor the HTML tag setting of the field that the grouping is based on ('Grouping field nr.N').
All the functionality is there, including the ability to override the content, change the surrounding tags, etc. If the grouping setting just used the related fields settings this would be a breeze. I also think this would naturally be expected (at least I anticipated this would be the default behavior).
or
to post comments
Comment
#11
dawehner
German
commented
26 June 2012 at 06:03
Component:
Documentation
» Code
Category:
bug
» feature
There are problems with doing this automatically
This would break all existing groupby views, because people never expected to work like that
You have to make it configurable based on the first argument
or
to post comments
Comment
#12
travis-cunningham
commented
9 October 2012 at 05:20
If you change the format to HTML list and select a grouping field it gives you options to add classes to the wrapping element as well as the list and the list parent.
or
to post comments
Comment
#13
jlongbottom
commented
31 October 2012 at 20:45
I just created a template file that overrides for only that one view and changed the H3 to an H2
or
to post comments
Comment
#14
danny englander
(he/him)
commented
11 November 2012 at 17:48
I just ran into this issue as well. It was a simple matter of switching the display to Semantic Views (you'll need
that module
to do this) and then change the "GROUPING TITLE > Element" to h2. I don't think this is really an issue with Views, it's a themer's task to solve things like this (i.e. #13 above using a template file is a good example as well). Views gives you what are reasonable defaults but it can't anticipate every possible scenario and use case for a themer and a design.
or
to post comments
Comment
#15
damien_vancouver
commented
14 November 2012 at 01:53
I solved this problem using the solution in #13 of overriding the views template file in my custom theme.
I can confirm that it does work despite the comment in #2. You must override the views style template for your currently selected style (I used unformatted list so that is the template I describe). Here are the exact steps I used.
1. Copy the
views-view-unformatted.tpl.php
template file from sites/all/modules/views/theme and place it in your theme's templates folder.
2. Figure out the machine name of your view. Mine was called products_by_category. One way to see this machine name is to edit the view and then look at the URL in your browser address bar. It will contain the machine name: admin/structure/views/view/
products_by_category
/edit
3. Rename the template file you copied in step one to have your view name after --. So I renamed mine to:
views-view-unformatted--products_by_category.tpl.php
so it would only override for this particular view.
4. Edit the template file and adjust the line displaying the title to use whatever you want instead of h3. I made mine use a
:
5. Save everything and clear your site caches.
6. Now when you load your view it should use the new overridden template and your group field will have the markup you want.
or
to post comments
Comment
#16
giorgio79
commented
3 January 2013 at 10:39
#14
I don't think this is really an issue with Views, it's a themer's task to solve things like this
That's why Views should not be adding h3 tags to every group 2 level...
Views adds h3 tags for both HTML List and Unformatted list for group 2. Group 1 gets no heading at all it seems.
One can already provide custom style settings for a field. Views should use that instead of this hardcoded h3...
or
to post comments
Comment
#17
dawehner
German
commented
5 January 2013 at 12:45
Just in case someone is interested, I opened a feature request against Drupal 8.
or
to post comments
Comment
#18
giorgio79
commented
5 January 2013 at 13:09
awesome, here is the ref
#1880100: Allow to configure the h3 element for view style plugins
Just peeked at your post tracker dawehner. Wow, you're doing a massive amount of work. A thread updated around every 10 minutes :)
or
to post comments
Comment
#19
dawehner
German
commented
5 January 2013 at 13:27
The drop is always moving!
or
to post comments
Comment
#20
joakaune
commented
21 January 2013 at 10:13
I just encountered the same problem.
And I can't for the life of me understand the logic behind views adding a random h3 tag in the middle of everything.
It makes no sense at all, and just creates extra work since you have to create a workaround.
Please remove the h3 tags and make everything unformatted unless you add custom style settings to it.
or
to post comments
Comment
#21
HAg
commented
7 March 2013 at 19:48
The solution in #15, works in version 6.x too.
or
to post comments
Comment
#22
imperator_99
commented
26 March 2013 at 01:13
Solution in #15 works perfectly. I changed the H3 to H2 and it all works beautifully. Should not have been an issue at all though - views really should allow you to select the style for the grouping fields just as it does for other fields, as giorgio79 suggested.
or
to post comments
Comment
#23
Abelito
commented
1 May 2013 at 17:19
#13 worked for me!
or
to post comments
Comment
#24
jillpadams
commented
29 May 2013 at 19:33
#15 perfect fix for Grid style as well.
or
to post comments
Comment
#25
aagd
commented
20 September 2013 at 16:10
#15 (damien_vancouver) So easy! Thanks for the instructions. With this custom template I could also add an extra div wrapper around the list to simplify placing on a susy grid.
or
to post comments
Comment
#26
sanjadmin
commented
29 October 2014 at 14:25
Thanks. Post #15 worked for an html list presented in a block. In my case I am using an html list view so my filename is views-view-list--rss_block.tpl.php.
or
to post comments
Comment
#27
ladybug_3777
commented
21 October 2015 at 14:01
Issue summary:
View changes
There is a themeable function that you can override to style the group however you want. Simply use this function in your template.php file in your theme: (This function originally comes from theme.inc within the view module)
function YOURTHEMENAME_views_view_grouping($vars) {
$view = $vars['view'];
$title = $vars['title'];
$content = $vars['content'];
$output = '
$output .= '
$output .= '
$output .= '
return $output;
or
to post comments
Comment
#28
scotwith1t
Birmingham, AL
commented
11 April 2016 at 05:50
Am I crazy, or does this (the theme function above, as well as the views-view-grouping.tpl.php file) only work if you have multiple levels of grouping? I suppose that's because of dawehner's
comment
about breaking backwards compatibility?
or
to post comments
Comment
#29
scotwith1t
Birmingham, AL
commented
11 April 2016 at 06:15
So a nice little trick I just figured out:
1) Set the grouping field to the same field for level 1 and 2
2) Remove this chunk from your views-view-
style
.tpl.php file (copy it to your theme and modify there)
This removes the grouping markup for level 1
3) Copy the views-view-grouping to your theme and go nuts. You can (probably want to, unless you want to modify all groupings) rename to target just the view you're working on (views-view-grouping--
view_machine_name
--
display_id
.tpl.php or the like). If you're ok with targeting the way ALL groupings are rendered, the theme function that @ladybug mentioned should do the trick too.
In fact, I created a views-view-grouping--
view_machine_name
--
display_id
.tpl.php, which worked great, but then I tried a preprocess function named MYTHEME_preprocess_views_view_grouping__
view_machine_name
__
display_id
(&$vars) but it didn't work. I tried getting less specific, like just MYTHEME_preprocess_views_view_grouping__
view_machine_name
(&$vars) but to no avail. Only the MYTHEME_preprocess_views_view_grouping(&$vars) works from what I tried:
function ltl_preprocess_views_view_grouping(&$vars) {
$vars['title'] = 'Group ' . $vars['grouping_level'];
Finally, note that there is a known bug that is being worked on, where $vars['grouping_level'] is always 0 to the template from the preprocess function above.
#1488744: Grouping level is always zero in views_plugin_style::render_grouping_sets()
has a reasonable approach to handle in your theme and patches underway.
or
to post comments
Comment
#30
scotwith1t
Birmingham, AL
commented
11 April 2016 at 06:32
Also, while I'm here, any ideas how to get a count of the groups? I don't see any way to do so at first glance...
or
to post comments
Comment
#31
andrezstar
commented
18 January 2017 at 15:41
#15 +1 cool
or
to post comments
Comment
#32
Dima DD
commented
1 June 2017 at 13:06
Regarding formatting titles of the 1-st (outmost) grouping level in multi-level grouping case, my solution: I've used firebug and noticed that they have css class="view-grouping-header". This class is used in views-view-grouping.tpl.php (and in theme.inc as well). So I've simply declared this class in vews.css (just for testing) and set desired font setting there, and now my 1-st level titles looks great.
or
to post comments
Comment
#33
phily
he/him
French
🇪🇺🇫🇷 Paris, France
commented
7 February 2018 at 16:53
Why not rewrite the output of the field that is used for grouping, wrapping it with the required HTML tags?
No hook nor template nor extra module needed (at least with Views 7.x-3.18).
This also works for multiple groupings: rewrite each field output as wished.
or
to post comments
Comment
#34
millionleaves
commented
29 March 2018 at 03:05
Re: #33 - I am doing that, but all the rewriting is being wrapped in a H3 tag. My rewriting is in a custom field which is used as the grouping field. @PhilY - how did you get it working?
or
to post comments
Comment
#35
phily
he/him
French
🇪🇺🇫🇷 Paris, France
commented
29 March 2018 at 07:24
@millioleaves: on the view's fields list, edit the one you wish to use for grouping to rewrite its output to (for example):
[node:field_myfield]
. Usually, you would also hide that field.
Then, when you use it for grouping, it outputs as rewritten rather than with native
wrapper.
or
to post comments
Comment
#36
talisa1987
commented
19 July 2018 at 22:04
#12 Simple and easy solution of the problem. Thank you very much Travis. You saved my time
or
to post comments
Comment
#37
eigentor
commented
5 September 2018 at 13:13
As of today the issue dawehner created did not get into core.
#15 appears to be the most manageable workaround with the least tradeoffs.
or
to post comments
Comment
#38
ErnoVanhala
commented
28 November 2018 at 19:23
I stumbled upon this issue now. I have to say that this really sounds strange that you have no way to select the tag for grouping when you have it with normal fields. And then there is forced H3 for the first last grouping item.
How in the Earth this kind of thing has passed testing years ago and is still not fixed? :)
or
to post comments
Comment
#39
liam morland
Ontario, CA 🇨🇦
commented
13 December 2019 at 15:57
The
h3
should not be hard-coded. Will the maintainers accept a patch that makes the grouping element be configurable?
or
to post comments
Comment
#40
GuitarKat
commented
16 December 2019 at 22:45
h3 should not be hard-coded, I agree. I have found a workaround since then by applying a class on the text affected by it via a custom field. It is so strange.
or
to post comments
Comment
#41
chris matthews
commented
21 February 2020 at 17:56
Project:
Views (for Drupal 7)
» Drupal core
Version:
7.x-3.x-dev
» 9.1.x-dev
Component:
Code
» views_ui.module
I just ran into this myself in Drupal 8 core Views UI. There is probably very little chance this will get 'fixed' in Drupal 7 contrib Views so updating the IS accordingly.
Project: Drupal core
Version: 9.1.x-dev
Component: views_ui.module
or
to post comments
Comment
#42
kevinhbruce
commented
17 April 2020 at 18:26
Chiming in with this, as well. I also just ran into this. Although, I found that the previous dev hardcoded it. I'd love to be able to delete this comment now, but it seems that's not an option.
or
to post comments
Comment
#43
mmlmitchell
commented
14 September 2020 at 22:18
Here's a work-around for this pesky problem...
Edit the field being used for grouping
Open "Rewrite results" > Check "Override the output"
Begin the override text string with
, which cancels the troublesome html element
Insert your own tags and/or elements
Example:
The grouping field has the machine name of "field_model_component".
The override text =
or
to post comments
Comment
#44
liam morland
Ontario, CA 🇨🇦
commented
15 September 2020 at 01:03
@#43: This likely works visually in many themes, but it would result in invalid HTML and would have accessibility problems due to the empty header element.
or
to post comments
Comment
#45
15 September 2020 at 01:03
Version:
9.1.x-dev
» 9.2.x-dev
Drupal 9.1.0-alpha1
will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the
Drupal 9 minor version schedule
and the
Allowed changes during the Drupal 9 release cycle
or
to post comments
Comment
#46
15 September 2020 at 01:03
Version:
9.2.x-dev
» 9.3.x-dev
Drupal 9.2.0-alpha1
will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the
Drupal core minor version schedule
and the
Allowed changes during the Drupal core release cycle
or
to post comments
Comment
#47
dalemoore
commented
24 May 2021 at 15:33
I've solved this for years using the template copy method in D7, but also never understood why you can change the H-level in the field UI but not for the grouping. I ran into it yet again just today and so came back to see if anyone else had recently posted. 😄 IMO, headings should always be configurable, whether in a field, a block, view, layout builder, whatever for proper outline/accessibility.
or
to post comments
Comment
#48
chrisgross
commented
21 June 2021 at 16:35
I just ran into an issue in Drupal 8.9 where I cannot override the views grouping template at all if I don't have at least two grouping levels. views-view-grouping.html.twig does not seem do anything at all in this situation, nor can I trigger template_preprocess_views_view_grouping(). If I use two grouping levels, the second one does not have a template that I can override. This seems similar to what scotwith1t mentioned in #28, but his solution appears to have been for D7 and I cannot find a corresponding workaround for D8.
If I enable the twig markup debugging, it says the grouping title uses views-view-field.html.twig, but there does not seem to be any actual grouping going on in the templates at all. I don't have an h3 at all to remove, but I desperately need to be able to wrap field groupings in custom markup and I cannot. Has anyone discovered a similar workaround for this? Drupal's theme layer is basically telling me that the grouping I set in the views UI is not actually a grouping. It is maddening.
or
to post comments
Comment
#49
chrisgross
commented
21 June 2021 at 19:03
So far, the only simple workaround I've found is to add a dummy custom text field to the view, hide it from display, and use that as the first grouping level. Then, the real group I actually wanted to create can be grouping level two and Drupal will let me theme that.
Alternatively, you can edit your twig template, in this case,
views-view-unformatted.html.twig
and do some complicated logic where you repeatedly check the condition
{% if view.style_plugin.options.grouping %}
and then insert and modify whatever markup is needed to properly group things together. For second level grouping and deeper, you'd still have to modify
views-view-grouping.html.twig
But this seems like a really bad bug that needs to be fixed. I imagine it shouldn't be so confusing to figure out that grouping is treated differently depending on the grouping level and then come up with completely different approaches.
or
to post comments
Comment
#50
21 June 2021 at 19:03
Version:
9.3.x-dev
» 9.4.x-dev
Drupal 9.3.0-rc1
was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the
Drupal core minor version schedule
and the
Allowed changes during the Drupal core release cycle
or
to post comments
Comment
#51
21 June 2021 at 19:03
Version:
9.4.x-dev
» 9.5.x-dev
Drupal 9.4.0-alpha1
was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the
Drupal core minor version schedule
and the
Allowed changes during the Drupal core release cycle
or
to post comments
Comment
#52
brianbrarian
commented
10 June 2022 at 16:18
The Semantic Views contrib module mentioned in #14 seems to work as a workaround, as long as you want your view to display as an unformatted list or html list. And I was able to use CSS to make an unformatted list in a Semantic Views Style display look like a multi-column vertical-alignment grid display.
But I'm a +1 that this needs to be fixed in core.
or
to post comments
Comment
#53
13 July 2022 at 18:06
theMusician
made their first commit to this issue’s fork.
or
to post comments
Comment
#54
27 July 2022 at 21:13
CarlyGerard
made their first commit to this issue’s fork.
or
to post comments
Comment
#55
10 August 2022 at 22:17
npacker
made their first commit to this issue’s fork.
or
to post comments
Comment
#56
31 August 2022 at 22:03
CarlyGerard
opened
merge request !2711
or
to post comments
Comment
#57
carlygerard
She/Her/Hers
commented
9 September 2022 at 23:49
Title:
How to change the HTML wrapped around a grouping output (HTML h3 tag)
» Allow a custom HTML element to be selected for a grouping field
Issue summary:
View changes
Issue tags:
Related issues:
#1880100: Allow to configure the h3 element for view style plugins
Status
File
Size
new
MicrosoftTeams-image.png
125.35 KB
or
to post comments
Comment
#58
carlygerard
She/Her/Hers
commented
12 September 2022 at 17:50
Issue summary:
View changes
or
to post comments
Comment
#59
12 September 2022 at 17:50
Version:
9.5.x-dev
» 10.1.x-dev
Drupal 9.5.0-beta2
and
Drupal 10.0.0-beta2
were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the
Drupal core minor version schedule
and the
Allowed changes during the Drupal core release cycle
or
to post comments
Comment
#60
laura.gates
She/Her
commented
12 October 2022 at 22:22
Is it possible for this to be back-ported to 9.4.x? I'm running into an issue that I think this issue resolves where grouping by a date field results in duplicate content because when editing the views-view-unformatted.html.twig file it thinks that
{% if title %}
{{ title }}
{% endif %}
is the title field, when in fact it's the grouped by field. Thus making it almost impossible to then create a
{% for row in rows %}
loop.
or
to post comments
Comment
#61
carlygerard
She/Her/Hers
commented
20 October 2022 at 22:02
Hi Laura, since this is a new feature, Drupal recommends we develop for 10.1.x (see
comment #59
), so our team can't backport this fix to 9.4.x. If you have the dev time and need this for your site, you're welcome to use the
dev branch
as a baseline and make a custom 9.4.x patch for your site and/or theme.
or
to post comments
Comment
#62
1 November 2022 at 22:52
CarlyGerard
opened
merge request !2921
or
to post comments
Comment
#63
1 November 2022 at 23:58
CarlyGerard
closed
merge request !2921
or
to post comments
Comment
#64
2 November 2022 at 00:00
CarlyGerard
opened
merge request !2922
or
to post comments
Comment
#65
carlygerard
She/Her/Hers
commented
2 November 2022 at 00:06
Issue summary:
View changes
or
to post comments
Comment
#66
4 November 2022 at 14:59
CarlyGerard
closed
merge request !2922
or
to post comments
Comment
#67
4 November 2022 at 14:59
CarlyGerard
opened
merge request !2927
or
to post comments
Comment
#68
4 November 2022 at 15:00
CarlyGerard
closed
merge request !2927
or
to post comments
Comment
#69
4 November 2022 at 15:01
CarlyGerard
reopened
merge request !2922
or
to post comments
Comment
#70
carlygerard
She/Her/Hers
commented
10 November 2022 at 22:19
Issue summary:
View changes
or
to post comments
Comment
#71
carlygerard
She/Her/Hers
commented
10 November 2022 at 22:20
Issue summary:
View changes
or
to post comments
Comment
#72
carlygerard
She/Her/Hers
commented
10 November 2022 at 22:27
Issue summary:
View changes
or
to post comments
Comment
#73
lendude
Dutch
Amsterdam
commented
11 November 2022 at 08:45
Status:
Active
» Needs work
Just a warning, since I have no idea what the actual state of this is, the MR currently contains a massive amount of unrelated code clean up, if this is to have any chance of landing those need to be removed.
or
to post comments
Comment
#74
carlygerard
She/Her/Hers
commented
14 November 2022 at 21:53
Thanks for taking a look and giving the pull request a review @lendude. I think "needs work" as a status makes sense for now--it is an active ticket but the next major task on our list is writing tests, and I think there's redundant line cleanup I agree needs to happen before we go on to that step (it seems like there were some rebase/conflict issues I missed, causing the repeated lines).
Some code changes, though, are based on results we get from running the PHPCS Drupal standard, would you consider that "unrelated code"? When we run Drupal PHPCS on the 10.1.x version of Grid.php on line 64, for example, we get the following error (this becomes line 71 with the MR 2922 changes):
FILE: [base-path]/test-drupal10/web/core/modules/views/src/Plugin/views/style/Grid.php
-----------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------------------
64 | ERROR | The array declaration extends to column 96 (the limit is 80). The array content should be split up
| | over multiple lines
-----------------------------------------------------------------------------------------------------------------
Since we're developing on this file and should push code that
meets Drupal's coding standards,
it seems like it would be our responsibility then to help get the newer version of the file up to standard. Agreed all of our new code should follow that standard, but if there are minor changes like that one (1-5 lines tops), should we not get the code syntax up to standard as well?
or
to post comments
Comment
#75
carlygerard
She/Her/Hers
commented
20 December 2022 at 19:28
Issue tags:
Needs change record
, +
Needs manual testing
or
to post comments
Comment
#76
carlygerard
She/Her/Hers
commented
20 December 2022 at 19:34
I will write the change record for this ticket.
or
to post comments
Comment
#77
themusician
commented
5 January 2023 at 19:25
Issue summary:
View changes
or
to post comments
Comment
#78
mgifford
he/him
commented
20 January 2023 at 19:17
Issue tags:
wcag131
I think this would apply to WCAG SC 1.3.1
or
to post comments
Comment
#79
20 January 2023 at 19:17
Version:
10.1.x-dev
» 11.x-dev
Drupal core is moving towards using a “main” branch.
As an interim step, a new
11.x
branch has been opened
, as Drupal.org infrastructure cannot currently fully support a branch named
main
. New developments and disruptive changes should now be targeted for the
11.x
branch, which currently accepts only minor-version allowed changes. For more information, see the
Drupal core minor version schedule
and the
Allowed changes during the Drupal core release cycle
or
to post comments
Comment
#80
carlygerard
She/Her/Hers
commented
8 December 2023 at 18:38
Status
File
Size
new
1383696-80.patch
19.52 KB
This patch file re-rolls previous MRs from Gitlab workflow as a patch file for 11.x Work still needs to be done in figuring out caching so the wrapper tag option is stored properly. A new patch is needed once that's addressed.
or
to post comments
Comment
#81
carlygerard
She/Her/Hers
commented
5 April 2024 at 17:58
Status
File
Size
new
1383696-81.patch
20.3 KB
Should fix Drupal command fails in 11.x re-roll patch from #80.
or
to post comments
Comment
#82
5 April 2024 at 22:27
theMusician
changed the visibility of the branch
1383696-how-to-change
to
hidden
or
to post comments
Comment
#83
themusician
commented
5 April 2024 at 23:49
It appears the patch was applied cleanly. There is what seems to be an unrelated error in a unit test when testing the merge request.
Drupal\Tests\editor\Functional\EditorSecurityTest 0 passes 1 exceptions
FATAL Drupal\Tests\editor\Functional\EditorSecurityTest: test runner returned a non-zero error code (2).
Drupal\Tests\editor\Functional\EditorSecurityTest 0 passes 1 fails
---- Drupal\Tests\editor\Functional\EditorSecurityTest ----
Status Group Filename Line Function
--------------------------------------------------------------------------------
Exception Other phpunit-93.xml 0 Drupal\Tests\editor\Functional\Edit
PHPUnit Test failed to complete; Error: PHPUnit 9.6.15 by Sebastian
Bergmann and contributors.
Testing Drupal\Tests\editor\Functional\EditorSecurityTest
..E 3 / 3
(100%)
Time: 00:23.789, Memory: 4.00 MB
There was 1 error:
1)
Drupal\Tests\editor\Functional\EditorSecurityTest::testEditorXssFilterOverride
Behat\Mink\Exception\ExpectationException: The field "edit-body-0-value"
value is "Hello, Dumbo Octopus!alert(0)", but "Hello, Dumbo
Octopus!alert(0)" expected.
/builds/issue/drupal-1383696/vendor/behat/mink/src/WebAssert.php:888
/builds/issue/drupal-1383696/vendor/behat/mink/src/WebAssert.php:781
/builds/issue/drupal-1383696/core/tests/Drupal/Tests/WebAssert.php:968
/builds/issue/drupal-1383696/core/modules/editor/tests/src/Functional/EditorSecurityTest.php:447
/builds/issue/drupal-1383696/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
ERRORS!
Tests: 3, Assertions: 137, Errors: 1.
or
to post comments
Comment
#84
6 April 2024 at 00:29
theMusician
opened
merge request !7351
or
to post comments
Comment
#85
8 April 2024 at 13:51
fjgarlin
changed the visibility of the branch
drupal-1383696-82
to
hidden
or
to post comments
Comment
#86
8 April 2024 at 13:51
fjgarlin
changed the visibility of the branch
drupal-1383696-82
to
active
or
to post comments
Comment
#87
10 April 2024 at 00:14
acbramley
changed the visibility of the branch
gerardc/1383696
to
hidden
or
to post comments
Comment
#88
10 April 2024 at 00:28
acbramley
changed the visibility of the branch
gerardc/1383696-c
to
hidden
or
to post comments
Comment
#89
10 April 2024 at 00:29
acbramley
changed the visibility of the branch
packern/view-grouping-header
to
hidden
or
to post comments
Comment
#90
acbramley
commented
10 April 2024 at 00:30
2 files were hidden/shown/deleted
Status
File
Size
hidden
1383696-80.patch
19.52 KB
hidden
1383696-81.patch
20.3 KB
All old MRs and patches are now hidden, work should be continued on
or
to post comments
Comment
#91
12 April 2024 at 16:53
smustgrave
made their first commit to this issue’s fork.
or
to post comments
Comment
#92
themusician
commented
12 April 2024 at 17:29
Status:
Needs work
» Needs review
New code appears to be passing.
or
to post comments
Comment
#93
smustgrave
commented
18 April 2024 at 18:36
Status:
Needs review
» Needs work
Issue tags:
Needs subsystem maintainer review
Left some comments.
Didn't check but if any of those templates are declared in a theme in core they'll have to be updated too.
Definitely will need a CR and probably submaintainer sign off
or
to post comments
Comment
#94
24 April 2024 at 21:45
CarlyGerard
changed the visibility of the branch
drupal-1383696-drupal-1383696-82
to
hidden
or
to post comments
Comment
#95
carlygerard
She/Her/Hers
commented
26 April 2024 at 19:35
Status:
Needs work
» Needs review
The MR
is now passing with the latest changes as requested (with some allowed fails in the pipeline). Updating status for the next stage of review.
or
to post comments
Comment
#96
smustgrave
commented
30 April 2024 at 18:17
Status:
Needs review
» Needs work
Moving to NW for the change record
But question what will happen if $usesGroupingLabelElement isn't present. Lot of contrib plugins will take a while to update.
or
to post comments
Comment
#97
themusician
commented
3 May 2024 at 17:38
Thank you for the feedback.
To answer your question about if a view does not have $usesGroupingLabelElement present, the twig templates handle that logic and print the title.
If it is present, such as after this patch is applied, but not set, the code supports the current default of the grouping label being an h3 or empty.
Contrib plugins would have an option of using this way of handling additional HTML options or could continue doing it however they currently make it happen.
There are a few of the core themes that use the twig template overrides for views-view-unformatted.html.twig, views-view-list.html.twig, and a few more. You suggest updating these in this same patch. As I understand it, the twig templates would be updated where appropriate for claro, olivero, stark, and starterkit_theme but not stable9. The same approach would be for engines/twig excluding updates to stable9. Is that correct?
or
to post comments
Comment
#98
themusician
commented
6 May 2024 at 23:24
Issue tags:
Portland2024
or
to post comments
Comment
#99
themusician
commented
8 May 2024 at 18:42
Issue summary:
View changes
Status:
Needs work
» Needs review
Issue tags:
Needs change record
Good morning,
I have authored a proposed change record for review by others.
I have also pushed an updated branch that includes theme updates to the core themes where the views templates are included. I did not, however, update Stable 9 as my understanding is that the Stable 9 theme is locked in place. I am happy to make the changes there if required.
or
to post comments
Comment
#100
smustgrave
commented
14 May 2024 at 17:23
Status:
Needs review
» Needs work
Went to review but appears MR has some failures
or
to post comments
Comment
#101
themusician
commented
20 May 2024 at 18:48
Status:
Needs work
» Needs review
The test had been failing due to this upstream bug, that has now been fixed. Thanks to nicxvan and mikelutz for troubleshooting over in #contribute on Slack.
Resolved bug that was causing test failures:
Tests are now passing.
or
to post comments
Comment
#102
nicxvan
commented
24 May 2024 at 15:04
Status:
Needs review
» Needs work
Coincidentally I just needed this patch myself. I suspect that this will need to add something to the ViewsConfigUpdater since it is adding config to Views.
I did this earlier this year and it can be quite complex, I'm working on documenting it here
#3447755: Document ViewsConfigUpdater
I'm not sure why tests are not triggering on the changed config already, maybe cause it's a sub item under grouping, but this adds new config: grouping_label_element: h2.
I'm also not sure why it wouldn't be limited to heading tags like the views pager update linked in the documentation issue.
I'm happy to help guide someone on the views update config changes since I know it's a pretty significant wrench in the process.
This may need additional tests too.
or
to post comments
Comment
#103
nicxvan
commented
24 May 2024 at 15:30
It might be helpful to add an example of views-view-grouping.html.twig in the change record too since the starterkit theme generation is different than the example.
or
to post comments
Comment
#104
nicxvan
commented
24 May 2024 at 17:54
I am also getting this on pages with this patch, I think on views without a grouping set:
Undefined array key "grouping_label_element" in Drupal\views\Plugin\views\style\StylePluginBase->renderGroupingSets() (line 559 of core/modules/views/src/Plugin/views/style/StylePluginBase.php).
or
to post comments
Comment
#105
themusician
commented
31 May 2024 at 22:01
Thanks for the feedback. I agree that the undefined array key error is because the views did not get the update to set grouping_label_element to null.
The ViewsConfigUpdater code requirement makes sense to me as being necessary. On a separate issue,
, the test update never fires even though I wrote a function in ViewsConfigUpdater but I was not aware you have to also call the function in updateAll(). The documentation improvements for how to use ViewConfigUpdater is a great idea.
Here is a rough idea of what I think is needed. @CarlyGerard also involved with this ticket walked me through what this may end up requiring. In the protected function addGroupingLabel() I can't quite figure out what the handler represents. The parameter defines it as a display handler, so I think a view style is represented here as the handler_type "style" and that is also the plugin_id? These ideas came from one of the issues you referenced, thank you for the pointer -
/**
* Performs all required updates.
* @param \Drupal\views\ViewEntityInterface $view
* The View to update.
* @return bool
* Whether the view was updated.
*/
public function updateAll(ViewEntityInterface $view) {
return $this->processDisplayHandlers($view, FALSE, function (&$handler, $handler_type, $key, $display_id) {
$changed = FALSE;
if ($this->addGroupingLabelElement($handler, $handler_type, $view)) {
$changed = TRUE;
return $changed;
});
/**
* Add Grouping Label to views without one.
* @param array $handler
* A display handler.
* @param string $handler_type
* The handler type.
* @param \Drupal\views\ViewEntityInterface $view
* The View being updated.
* @return bool
* Whether the handler was updated.
*/
protected function addGroupingLabelElement(array &$handler, string $handler_type, ViewEntityInterface $view): bool {
$changed = FALSE;
// Add grouping label element to existing views.
if (($handler_type === 'style')
&& isset($handler['plugin_id'], $handler['type'])
&& $handler['plugin_id'] === 'style'
&& $handler['type'] === 'Grid' || 'HtmlList' || 'GridResponsive' || 'DefaultStyle'
&& !isset($handler['style']['grouping_label_element'])) {
$handler['style']= ['grouping_label_element' => NULL];
$changed = TRUE;
return $changed;
You asked, why the allowed grouping elements would not be restricted to just heading tags like the views pager update. For the grouping use cases, grid, HtmlList, GridResponsive it seemed hard to predict that one would only ever group by heading. Using labelELements,
, makes it so available elements do not need to be maintained in this code as well as the views.settings. I concur that the most common use case would be headings but I am not confident that there would never be a need to group by another element.
Thanks again for the feedback, the questions, and the guidance.
or
to post comments
Comment
#106
nicxvan
commented
31 May 2024 at 23:22
At a quick glance that looks right: also if you want to link an issue in a comment where the issue status color comes up can you use:
[#issuenumber]
like this
#2770835: Add support for tables with two headers in views table display
or
to post comments
Comment
#107
29 March 2025 at 16:18
themusician
changed the visibility of the branch
drupal-1383696-drupal-1383696-82
to
active
or
to post comments
Comment
#108
29 March 2025 at 16:19
themusician
changed the visibility of the branch
drupal-1383696-drupal-1383696-82
to
hidden
or
to post comments
Comment
#109
themusician
commented
29 March 2025 at 17:17
Status:
Needs work
» Needs review
I believe the ViewsUpdateConfig functions now are properly looping through existing views and setting the grouping to the default if it is not already set.
If using grouping on existing views, the default is the h3 element as it is already set to, after the config update executes.
or
to post comments
Comment
#110
needs-review-queue-bot
commented
2 April 2025 at 10:28
Status:
Needs review
» Needs work
Status
File
Size
new
1383696-nr-bot.txt
8.03 KB
The
Needs Review Queue Bot
tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the
Drupal Contributor Guide
to find step-by-step guides for working with issues.
or
to post comments
Comment
#111
2 April 2025 at 10:28
Version:
11.x-dev
» main
Drupal core is now using the
main
branch as the primary development branch. New developments and disruptive changes should now be targeted to the
main
branch.
Read more in the announcement
or
to post comments
Comment
#112
robcarr
Perthshire, Scotland
commented
18 March 2026 at 12:46
I'm unable to apply the MR as a patch against 11.x
or
to post comments
Comment
#113
2 April 2026 at 20:28
ehlovader
made their first commit to this issue’s fork.
Attempted to rebase for rerolling the patch.
Looking into failing PHPcs and PHPstan tests next
or
to post comments
Comment
#114
2 April 2026 at 20:43
ehlovader
changed the visibility of the branch
drupal-1383696-82-11.x
to
hidden
or
to post comments
Comment
#115
2 April 2026 at 20:43
ehlovader
changed the visibility of the branch
drupal-1383696-82-11.x
to
hidden
or
to post comments
Comment
#116
ehlovader
commented
2 April 2026 at 23:15
Well I tried rerolling the MR but ran into a bunch of PHPCS and PHPStan errors in the build, but locally they aren't detecting any issues when I run them for Drupal standards. In addition to that the patch won't apply normally.
I believe some of my trouble applying the patch locally despite the phpcs stuff is related to rebasing across a rewrite to use class based hooks.
I'll keep looking into it, started to rebase on a new branch but was still on the main branch shown, maybe I will look into that new branch again to try and avoid introducing more issues.
When I did get the patch applied though I saw the dropdown for group markup, but I think I lost the multiple grouping levels that I'd expected.
or
to post comments
Comment
#117
ehlovader
commented
3 April 2026 at 00:59
Just pushed the original back to 39368b50 from another branch, I will continue trying to rebase from the other 11.x branch I started
or
to post comments
Comment
#118
3 April 2026 at 20:51
ehlovader
changed the visibility of the branch
drupal-1383696-82-11.x
to
active
or
to post comments
Comment
#119
7 April 2026 at 14:03
ehlovader
opened
merge request !15366
or
to post comments
Comment
#120
ehlovader
commented
7 April 2026 at 15:42
@robcarr confirmed the reroll of this fix onto 11.x in MR !15366 works on 11.3, and patches cleanly.
There are a lot of PHPCS constraints added to main that will require some work to clean up and make this mergable there.
or
to post comments
Comment
#121
themusician
commented
7 April 2026 at 16:07
How exciting to see movement on this again. Thank you for pushing this along.
or
to post comments
Comment
#122
ehlovader
commented
7 April 2026 at 19:38
It does appear that there was more to the refactoring of
addGroupingLabelElement
than just getting it to use an array format for the display handler and styles values.
The structure of the style config appears to have changed and is deeper than it was. it was no longer just grouping_label_element but now has more and multiple group levels.
I also found that this has no effect on HTML Lists in the
Bootstrap5 theme
, the views-view-list template is overridden there and is also hardcoded with an
h3
I might take a closer look at the display handler structure, see if it is an easy fix, but the theme situation feels like more of a blocker to me right now
or
to post comments
Contribution record
Change record drafts
Allow for a specific HTML element to be selected for a views grouping field
Add child issue
clone issue
Related issues
Referenced by
#1880100: Allow to configure the h3 element for view style plugins
Infrastructure management for Drupal.org provided by
Need a Drupal 7 extended support partner? Consider Tag1.
News items
News
Planet Drupal
Social media
Sign up for Drupal news
Security advisories
Jobs
Our community
Community
Services
Training
Hosting
Contributor guide
Groups & meetups
DrupalCon
Code of conduct
Documentation
Documentation
Drupal Guide
Drupal User Guide
Developer docs
API.Drupal.org
Drupal code base
Download & Extend
Drupal core
Modules
Themes
Distributions
Governance of community
About
Web accessibility
Drupal Association
About Drupal.org
Drupal is a
registered trademark
of
Dries Buytaert