🇺🇸United States @redeight

This issue, while similar in error message to the one you claim this duplicates, deals with a completely separate method type signature. Per your comment in other issues, since my error pertains to a separate method, the fix in that issue will not correct this one so I've created a separate issue to deal with this specific one.

TR Said to post this here. Even though its a completely different method, the error is VERY similar.

I'm not entirely sure what is happening here but I had a view that was working previously and after an update to one module or another (this, maybe webforms, unknown) it stopped working.

The error is TypeError: Drupal\views_aggregator\Plugin\views\style\Table::renderNewWebformValue(): Argument #2 ($row_num) must be of type int, null given. called in .../views_aggregator/src/Plugin/views/style/Table.php on line 902 which occurs inside the elseif ($this->isWebformNumeric($field_handler)) { branch.

Looking at the code, I can see that the second argument of renderNewValue is ?int $row_num and nothing changes $row_num before line 902 which means that $row_num is an int or null. Then in the function definition for renderNewWebformValue, the argument that receives the $row_num is defined as int $row_num. The first line of the method actually checks if $row_num isset which means a null would be handled correctly anyways... Changing the type of this argument to ?int $row_num should be handled correctly and prevent the possible type error.

However, upon making that change, I ran into the next issue with my view. When $row_num is null, my $new_value is now apparently a float instead of an array, which causes an error on argument #3... :p

The change I made that appears to fix BOTH issues is to only call $this->renderNewWebformValue if $new_value is an array, otherwise I just set $rendered_values[] to $new_value and move on...

The line now looks like $rendered_values[] = is_array($new_value) ? $this->renderNewWebformValue($field_handler, $row_num, $new_value, $separator) : $new_value; and that fixes it.

Because this happens in the "isWebformNumeric" branch, I suspect something changed in webforms or there was an edge case on the webform numeric fields that wasn't caught before.

redeight → created an issue.

I can confirm that this does indeed work well. In addition, by moving the hoverintent to a drupal behavior instead of $(document).ready it fixes another issue I've been seeing on some of my sites where hoverintent failed to work at all.

For those looking for a quick fix using a generated subtheme:

