To make the patch in #470258: Groupwise maximum ('representative') relationships work properly, I had to slightly alter the behavior of the add_orderby method of views_plugin_query_default.

Currently, when the views query is built, add_orderby adds an aliased field into the SELECT clause (by adding a field to the View object) and then ORDERing by the aliased field: SELECT sort_field as sort_field_alias ... ORDER BY sort_field_alias).

As far as I know, the ORDER BY clause can simply use the table alias instead: table_alias.field.

Adding a field to the View (and consequently the select clause) should at best be an optional side-effect, and it seems to e like it just shouldn't happen there at all. My concern is that other code may depend on the field being added when add_orderby is called.

I generated a few views to test it out, a couple with complex relationships -- nothing broke, and the generated queries matched my hand-written queries pretty closely. But I definitely haven't tested it thoroughly.

CommentFileSizeAuthor
#13 844910-views.dont-add-field-in-orderby.patch978 bytesdavideads
#8 844910-views.dont-add-field-in-orderby.patch982 bytesdavideads
#1 views.dont-add-field-in-orderby.patch636 bytesdavideads

Comments

davideads’s picture

davideads commented
StatusFileSize
new views.dont-add-field-in-orderby.patch636 bytes

Whoops, preview ate my attachment, apparently.

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Needs work

We cannot remove the add_field, this would be a major api change. I suggest you to look at this export

$view = new view;
$view->name = 'last_comment';
$view->description = '';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 3.0-alpha1;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Defaults */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'fields';
/* Field: Node: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['title']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title']['alter']['html'] = 0;
$handler->display->display_options['fields']['title']['hide_empty'] = 0;
$handler->display->display_options['fields']['title']['empty_zero'] = 0;
$handler->display->display_options['fields']['title']['link_to_node'] = 0;
/* Sort criterion: Node: Updated/commented date */
$handler->display->display_options['sorts']['last_updated']['id'] = 'last_updated';
$handler->display->display_options['sorts']['last_updated']['table'] = 'node_comment_statistics';
$handler->display->display_options['sorts']['last_updated']['field'] = 'last_updated';

Before sql:

SELECT node.title AS node_title,
GREATEST(node.changed, node_comment_statistics.last_comment_timestamp) AS node_comment_statistics_last_updated
 FROM node node 
 INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
    ORDER BY node_comment_statistics_last_updated ASC

After sql:

SELECT node.title AS node_title
 FROM node node 
 INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
    ORDER BY node_comment_statistics_last_updated ASC
merlinofchaos’s picture

merlinofchaos commented

ANSI SQL requires that any field in the ORDER BY clause must also be in the SELECT clause. The add_field() is therefore not optional.

joachim’s picture

joachim commented

> ANSI SQL requires that any field in the ORDER BY clause must also be in the SELECT clause

Wha...?

MySQL doesn't need this, and PostGRESQL (or however the capitals go) doesn't need it -- and it's total crack. It means that you can't order a subquery! (And thus #470258: Groupwise maximum ('representative') relationships becomes impossible.)

merlinofchaos’s picture

merlinofchaos commented

This was added specifically due to pgsql which does, in fact, appear to need this. Or at least did when this went in.

joachim’s picture

joachim commented

See http://www.postgresql.org/docs/8.2/static/sql-select.html#SQL-ORDERBY

It is also possible to use arbitrary expressions in the ORDER BY clause, including columns that do not appear in the SELECT result list. Thus the following statement is valid:

SELECT name FROM distributors ORDER BY code;

Postgresl is st00pid but it's not THAT st00pid ;)

davideads’s picture

davideads commented

I've given a bit more thought to this after seeing Dereine's example view. That was the use case I was looking for, but couldn't figure out. Because the field is computed, it must be aliased to allow ordering.

I don't believe, based on my research, that a field must be in the select clause to allow ordering, at least in SQL-92 and both Postgres and MySQL's implementations. And, to use a real world example that I've had to work with lately: Django's ORM uses ORDER BY tablealias.fieldname syntax to build sorts with both the MySQL and PostgreSQL backends. Fields are added to the select clause as requested, with no connection between then. Admittedly, this makes the "last comment or last update" sort harder to accomplish than in View's handler-oriented framework. My point is really just that AFAICT (and I'm no expert) and based on other real world implementations, this shouldn't be out of the question.

This suggests two other possible approaches:

