onetrev

I too had the sample problem. It’s weird that …defaultConfig.entry(), worked when everywhere you are told use …getWebpackEntryPoints(), such as in this Github issue. If you don’t the cool automatic webpack globbing / searching for block.json files isn’t supposed to work any more. However, obviously some of us are finding the opposite to be the case. Very odd!

• This reply was modified 7 months ago by onetrev. Reason: Clarity

One quick workaround that I just found to be able to inspect your navigation block overlay is to do this:

• Open your Developer Tools and inspect the HTML
• Find the Event Listener for the modal (it’s the div right below the open menu button element)
• In that Event Listener uncheck the “focusout” event
• Once you do that if you then click the menu button it will stay open until you refresh/reload the page. Hooray!

Hey @mrtom414, I think what the OP @juliangk was asking for was a way to inspect the generated HTML & CSS with something like Firefox Developer Tools.

There has to be a way to keep the menu open so you can inspect it, in order to be able to adjust things like padding, margins, etc, in Developer Tools. That way you can see what the changes will look like in real time and then adjust the settings in your theme accordingly. This is common web dev practice.

I have the same issue though, I can’t keep the menu active no matter what I do, the menu closes as soon as you try to inspect any aspect of it. It’s very frustrating.

• This reply was modified 8 months ago by onetrev. Reason: Tag original poster

No worries on the delay. Thanks so much for fixing this so quickly since it was only a minor issue.

Hi Eugene,

No worries on the late response. Any response is better than none, especially with a totally free plugin like this one, I can’t really ask for more. ??

The site that shows the issue is now live, so the delay works well. The issue occurs on all pages with the Getwid accordion. The site uses the latest version of Getwid (1.8.7). This page shows the issue the best. On desktop, in Chrome or Firefox, scroll down to the second accordion item called “Proof is in the pudding“. If you click to expand it, your browser jumps down to the bottom of the page and you have to scroll back up to get to the top of the accordion content. If you stay on the page and close and expand it again though all is fine.

Let me know anything else I can do to help you reproduce this if this doesn’t help enough. Thanks!

Thank you. Yes, it’s fixed perfectly. Cheers.

Hi Gaurav,

The error is still occuring. Before we schedule a call to demo this issue I should have explained this error occurs only if the theme has widgitized areas registered. So if you do something like this you should be able to replicate the bug.

add_action( 'widgets_init', 'register_sidebars' );

function register_sidebars()
{
? register_sidebar(array(
? ? 'id' => 'footer-area',
? ? 'name' => 'Footer Area',
? ? 'description' => 'Website footer area.',
? ? 'before_widget' => '<div id="%1$s" class="widget ?%2$s">',
? ? 'after_widget' => '</div>',
? ? 'before_title' => '<h4 class="widgettitle">',
? ? 'after_title' => '</h4>',
? ));
}

Correct, Version 4.1. WP 6.1. Of course to see the Notice you have to have debug enabled in your config file. ??

define( 'WP_DEBUG', true );

Confirmed, the issues are fixed. Thank you!

I already did re-schedule. And no one showed up the second time. ?? We can try one last time I suppose. I set the meeting for:

6:30pm – 6:45pm, Wednesday, November 16, 2022 – Sydney, Melbourne Time

Hi thanks for the follow up! I scheduled a meeting that was supposed to be just now, but no one showed up. ?? Hopefully they do for the rescheduled one as I appreciated this offer which should really help demonstrate the issue quickly.

Nice find! I tried to track down the PHP 8.1 fixes in WP 6.1 core, but didn’t come across this one. The odd thing is I’ve been running WP 6.1-beta2, so perhaps it’s not merged yet? I can’t tell. It’s not obvious to me like it is with git. ??

Sadly no stack trace. Ya I didn’t think there would be cookies, so it is odd it chucks these warnings right? The only plugin active is this one. I triple checked. ?? If I switch back to PHP 8.0, all is good.

The entire warning message, which appears on the /wp-admin/plugins.php page and on the plugin settings page (/wp-admin/tools.php?page=wp-beta-tester) is:

Deprecated: Return type of Requests_Cookie_Jar::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Cookie/Jar.php on line 63 Deprecated: Return type of Requests_Cookie_Jar::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Cookie/Jar.php on line 73 Deprecated: Return type of Requests_Cookie_Jar::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Cookie/Jar.php on line 89 Deprecated: Return type of Requests_Cookie_Jar::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Cookie/Jar.php on line 102 Deprecated: Return type of Requests_Cookie_Jar::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Cookie/Jar.php on line 111 Deprecated: http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated in /app/wordpress/wp-includes/Requests/Transport/cURL.php on line 345 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 40 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 51 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 68 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 82 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /app/wordpress/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 91

No worries! In case anyone else is encountering this in the future, what you need to do is use columns.render (more details) instead of createdRow.

Awesome! Thank you so much. It works perfectly now. I wondered if that needed to be added to the “Custom Commands” section, but couldn’t any details about that. I should have experimented with dropping the extra DataTable() call, so you didn’t have to spend time replying.

One related query, happy to create a new topic for this if preferred, I noticed the added classes from the code don’t appear in data in “collapsed” area when using responsive=collapse. I’m guessing that’s just the way it has to be, but thought I would check. ??