1. Replace function HOOK_library_info_build() { with function HOOK_library_info_alter(&$libraries, $extension) {.
2. Remove the line that says $libraries = [];
3. Remove the line that says return $libraries;

That should get your layout and extension libraries working again.

Unfortunately, this change will likely need to be rolled manually by everyone currently using any subtheme generated prior to us fixing this since those subthemes will use the incorrect hook.

redeight → created an issue.

I'm facing this issue right now. Multiple field settings > Display all values in the same row, which is how I would fix this with any other field, is not working as expected.

Event is a two day event. Mon 1-4PM, Tue 1-2PM. The event's smart date field has two entries.

In the view, with "Display all values in the same row" set, it shows both dates+times in two rows... Both rows show the exact same thing.
Unchecking it results in two rows, first with Mon 1-4PM, the second with Tue 1-2PM.

The second is correct behavior, but not useful for my specific use case: listing events people can register for, and you cant register for just one day.
The first behavior is incorrect. And checking Distinct in the query settings doesn't fix it. How do I fix this?

I've been trying to figure out this issue for a while now. I have confirmed that uninstalling Metatag fixes the issue I was having.

On to the weird.... I'm running some custom code that loads and modifies webform submissions. In my case, with metatag installed, it gets stuck in an infinite foreach loop.

Specifically on webform (version 6.2.9) /src/WebformSubmissionStorage.php line 1438.

foreach ($submissions_data as $sid => $submission_data) {

$submissions_data is an array and in my case only contains one element (a single webform submission's data). stepping through, it goes all the way through the interior of the foreach loop, then ends up back on the foreach line and sets $sid and $submission_data to the exact same values as last time, jumps into the interior and works through setting values that were already set. It does this without end until PHP runs out of memory or throws an exception for calling too many functions or something like that. In debugging I was able to set a breakpoint and forcibly set the $submissions_data array to be null after it ran through a couple times and that causes it to finally leave the foreach loop. Everything else then proceeds as expected.

Uninstalling the metatag module and running through the debugging breakpoint again hits the same foreach loop but DOESN'T get stuck....

I'm so far beyond my ability to understand what is happening here. If there is any information I can give that might help either Metatag or Webform developers fix this issue, I'm more than willing to keep plugging on this issue.

My assumption is that the multiple applies is probably due to BigPipe and how that loads the site elements.

We updated a bunch of sites to 10.3.0 and then 10.3.1. We've only noticed this issue on one of those sites... 

We did have the duplicate menu items in that menu. I suspect they are from a migration we did, though I could be mistaken. They appear to be custom menu items that essentially replicate the system items. Deleting the "custom" menu items then allows the missing menu items to reappear in the toolbar AND the access issue to resolve itself. 

I'm now trying to rearrange the menu to the usual order and having a heck of a time since something seems to be fighting me on the weights. Rearranging with the drag and drop doesnt save. Manually editing the menu item and hardcoding a weight just has that weight reset to 0. Did 10.3 break menu weights or enforce some sort of alphabetical menu on the Management Menu?

Thank you!

Yes exactly! I forgot to mention that it was in the List display.

redeight → created an issue.

Remove requirement for "drupal/adaptivetheme": "^6.1". composer will get the correct adaptivetheme when you require "drupal/at_tool": "^3.1",

janc48, I'm not able to replicate it myself since I can't see a responsive menu on your site. The way I found the issue was to watch the classes on the menu via your browser's inspector when clicking the toggle. If you see a flash of change when the class gets added then immediately removed, it is likely due to this issue. You can also try applying the patch or checking out the merge request branch (whichever is easier for you) and seeing if that fixes it.

RedEight → created an issue.

Is there something else that was supposed to populate that call to render with the $results it was expecting? Did Drupal change something so it no longer does that?

So, I believe the issue is that StylePluginBase->render() doesn't take any parameters, but StyledGoogleMapsStyle->render is defined as public function render($results = []) and nothing passes anything to that $results. Adding $results = $this->view->result; as the first line of StyledGoogleMapsStyle->render suddenly fixes the issue. Which makes sense. The render function has access to the result directly from itself, no reason to pass in another array entirely.

As hudri said, the patch fixes an issue we're having with using these options on our sites.

I can definitely confirm all of this.

My apologies. Running the update after installing 4.1 was what I was missing. It's now showing bigint. Thanks!

The date and enddate are stored as INT after installation, but duration is stored as bigint. Is there any reason we aren't storing the start and end as bigint?

I've had this issue cause an error on two of my sites with thousands of media items and the error message is so unhelpful (http 500 error with ajax) it took me hours to realize what was happening the first time. I'd suggest adding pagination to the default view as that fixes it, though slightly less elegantly than the suggested workaround. But at least it doesn't require installation of another module or a dependency on that module from this one.

This works great!

Honestly, I've used this so much I'm gonna mark it as tested. Would love to see a tagged release with d10 set as supported

I've added an accessCheck(TRUE) to both /src/Form/FeeForm.php and /src/FeeListBuilder.php.

There are also queries executed in the /commerce_fee.post_update.php. Do we need to add this there as well?

RedEight → created an issue.

I tried installing installing this on a d10 site but ran into some issues. I think it might be because the composer.json file specifies "drupal/core": ">=9.3" when it should probably have a similar wildcard to the info.yml file. Thoughts on how to get this installed on a d10 site?

Not sure if it is related, but checking the "Expand all menu links" option in the block configuration doesn't even stick when saving. I checked the configuration for the block itself and that value is set to "FALSE" even when I just saved it turned on.

I've been using this to build out a site on D10 and it works great. Would love to see this released for d10 officially.

Any word on tagging a release as 10 supported so we can install with composer?

Any chance we could get a release with this so it can be installed via composer on d10 sites?

Patch seems correct.