One approach would be to make a new rule: If a field uses a database function (such as a comparison function or user defined function for IP address manipulation), it must invoke add_orderby with a declared alias. At least it would narrow down the list of potentially backward incompatible code to calls to add_orderby that use a computed field AND don't specify its own alias.

For example, views_handler_sort_ncs_last_updated.inc already specifies an explicit alias when adding ordering in its query method:

class views_handler_sort_ncs_last_updated extends views_handler_sort_date {
  function query() {
    $this->ensure_my_table();
    $this->node_table = $this->query->ensure_table('node', $this->relationship);
    $this->field_alias = $this->query->add_orderby(NULL, "GREATEST(" . $this->node_table . ".changed, " . $this->table_alias . ".last_comment_timestamp)", $this->options['order'], <strong>$this->table_alias . '_' . $this->field</strong>);
  }
}

I've attached a patch that implements this behavior. I think there's still room for improvement, but I believe this is fairly backwards compatible, and doesn't fundamentally change the function as described in the doxygen documentation. Personally, I think this is a reasonable approach, and represents a small step towards magic elimination.

Another approach would simply be to add a flag to the function signature which specifies the "build" mode. This would be the safest, most backward compatible approach, and I'd still be quite happy to see it.

Take a look at this (contrived) example view:

$view = new view;
$view->name = 'add_orderby_test';
$view->description = 'Testing changes to add_orderby method.';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 3.0-alpha1;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

$view = new view;
$view->name = 'patch_test';
$view->description = 'Testing';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 3.0-alpha1;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Defaults */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['style_plugin'] = 'list';
$handler->display->display_options['row_plugin'] = 'fields';
/* Relationship: Content: List of pages (field_pages) */
$handler->display->display_options['relationships']['field_pages_nid']['id'] = 'field_pages_nid';
$handler->display->display_options['relationships']['field_pages_nid']['table'] = 'node_data_field_pages';
$handler->display->display_options['relationships']['field_pages_nid']['field'] = 'field_pages_nid';
$handler->display->display_options['relationships']['field_pages_nid']['required'] = 0;
$handler->display->display_options['relationships']['field_pages_nid']['delta'] = '-1';
/* Field: Node: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['title']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title']['alter']['html'] = 0;
$handler->display->display_options['fields']['title']['hide_empty'] = 0;
$handler->display->display_options['fields']['title']['empty_zero'] = 0;
$handler->display->display_options['fields']['title']['link_to_node'] = 0;
/* Field: Node: Post date */
$handler->display->display_options['fields']['created']['id'] = 'created';
$handler->display->display_options['fields']['created']['table'] = 'node';
$handler->display->display_options['fields']['created']['field'] = 'created';
$handler->display->display_options['fields']['created']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['created']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['created']['alter']['trim'] = 0;
$handler->display->display_options['fields']['created']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['created']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['created']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['created']['alter']['html'] = 0;
$handler->display->display_options['fields']['created']['hide_empty'] = 0;
$handler->display->display_options['fields']['created']['empty_zero'] = 0;
/* Field: Node: Title */
$handler->display->display_options['fields']['title_1']['id'] = 'title_1';
$handler->display->display_options['fields']['title_1']['table'] = 'node';
$handler->display->display_options['fields']['title_1']['field'] = 'title';
$handler->display->display_options['fields']['title_1']['relationship'] = 'field_pages_nid';
$handler->display->display_options['fields']['title_1']['label'] = 'Child Title';
$handler->display->display_options['fields']['title_1']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title_1']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title_1']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title_1']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['title_1']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['title_1']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title_1']['alter']['html'] = 0;
$handler->display->display_options['fields']['title_1']['hide_empty'] = 0;
$handler->display->display_options['fields']['title_1']['empty_zero'] = 0;
$handler->display->display_options['fields']['title_1']['link_to_node'] = 0;
/* Field: Node: Updated/commented date */
$handler->display->display_options['fields']['last_updated']['id'] = 'last_updated';
$handler->display->display_options['fields']['last_updated']['table'] = 'node_comment_statistics';
$handler->display->display_options['fields']['last_updated']['field'] = 'last_updated';
$handler->display->display_options['fields']['last_updated']['relationship'] = 'field_pages_nid';
$handler->display->display_options['fields']['last_updated']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['last_updated']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['last_updated']['alter']['trim'] = 0;
$handler->display->display_options['fields']['last_updated']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['last_updated']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['last_updated']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['last_updated']['alter']['html'] = 0;
$handler->display->display_options['fields']['last_updated']['hide_empty'] = 0;
$handler->display->display_options['fields']['last_updated']['empty_zero'] = 0;
/* Sort criterion: Node: Updated/commented date */
$handler->display->display_options['sorts']['last_updated_1']['id'] = 'last_updated_1';
$handler->display->display_options['sorts']['last_updated_1']['table'] = 'node_comment_statistics';
$handler->display->display_options['sorts']['last_updated_1']['field'] = 'last_updated';
$handler->display->display_options['sorts']['last_updated_1']['order'] = 'DESC';
/* Filter: Node: Type */
$handler->display->display_options['filters']['type']['id'] = 'type';
$handler->display->display_options['filters']['type']['table'] = 'node';
$handler->display->display_options['filters']['type']['field'] = 'type';
$handler->display->display_options['filters']['type']['value'] = array(
  'story' => 'story',
);

