whistlerdan

Awesome!

Ah, I see.

Yes, I was expecting it to be a dedicated search to show where the Synced Patterns were being used. That is what I hoped for. So I was expecting patterns to show in the scrolling list of Gutenberg blocks, possibly filterable using the drop-down that currently shows things like “core” etc.

Thanks for clarifying how it currently works. Maybe a future feature ??

• This reply was modified 4 months, 2 weeks ago by whistlerdan.

I don’t think you meant to give them five stars!

No. I have now submitted my info on Github where I found someone else had already reported this issue in the WordPress/Gutenberg section. Hopefully it’s a quick fix.

Most people won’t notice it because to trigger it, you need to go back and edit a post that was created before WP6.3, and there needs to be images in that post that had their size modified with the image handles.

• This reply was modified 1 year ago by whistlerdan.
• This reply was modified 1 year ago by whistlerdan.

Nevermind. I ran it again, and this time it found 3000+ issues which is much more in line with what I expected.

Okay, thanks for trying! At some point, they might have changed how they do things. This may only affect people who used very early versions of Divi. Yes, it does seem to have something to do with a built-in caching option. I just went through and deleted all keys beginning with _et_core, and that does solve the issue. Thanks again for taking a look!

Weird. It deletes them for me.

Great. Thank you.

I agree that this is a huge step backward. It’s one thing to hide it behind the dropdown for advanced options, but the fact that you can’t even get access to the advanced options until you have first added the link and then chosen to edit the link is maddening. Surely the point of hiding the options behind the advanced option was to tidy things up. Why tidy it up twice?

Oh, when I hover the mouse over the Pages item it does pop out a tree of pages.

I was specifically looking for the item shown in the screenshots as I expected that to be how the plug-in worked. I guess, mystery solved. The screenshots are out of date.

Thanks. I just tried this in Safari, and I still see some issues. It doesn’t always behave in the same way as Chrome, though. It’s more erratic. Sometimes it jumps a small amount, but still, sometimes, I see it jump to the bottom of the page just like it does in Chrome.

Regardless, I guess if you fix it in Chrome, it will fix it in Safari, so thanks for looking into it.

On your site, it looks like something happens when you try to insert the link because the scroll bar becomes active for a brief moment. On my test site, it is more visible because my content is longer. It scrolls right to the bottom of the page.

Did you try adding a lot more paragraphs? I think maybe if you added a couple of thousand words of text, it might exaggerate the issue more and you will see it clearly.

Here it is on my staging site running on 2023 default theme and only your plugin: https://capture.dropbox.com/pRpqZGtnzA1k2ReK

I’m happy to give yo a login to my staging site if you want to see it, but I’m not sure what is the safest way to do that on here.

• This reply was modified 2 years ago by whistlerdan.
• This reply was modified 2 years ago by whistlerdan.

Hi,

Yes, I have 3.10.12.

Your example test would not reproduce the issue. You need to create a page that has enough content on it to be scrolled.

On my staging site, I disabled all other plugins and installed the default 2023 theme, and I was still seeing the issue. I disabled caching on my server, cleared the browser cache, and tried Chrome and Safari. Same issue.

On your test site, can you please run the test again, but this time add a bunch of lorem ipsum paragraphs or something like that, and then try inserting a link somewhere in the top paragraph? I believe this might then reveal the issue. Thanks!

Not sure if it helped the OP, but it worked perfectly for me! Clearly shows a list of all posts and pages where a reusable block has been used.

Very helpful, thanks!