Plan for Views 7.x-3.23 release

Any reason why we couldn't get this one committed? Seems like a straightforward fix, unless there is a better way to resolve.

https://www.drupal.org/project/views/issues/2483055

I'd like to see #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback committed. It's been RTBC over a year now.

Apparently, this issue was fixed and then unfixed:

https://www.drupal.org/project/views/issues/1217394

I will see if I can produce a patch for version 3.20 and post in the above issue.

Can we get some of these RTBC committed?

#2834729: [META] Roadmap to stabilize Media Library is a great example of the Must-have / Should-have / Could-have / Done methodology.

The "must haves" are marked as children of this issue, see list on the right.

For me it's a bug/patch I'm running into on multiple different sites, or frequently crops up for new sites, then I'll add it to the list and push for commit.

If it's something edge-case, or hard to replicate, or can be worked-around, I'll let it lie until the more annoying issues get fixed.

I installed Views 7.x-3.20+12-dev and found no issues aside from a broken autocomplete field on an exposed filter, which is expected and related to #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback.

I tested a number of different exposed filters around my site and also confirmed a map display powered by Geolocation Views still work.

The patch from #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback no longer fixes my broken autocomplete field.

Lovely to see so many patches have been committed, I've added a few more low-hanging fruits.

@DamienMcKenna, I just noted that the v7.x-3.21 security release breaks on less than PHP 7.x. Will there be a security update for version of views that are still stuck on servers running PHP 5.x?

I just posted an issue in the queue.

Cheers,
Andrew

@DamienMcKenna, yes I have a client using php 5.3.x and this release introduces php 5.4.x array syntax []
instead of array()

+      // Clone the join for each table:
+      $this->handler->table_aliases = [];
+      foreach ($this->handler->value as $value) {
+        $join = $this->get_join();
+        if ($this->handler->operator == 'and') {
+          $join->type = 'INNER';
+        }
+        if (empty($join->extra)) {
+          $join->extra = [];
+        }
+        $join->extra[] = [
+          'field' => $this->handler->real_field,
+          'value' => $value,
+          'numeric' => !empty($this->handler->definition['numeric']),
+        ];

anyone have a patch for this yet?

ah yes there already is a patch
#3039953: PHP 5.3.x fix for syntax changes Views 3.21

@DamienMckenna adjust your views automated tests to trigger 'on commit' instead of every week. That would have caught this.

The current dev version is working fine for us. Over in #3039953: PHP 5.3.x fix for syntax changes Views 3.21 people also confirmed that it works again on PHP 5.3.

Since the security release broke existing sites we should ignore the remaining RTBC issues and instead release 3.22 immediately, right?

Since the security release broke existing sites we should ignore the remaining RTBC issues and instead release 3.22 immediately, right?

I agree, that we need a new release asap. However, there are apparently a number of regressions that have been introduced by the exposed filter security fix. Ideally, those should be investigated and fixed before a new release. It seems that there are a number of cases where a JOIN is missing from the query after the security fix, which will cause an empty where group and thus invalid sql. I guess we need to check if these are actually several other issues present in views and just exposed by the security fix or if the security fix did too much. We probably need input from someone on the security team here as well to make sure that any fixes do not render the security fix invalid in part or as a whole.

There is at least three issues in the issue queue marked as 7.x-3.21 regression that we might look closer at before tagging 7.x-3.22.

FYI: via simplytest.me I've created a sandbox reproducing the 3.21 regression issue 3040526 temporarily available here: breaking view.

Remark: no exposed filter involved.

I've played around in the above sandbox on simplytest.me and observed the following:

Combining two filters based on the same taxonomy term and using "is none of" or "is all of" causes the SQL error. When one of these is replaced by another operator, the error disappears. Also when using different terms from the taxonomy the error disappears.

By the way: using the 'same' filter typically happens when using filter groups and repeating some filter components (this was my original case). These observations may indicate that the different 3.21 regression issues (at least 6 issues) and the different ways these were reported over time, may be very related, possibly sharing the same root cause.

@damienmckenna I just added #3040497: [Regression] Missing JOIN in attached display with taxonomy filter and inherited exposed filter as an other child issue, since I think you missed that one when adding all the regressions as child issues. I hope that's ok.

Wish security issues would become public after they've been patched, makes it very difficult for those dealing with the fallout to have any idea of what was done and why with no details or context.

There are three issues which need tests, and then three new issues which need a) reviewing to see if they still exist after the other commits, b) patches & possible test coverage. We're getting there.

It's not clear to me what issues those are, if I may make a request, can we list in the description what needs to happen before the release?

So as to make it easy to find out, in case someone wants to chip in to get this out earlier :)

Hello Damien.

I tested views-7.x-3.x-dev and found fix for "SQLSTATE[HY000]: General error: 1116 Too many tables" with filter for field of relation issue is not included.

I'm very happy if fix for this issue is in 7.x-3.23.

Thank you for great module!

Hi all,

I currently did patch rerolling for 50+ Views 7.x issues and want to continue that work constantly. So, if you like my work, please mark all patches needed to reroll as 'Needs reroll' and comment last patch like Chris Matthews does here: https://www.drupal.org/project/views/issues/1603664#comment-12928087
'Patch' link to last patch greatly helps me every time. Thank you!

@Andrew Answer

I saw all your rerolls, very awesome!

Thanks Damien for squeezing those last two in, also for having some time to give Views some much needed attention of late.

@DamienMcKenna++