With the patch applied, this generates:

SELECT node.title AS node_title,
node.created AS node_created,
node_node_data_field_pages.title AS node_node_data_field_pages_title,
GREATEST(node_node_data_field_pages.changed, node_node_data_field_pages__node_comment_statistics.last_comment_timestamp) AS node_node_data_field_pages__node_comment_statistics_last_upd,
GREATEST(node.changed, node_comment_statistics.last_comment_timestamp) AS node_comment_statistics_last_updated
 FROM node node 
 LEFT JOIN content_field_pages node_data_field_pages ON node.vid = node_data_field_pages.vid
 LEFT JOIN node node_node_data_field_pages ON node_data_field_pages.field_pages_nid = node_node_data_field_pages.nid
 INNER JOIN node_comment_statistics node_node_data_field_pages__node_comment_statistics ON node_node_data_field_pages.nid = node_node_data_field_pages__node_comment_statistics.nid
 INNER JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
 WHERE node.type in ('story')
   ORDER BY node_comment_statistics_last_updated DESC

In this case, I think the question becomes "what happens when a relationship is specified in a sort or filter handler?"

davideads’s picture

davideads commented
StatusFileSize
new 844910-views.dont-add-field-in-orderby.patch982 bytes

Oh darn, again, here is patch.

davideads’s picture

davideads commented

Has any thought been given to this patch? I've been successfully using it on a testing/development site for several weeks, with no adverse effects.

joachim’s picture

joachim commented

Is that a PostgreSQL site though?

davideads’s picture

davideads commented

No, it is MySQL.

davideads’s picture

davideads commented

Want me to test with PostgreSQL?

davideads’s picture

davideads commented
StatusFileSize
new 844910-views.dont-add-field-in-orderby.patch978 bytes

I'm in the midst of turning my project that depends on this patch into a buildable system with Drush make and realized the prior patch doesn't apply cleanly.

Here's a fixed version. I've been using this patch on a testing site (running MySQL) for the past five months without adverse effects. I tested on PostgreSQL back in August, and everything seemed fine but I haven't done additional testing since.

dawehner’s picture

dawehner
Primary language German
commented
Status: Needs work » Needs review

This seems to be like a reviewable patch.

In general the issue is still valid: http://drupal.org/node/844910#comment-3163046

joachim’s picture

joachim commented

http://en.wikipedia.org/wiki/Order_by says:

> The sort criteria do not have to be included in the result set.

The other problem is that:

> The SQL standard is not freely available. The whole standard may be purchased from the ISO as ISO/IEC 9075(1-4,9-11,13,14):2008. http://en.wikipedia.org/wiki/SQL:2008

I dunno about you but I'm not forking out for it!

joachim’s picture

joachim commented
Status: Needs review » Needs work

Patch works for me in that it fixes the problem. Yay!

Few things though...

+++ plugins/views_plugin_query_default.inc	Mon Jul 05 13:54:17 2010 -0500
@@ -801,16 +801,21 @@
+    // If there called without an alias, only add the field to the order-by clause.

That sentence needs fixing, not sure how.

I think the comments could go into a bit more detail about what being done and how. The deep innards of Views get quite complex!

