Hi,
I’ve recently switched off Classic Editor to start using Gutenberg + SO PB layout block, just to see how Gutenberg performs (spoiler: very badly, mostly because of its UI. Still cannot understand why some people think it’s even barely usable. They just had to copy from literally ANY page builder plugin – it wasn’t that hard to make something better from a usability perspective).
HOWEVER, Gutenberg is there and it seems it will be there, so then using G + SO PB doesn’t hurt my workflow too much.
Unfortunately, I’ve noticed that if a Layout Block is in the page, then I need to click “update” twice to see the changes: nothing gets saved on the first click.
If then I remove the Layout Block, using a Paragraph block for example, everything is saved upon the first click.
WP 5.3.1 / 5.3.2
Generatepress latest
All plugin latest
No caching
PHP 7.2
Hi Frafor
Thanks for your thoughtful feedback.
I haven’t been able to replicate the issue so far. If you have a moment, please, could you try checking for console errors after the first save, when the issue occurs.
Here is how to check for console errors https://wordpress.org/support/article/using-your-browser-to-diagnose-javascript-errors/#step-3-diagnosis. Scroll down to find your browser. If errors are present, please, screenshot, upload to imgur.com or your chosen site and send us the link. Thanks.
Hi Andrew,
I’ve looked further into the issue on a test environment (xampp + disables all plugin except SOPB & Widget Bundle & removed my own generatepress child theme).
You’re right that there’s no problem in creating new rows & widgets. Then I thought there was a problem in duplicating widgets, because I noticed fancy stuff happening with them.
I’ve even checked the console, but I didn’t find anything explanatory.
https://imgur.com/a/6ps6rJu
However, I later noticed that for each created/duplicated widget there’s an XHR request passing a nonce. These requests where fewer then the duplicates I was creating: if I saw 3 request, then only 3 widgets would appear.
So I started to click “Duplicate” waiting 3 seconds per-click. Or clicking Delete waiting 3 seconds per click: adding a wait time helped the frontend to look like my edit page.
At the end this is the issue: if you click “Duplicate” or “Delete” too fast (which is not really too fast in my opinion, I am just as fast as with the Classic Editor), then not all the new widgets are being saved, or deleted, even they appeare/disappear from the UI.
It’s harder to face this issue using in newly created widget/rows just because there’s more wait time between actions (doing “right click -> SO Editor” takes more seconds more than clicking “duplicate duplicate duplicate”).
BTW, sorry for the typos and HAPPY NEW YEAR! :)
Happy New Year to you too :) All the best for the year ahead.
Thanks for the additional testing and feedback. We’ll test locally and come back to you as soon as we’ve taken a look.
Hi Frafor,
I’m currently investigating this issue – thank you for your detailed reply! While I can see the requests you’re referring too, I’m having trouble replicating the outlined issue of having to click Update twice even when the requests are still being processed. Would it be possible for you to record a screencast of what it looks like when you have to click the Update button twice? Ideally, please include the entire process as it should help us replicate this. – adding/duplicating a widget and then attempting to save the page and having to press the update button twice.
We don’t currently support attachments but you can upload it to somewhere like WeTransfer or Google Drive.
Hi Alex,
I really appreciate your efforts in trying to replicate my issue. I’ve setup a clean install on localhost with just Generatepress + SOPB + SOWB, SOPB is setup as preview first, use classic editor unchecked.
It may be something going on with the XHR post request / answer on slow machines, since wamp/xampp on windows can be laggy, maybe nonce related. It’s like the POST request sent is sometimes behind the actual UI shown by the builder, but I do not know much on how gutenberg handles post updates.
Here’s the video:
https://www.youtube.com/watch?v=VuhX245ie8k
Test 1: created 5 copies for a total 6 widgets, displayed only 5 on frontend.
Test 2: deleted 4 widgets, still shows 4 widgets on frontend.
To replicate the issue, try to click “Update” shortly after duplicating the widgets. I’ve noticed that the wait time i was talking earlier is shorter on simple pages, however the issue still persist.
Hi Frafor,
Thank you for your detailed post and screencast. I’ve been able to replicate this issue by throttling the network speed of my connection to ensure requests took a very long time to process.
Hi Alex, happy with that, hope you’ll fix soon because on complex pages is sometimes very annoying :) I tried to setup xampp for better performance (even moved to FGCI, disabled xdebug) but it still happens.
Hi Frafor,
I’m sorry to hear that. Unfortunately, I don’t have any major recommendations for how to improve performance as I haven’t found anything on Windows that comes close to a proper server environment. It’s not ideal, but consider setting up a staging site with a hosting provider for those more advanced development projects/tests.
Does that mean you won’t fix?
Hi Frafor,
No, the issue you’ve highlighted has been logged with the development team and they’ll look into possible solutions.
My previous reply was in regards to your last comment about general poor performance when using Windows rather than the issue you highlighted.
Ok, good!
I usually work with online staging environments when I have to build pages (not code), but on early stages and/or particular cases (plugin development, testing, travelling in places where there’s no/slow connection), I still work on my pc first.
Anyway, thanks a lot as usual!
Hi Frafor,
Happy to help. Let us know if anything else comes up and we’ll lend a hand.