Problem/Motivation
Hi,
When I was still using Drupal 8.9, I used to have a view with 5000+ commerce products and product variations. I upgraded to Drupal 9.5.0, and this view is now broken : I can't use a table with aggregation unless I use a filter to reduce the number of items in the table in the first place.
When I change the display, it loads for a long time but the preview doesn't change, when I save the view, the preview disappears. If I try to load the page of the view, I get a 500 error.
Here is the error log on my server :
Backend fatal error: PHP Fatal error: Uncaught Error: Call to a member function get() on null in /home/pmsz0305/dev/core/lib/Drupal/Core/Session/SessionHandler.php:79\nStack trace:\n#0 /home/pmsz0305/dev/core/lib/Drupal/Core/Session/WriteSafeSessionHandler.php(95): Drupal\\Core\\Session\\SessionHandler->write()\n#1 /home/pmsz0305/dev/vendor/symfony/http-foundation/Session/Storage/Proxy/SessionHandlerProxy.php(73): Drupal\\Core\\Session\\WriteSafeSessionHandler->write()\n#2 [internal function]: Symfony\\Component\\HttpFoundation\\Session\\Storage\\Proxy\\SessionHandlerProxy->write()\n#3 [internal function]: session_write_close()\n#4 {main}\n thrown in /home/pmsz0305/dev/core/lib/Drupal/Core/Session/SessionHandler.php on line 79\n, referer: https://www.dev.sega-mag.com/admin/structure/views/view/essai_aggregator
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | views.view_._sm_liste_jeux.yml | 101.76 KB | shenron_segamag |
| #6 | Ajax_views_23-01-07.PNG | 2.56 KB | shenron_segamag |
| #3 | Ajax_views_23-01-02.PNG | 48.45 KB | shenron_segamag |
Comments
Comment #2
jordik commentedIt seems that the view generates the error, but the error description posted here does not give me any clues on why this is happening.
Is the view showing ok if you change the plugin to core Table? Do you see any Broken/missing handler on your view?
Comment #3
shenron_segamag commentedI pushed my research further :
- When I change to core table, the view and the page load just fine
- I don't see any missing handler on the view,
- The page loads just fine for anonymous users, but takes forever to load for logged in users
- When I try to edit and save the view, there seems to be an issue with Ajax, even though I disabled it for this view (see screenshot).
I'm sorry if I'm not accurate enough in my descriptions, I'm way out of my field. I would gladly provide more informations.
Comment #4
tr commentedIf you upgraded your PHP version when you upgraded Drupal, then this might be due to your PHP configuration settings. For example max_input_vars or something similar.
Comment #5
shenron_segamag commentedI'm gonna check this value but I had this issue with my initial PHP config.
Comment #6
shenron_segamag commentedSo, I changed the value of
max_input_varsto 30 000 (which seems ridiculous) and I still can process only half of the items in 30 seconds.I have the same 500 error with a different initiator.
The issue is the same with my former php config.
Comment #7
jordik commentedCould you please check, if the default sort in the view settings of your view is set and if yes - please set it to „none“.
Comment #8
jordik commentedAnd please upload the congig export of your view as .yml.
Comment #9
shenron_segamag commentedThe default sort is set to "none".
Here is the export of the view. The problematic page is page_1.
Comment #10
KimD1 commentedI've possibly got the same issue. I've got a content type with 16K nodes. I run into problems when I try to aggregate this using View Aggregator Plus. I get a 'failed to load resource : the server responded with a status of 500' error.
Its easiest to describe if I start from what happens if I aggregate using Drupal's core views module.
- Structure > Views > Add View
- Content of type My16KNodes
- Create a page
- Display format Table of Fields
- Items to display 100 <------------ the key field for this issue
- Then create my aggregated view on the Structure > Views > Title / Format / Fields page
The Items to Display controls the number of rows in the display of the aggregated view. I can aggregate 16K nodes, as long as the number of grouped rows in the resulting view doesn't exceed, in this example, 100.
Then I try to do exactly the same with Views Aggregator Plus, except that the Display Format is a Table with aggregation options. What's surprising is that VAP doesn't use the Items To Display (in my example 100) to control the number of rows in the output. Instead VAP uses the Items To Display to control the number of nodes that it accepts as inputs. VAP successfully takes the first 100 nodes of type My16KNodes, and aggregates those.
Put simply - Structure > Views > Add View > Items to display:
- on core aggregated Views, limits the rows output;
- on Views Aggregator Plus, limits the number of nodes input.
Because I want to use Views Aggregator Plus to display aggregated data describing my 16K nodes, I try the obvious thing and increase the Items To Display to 17000. When I do this, for both VAP and core Views, this results in an Ajax error ('failed to load resource : the server responded with a status of 500'). The error message is displayed when I press the Save and Edit button. The maximum value for Items To Display that I can enter without getting this error seems to be about 4000. Sometimes 4000 triggers the error, sometimes it doesn't.
Given that the error occurs for both VAP and core Views, I suspect that this isn't a bug in VAP. The issue with VAP is that it is using the Items to Display field in different way than core Views is, and this forces the user into situations where they are more likely to trigger the error. For core aggregated Views limiting the number of aggregated rows output to less than 4000 doesn't seem like much of a constraint, but for VAP limiting the number of nodes input to less than 4000 is a big constraint (for me anyway). I'm hoping that VAP can be changed so that it uses Items To Display in the same way that core View does, as a constraint on the output. If that was the case then I wouldn't need to set Items to Display to a high value, and therefore I wouldn't trigger the Ajax error that occurs when Items to Display is north of 4000.
Thanks BTW - VAP is a great module.
Views Aggregator Plus 2.0.2, Drupal 10.1.2, PHP 8.2.8