Also I'm curious about this:

    if ($table && $alias) {

when we have this:

  function add_orderby($table, $field = NULL, $order = 'ASC', $alias = '', $params = array()) {

$table is not optional -- so surely $table will always be true?

Powered by Dreditor.

davideads’s picture

davideads commented

Joachim, thanks for the review. I frankly don't remember with respect to the $table variable -- I wrote the patch 11 months ago. But I'll check; most likely it was a brain fart on my part.

In terms of the the errant sentence, it should simply read "If called without an alias, only add the field to the order-by clause." For me, that seems like sufficient commenting within in the context of the function. Should it explain how otherwise the field is added to both the where clause and the order by clause?

joachim’s picture

joachim commented

I'm not sure what calling without an alias actually entails... though arguably that should be the job of the actual method's documentation to explain! Is it that you can either add a sort order on a field that is already present in the query (and thus has an alias) or a new one?

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Version: 6.x-3.x-dev » 8.x-3.x-dev
Issue tags: +VDC

There are still references to this in 8.x-3.x

xjm’s picture

xjm
she/her
Primary language English
commented
Project: Views (for Drupal 7) » Drupal core
Version: 8.x-3.x-dev » 8.x-dev
Component: Code » views.module
Issue tags: +Needs issue summary update

So there are references to something that we need to remove but it's still filed as a feature request. Can we update the summary explaining the current status? :)

joachim’s picture

joachim commented
Category: feature » bug
Issue tags: +Needs backport to D7

I understand the problem as it was filed and discussed on 6x3x but I don't know the state of the Views 8 code to write a summary.

This is definitely a bug though, because of #1819656: sort handlers don't know the alias of their query field which is really just another consequence of this.

dawehner’s picture

dawehner
Primary language German
commented 
I'm not sure what calling without an alias actually entails... though arguably that should be the job of the actual method's documentation to explain! Is it that you can either add a sort order on a field that is already present in the query (and thus has an alias) or a new one?

And it does :)

If an $alias isn't specified
* one will be generated for from the $field; however, if the
* $field is a formula, this alias will likely fail.

There is a public available draft of a previous sql standard, which is helpful: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

If ORDER BY is specified, then each in the
shall identify a column of T.

MySQL doesn't need this, and PostGRESQL (or however the capitals go) doesn't need it -- and it's total crack. It means that you can't order a subquery!

Are you sure this is true? Couldn't you just add the subquery to the result and then order by it?

joachim’s picture

joachim commented

A subquery that you use on a JOIN or a WHERE must select only one column. If you want to order by a different column, and that column must be selected, you're stuffed:

// Works:
SELECT * FROM outer WHERE outer.a = (SELECT inner.b FROM inner ORDER BY inner.c LIMIT 1)

// Fails, because the outer equality expression sees the wrong thing on the right of the =
SELECT * FROM outer WHERE outer.a = (SELECT inner.b, inner.c FROM inner ORDER BY inner.c LIMIT 1)

dawehner’s picture

dawehner
Primary language German
commented

Violating against the sql standard seems to be the wrong way to solve that problem, so i have no idea how to continue on this issue.

joachim’s picture

joachim commented

10)If ORDER BY is specified, then each in the
shall identify a column of T.

Unless I'm misreading it, that does not say the sort column must be in the SELECT part. It just says that the sort column must be a column of the table.

mitokens’s picture

mitokens commented
Issue summary: View changes
Parent issue: » #470258: Groupwise maximum ('representative') relationships

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

TLDNR: I want to order entities from an entity reference by the delta of the entity reference field but that leads to duplicate results because a further JOIN is added automatically which should not happen.

--

Hey all, thank you very much for this issue. I just ran into the problem of multiple results despite of active DISTINCT option because views adds a further join when an order by is added on a delta of an entity reference.

I found a module that provides a working workaround (https://www.drupal.org/project/views_order_by_delta) and opened an issue to find related core issues #3020585: Isn't this a core issue? because this should definitely be solved in core, I think.

Could someone from this issue perhaps have a look if this issue handles the same problem? Then we should try to revive it. Or is this a completely different problem? Thank you!

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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.

Version: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

acbramley’s picture

acbramley commented
Status: Needs work » Closed (outdated)
Issue tags: +Bug Smash Initiative

This issue came up in BSI triage. There hasn't been a comment here in almost 6 years. Because of this, I'm going to close this as outdated due to the time it has been since the last comment. It does seem like we still add a field in https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views... but only if one is passed in.

If anyone thinks this is still a bug that needs fixing, please feel free to reopen.