I’m running into a strange problem updating an html widget on our new virtual class resources page on our website. The widget updates fine, except for Tuesday class data.
This has happened for both Tuesday, April 14th and Tuesday April 21st now. I can create collapsibles, but the data in the “content” area simply won’t update from the dummy “content” text that I put there to hold the space while I pull data from teachers’ submissions. Wednesday, April 15th and Wednesday April 22nd class updates (edits made on Thursday mornings) ran just fine.
I can copy and paste the html from this widget into an html widget on another page, and it updates fine with Tuesday data, but when I hit update on the original page, it reverts each time.
I have: 1.) cleared local cache, 2.) cleared cached data from WP Super Cache widget and cleared local cache, 3.) disabled VaultPress and WP Super Cache widgets and cleared local cache
I have not yet disabled or cleared: Akismet Anti-Spam, Classic Editor, Jetpack by WordPress.com, Loginizer
Any other ideas? I’m at my wits’ end.
Hi Lconway
Thanks for reaching out.
Please, send a link to the page concerned and send the contents of the HTML widget here or via PasteBin.com so we can take a look.
Unfortunately, it's not just the html widget any longer. Multiple widgets are having this issue, where I will perform updates, they will appear either in the live editor or in the "edit page" view, and upon hitting
"update" they revert to the previous iteration. Site is:
ashleyballetarts.com
Page in question is ashleyballetarts.com/virtual-class-resources, which is behind a password due to proprietary information which our paying clients have access to (not terribly secure, but stops general hacking/unpaid access of our class materials during this time)
code here: https://u12582751.ct.sendgrid.net/ls/click?upn=3-2F9pCZRSnYcH3qy2Eh8CgoLRFKlRufmb6o0owJXTswnHKiMsmKq-2Bj1UN0vucF3dEEArD_Bns8o9nfgVCXQ9-2B-2FUu2oziiKwQK-2BszlkIish0-2FcrlGyQacYJ65-2B38pEKduMbO37xvz1bWDw-2Bns78vuxyA6-2Bhi1-2FrU1VYINjgWlfnZp77-2FdgJgHggoPVHquwLKzv3urZ69pIbnk1Lf7pv85c681TDg3O1KewGJvE3hYqVun9T4rxVxvI6zFlSOxf-2FBVwzKfr-2FLbpZgfA4mXCTi8SiLJHcTcp-2BMNAju1zH0AbGpT4pbAgZXIodBkIFSjbXKFeP2-2BWq-2FQLjQG2qXgysHOh7Cp0f4kbOqeVU-2FR1uoAXP8HaIWMo-3D
This is the first section of the code – we have other <div> for other levels. Part of the issue is the massive amount of data we are dealing with at this time due to the necessity of creating remote learning materials
Thanks
Let’s focus on the general issue then. If you can replicate the problem, that would be ideal. Especially if it’s on a test page that will allow you to edit and test without disturbing normal content.
When the issue occurs, assuming you can recreate it, please, check for JS errors, here is how https://wordpress.org/support/article/using-your-browser-to-diagnose-javascript-errors/#step-3-diagnosis. If errors are present in red, screenshot, upload to imgur.com or similar and send us the link.
I don't believe it is a JS error. This occurs in widgets with and without
JS, and the interactibles themselves still function, they just have old content in the dropdowns, or new buttons simply don't appear and the whole thing reverts to a prior version with fewer buttons.
Checked for JS errors, none appear
Thanks for the feedback.
Any plugin could be throwing a JS in the WordPress admin so it’s a good idea to check regardless of whether the widget in use makes use of JS.
The next test you can try running is a plugin conflict test. Temporarily deactivate all plugins not authored by SiteOrigin and replicate the issue. In this state, does the issue persist?
Yes, the issue persists. I have also confirmed with out web host that there is nothing causing an issue with caching on the server side in the background.
Thanks for your feedback :)
To confirm, when you checked for JavaScript errors you edited the page in question, recreated the issue by editing a widget, the issue occurred and then you checked for console errors?
To confirm, when doing the plugin conflict test, you deactivated all plugins not authored by SiteOrigin? Sometimes users run this test but selectively deactivate plugins, to confirm, every single plugin was deactivated except for Page Builder and the Widgets Bundle? Once that was done, you edited the page in question, recreated the issue, and the issue continued to occur, is that correct?
If the above is all correct, please, take several screenshots of the issue occurring, upload those to imgur.com or a similar site and send us the link so we can get a better picture of the issue. Thanks :)
Confirmed. Page edited, issue recreated, no console errors.
Every single non-SiteOrigin widget has been disabled. The only enabled plugins are: Page Builder by SiteOrigin, SiteOrigin CSS, SiteOrigin Widgets
Bundle. I have since re-enabled WordPress Classic Editor. This makes no difference in the issue.
Images here: https://u12582751.ct.sendgrid.net/ls/click?upn=3-2F9pCZRSnYcH3qy2Eh8CgqMeRTG-2BDfI54tjipCmN13-2Bc2FHGmRbW4JsJ-2Bba-2Bm-2F-2F-2BMlPe_Bns8o9nfgVCXQ9-2B-2FUu2oziiKwQK-2BszlkIish0-2FcrlGyQacYJ65-2B38pEKduMbO37xvz1bWDw-2Bns78vuxyA6-2Bhi1-2FrU1VYINjgWlfnZp77-2FdhZPYNB6XSapBLyJ9bA-2Bpdr-2FFNvD6cFiDUOLz36TQfSbYcUrpS88-2FnajtzNJz6M2bl3fP8jMZGhRLg46d6NZpNQH6DRbCic3fPYXHZIxZzsxqbFCfEkFtgLbPzllEib9y24Ul677tMiz0VsC7lGT3LoEpwJSE16LZvf3KcRF3wZaz-2Bshb977KGuArAPlEeMoyQ-3D
Several minutes later, this error message popped up (while I was creating
Imgur account/uploading screenshots) on the window the I had used to edit/update the web page: "Failed to load resource: The network connection was lost." I tried editing/updating again, and this message has not popped up again, though the issue persists.
Thanks :)
Try installing https://wordpress.org/plugins/server-ip-memory-usage/ and let us know what your PHP and WordPress memory limit is and what percentage is being used.
Memory: 28 of 128 MB (22%) | WP LIMIT: 40 MB
Thanks.
Do you perhaps have the technical background to edit your WordPress wp-config.php file? If so, it would be helpful to do two things:
1. Enable debug and debug log:
https://www.wpbeginner.com/wp-tutorials/how-to-set-up-wordpress-error-logs-in-wp-config/
You’ll then be able to check if there are any useful PHP errors printing to your error log file.
2. It would be useful to set your PHP memory to 256MB, here is how that’s done:
https://www.wpbeginner.com/wp-tutorials/fix-wordpress-memory-exhausted-error-increase-php-memory/
I don't specifically have experience in this, but I have the site fully backed up, and it wasn't hard to figure out.
Errors thrown: Notice: Undefined offset: 0 in
/home/ashleyba/public_html/wp-content/plugins/so-widgets-bundle/base/inc/lib/Less/Parser.php on line 1927
I have not yet set the PHP memory to 256MB if that makes a difference.
Further pertinent data:
The issue has not yet appeared when using WordPress.org's "Health
Check & Troubleshooting" widget – meaning that the issue has not yet occurred with SiteOrigin's widgets disabled.
Thanks for the update. We have the notice logged as a bug. Although not ideal, it isn’t an error, just a notice to the developers basically.
Please, try raising PHP memory to 256M. It’s very similar to the debug constants you’ve added to wp-config.php and ideally, should be done regardless of this problem.
Via Health Check, did you leave Page Builder activated but deactivated the Widgets Bundle?
I raised our PHP memory to 256M, and our web host then raised it to 512M for us. The issue persists.
I will be trying various combinations of PageBuilder/Widget Bundle/etc.
when I have time today. The issue consistently occurs when:
1.) A series of "smaller" edits are performed – somewhere between 1-3
SiteOrigin Accordion collapsibles or html/JS collapsibles added to the web page, or with content added within the collapsible; multiplied by 3-6 edits.
2.) One "large" edit is performed – around 6-10 SiteOrigin Accordion collapsibles or html/JS collapsibles added to the web page, or with content added within the collapsible.
Other notes:
Links are not showing up as "clickable" within the SiteOrigin Accordion widgets.
One of the strangest things: I have the html widget's code saved locally,
updated with class data for Tuesday, April 14th and Tuesday, April 21st.
Regardless clearing local cache and confirming with our web host that our website has nothing on the back end that would interfere with caching/updates arriving/overwriting files/etc., this Tuesday class data will not show up on the original page. It shows up as "content," the dummy data I was using as I added the html widgets. New collapsibles cannot be added within this html either, but collapsibles can be deleted. Locally saved html, with new content and new collapsibles, is copied, pasted, page is updated, and the old version shows. This can happen immediately after clearing local cache. It also appears to happen on new pages, if I have edited/accessed that original page, and haven't cleared local cache, but doesn't happen on new pages when I have cleared local cache (i.e. the new data in the collapsibles, and new collapsibles, will show up on the new page if I have recently cleared local cache, but clearning local cache has no effect on their appearance or lack thereof on the original page). This is one of the things that had me convinced that it was a server-side caching issue, but our web host swears there isn't anything on their end that would be causing this – they were able to recreate the issue, but weren't able to locate anywhere on their end that it might have come from.
I was using SiteOrigin Accordion from the widget bundle to attempt to work around this issue, since I figured there might be something wrong with my code, but new SiteOrigin Accordion widgets/collapsibles case to show up after a time.
Update: I was able to trigger the issue while using PageBuilder and the html widget from WordPress. I have not yet been able to trigger the issue using the Widget Bundle in WordPress's default editor, or WordPress's html widget in the default editor.
Thanks.
Would it be possible for you to create a temporary admin account for us so we can log in and take a look? You can create the account with the following email address:
Private Snippet
Just navigate to UsersAdd New in your WordPress admin. Enter siteorigin for the username and Private Snippet for the email address. Make sure you’ve selected Administrator for the role and enabled the Send Password field so we receive the details.
Once we’re finished taking a look, you can delete this account. We’ll let you know when to do that.
Please, also provide us with a before and after example edit that triggered the issue. PasteBin is an easy place to do that, thanks.
Done. Please let me know if you have any issues receiving it.
Note that "Virtual Class Resources" is the current, live page on our website. "Virtual Class Resources Draft" is throwing the same errors,
and is my current page for playing around with this issue.
Thanks, please, also provide us with a before and after example edit that triggered the issue. PasteBin is an easy place to do that.
This is a private message.
This is a private message.
The page in question is very large. Have you considered breaking this content up into smaller pages? At this point, this is just an observation, there are a few potential issues that are introduced by creating a page this large such as server timeouts.
You can copy/paste widgets or rows in Page Builder by right-clicking. My initial recommendation is to create a new test page with a single class like Modern Classes. That’s a big page on its own. Does the issue persist if create a test page with a single class?
I'm able to fit the Pre-Ballet classes onto a single page just barely, but
Junior Ballet is too large. I'm thinking that the long-term solution will be to split off into separate levels. This project has been growing and growing since the COVID-19 pandemic first forced us to close our doors to the public.
I am familiar with the ability to copy and paste rows and widgets. I was thrilled when PageBuilder added this capability, because it has allowed me to much more easily save data from prior years (e.g. on our weekly-updated performance page for cast members) and re-use in subsequent production years.
We have some other data-heavy pages on the site (e.g. the School Year
Schedule pages) where keeping the information together on one page keeps things much more readily accessible for clients – it's also why I prefer using a fairly stripped down group of plugins, etc.
With this in mind, I've been creating new pages, and having a hard time getting them to stick with PageBuilder as the default editor. Pages can be created in PageBuilder, but when I hit "update" they frequently revert to
Classic Editor, which loses the columns and nice divisions for linked pdfs at the top of the page.
My guess is that the issues could be related to
php_value max_execution_timeandmax_execution_time. You could chat with your hosts about increasing those but this is likely to still be a challenge with really big pages. Pages broken into smaller sections will also be easier for users to navigate and digest so there is an upside on that front.I tried to recreate the Page Builder issue you’ve described now and couldn’t. If there are specific steps I can take, please, let me know.
On the Virtual Class Resources Draft page, try adding titles and a few paragraphs to each of 4-6 accordion sections. This usually triggers it for me.
Thanks. It’s likely that the two issues are the same, both relating to the size of the page and the time it takes to process the page when saving. If either issue persists with smaller size pages, please, let us know.
I'm in the process of transferring our data to smaller pages, and still running into this issue. The issue is consistently showing up on pages with
2 SiteOrigin Editor widgets with 1-2 paragraphs each, and 2-3 SiteOrigin
Accordion widgets with 2-4 sections each. The issue is occurring even when only one Accordion section is added at a time.
I can again consistently trigger the issue using Troubleshooting mode when
PageBuilder plugin is active, but not when just the Widgets Bundle plugin is active.
Thanks for the update.
How are you testing the issue when Page Builder is deactivated? When I checked, the page was managed in Page Builder.
Please, try reaching out to your hosts and ask if they can try increasing PHP max execution time to 60 to see if that helps:
max_execution_time = 60I'm using WordPress's Health Check & Troubleshooting plugin, which opens a troubleshooting session where plugins can be disabled and a default theme
(WordPress's Twenty Twenty theme) is activated. I of course don't want to disable PageBuilder in a real session, since this is how 99% of our site is built and it would drastically affect functionality.
Request sent re: php execution time. I will update when I hear back and can experiment with it again.
Thanks for the update.
In the meantime, if possible, please, send us an export of one of the new smaller pages causing this issue. In Page Builder go to LayoutsImport/ExportDownload Layout. Next, upload. the JSON file to WeTranfer.com or the cloud site of your choosing and send us the link. Thanks.
This is a private message.
.json file shared with the email address listed above.
With PHP max execution time increased to 3000 (requested increase to 60,
our web host increased way above and beyond that for troubleshooting purposes) the issue still exists.
Thanks. Does the issue persist on a test page if you remove the Custom HTML widget?
Yes, the issue persists
This is a private message.
I have not been able to trigger the issue on the test page. Interestingly,
it take noticeably longer for the page to update on the test site. When the error occurs on our site, it takes less than a second for the page to
"update" to the older version. When I update the test site, it takes perhaps 1-1.5 seconds for the page to update.
On your site, try opening the browser console as follows https://wordpress.org/support/article/using-your-browser-to-diagnose-javascript-errors/#step-3-diagnosis, click the Network tab and then recreate the issue. Are there any error codes in the Status column, they should be in red. Please, screenshot and upload to imgur.com or any similar site if there are. Thanks.
I don't see any errors appear (everything is status 200), and the list of revisions in the post.php file contains at the top the most recent revision, with the class data that is missing after the "update" is completed.
Thanks.
If possible, please, make a brief screencast of the issue occurring on your site, I’ll show it to Alex here at SiteOrigin and we’ll try to advise further. If you’re using a Mac, QuickTime is a default app that can record screencasts. I’m not sure what the default is on Windows.
We are currently running PHP version 7.1.33 – would updating to the latest stable version help with this?
The team uses an array of PHP versions. I have 7.4.2 and 7.3.9 on my local laptop server. The demo site server is running 7.0.33. I don’t think that’s related but you’re welcome to move up to PHP 7.3+ or the latest stable version.
If you’re able to take a screencast of the issue as it occurs, upload it and send us a link, I’ll get a second opinion, hopefully, other ideas I haven’t yet thought of.
While testing screencast, the following error message appeared:
https://u12582751.ct.sendgrid.net/ls/click?upn=3-2F9pCZRSnYcH3qy2Eh8Cgi-2Bhoepvqf089Ol8ClzxcjZfyygpk-2BMh-2FpDCkjORQxVJgyLW_Bns8o9nfgVCXQ9-2B-2FUu2oziiKwQK-2BszlkIish0-2FcrlGyQacYJ65-2B38pEKduMbO37xvz1bWDw-2Bns78vuxyA6-2Bhi1-2FrU1VYINjgWlfnZp77-2FdgaFmYa5PsM1Ol4o0Jq1OFZxJo1opyWZbIvK5r9HnteytXPC2n3RKYLRUnWctGrvRv1DoYf59FDKOf5LLavzv7cCWz4XMYRQQXI31MFu-2BM1ErQxfyHjrkg6vr-2FFwWPR-2FI-2B-2FZc5AzT6PaCabUIltGPChrMNlCC6BsZse6OgGtIBQBSSEvcRtMLzM69QPKSuZDOc-3D
Please, reach out to your hosts about that, they should be able to assist.
This is a private message.
I have emailed a screencast to the email listed above.
Thanks, the admin-ajax blocking is a possible cause. Please, let us know what your hosts say. Hopefully, they can assist.
I have a message in to them. Weirdly, this error only appears occasionally,
even when the issue happens consistently. I will keep you posted. Thank you so much for all of your help to try to figure this out!
Web host has updated permissions and checked on the admin-ajax issue, and yet the issue persists. I can consistently trigger it on any page of the website, new or old. New error messages show admin-ajax issues persist, and an odd XSS auditor error.
https://imgur.com/a/dyGyqHt
We just released our new 2020-2021 School Year Schedule on May 1, and that page can be edited. It has a fairly large volume of data on it (class schedule tables, etc. with lots of pictures/formatting) but I haven't yet triggered the issue on that page. I have not yet tried adding collapsibles or accordion widgets to it since it's too important to keep it functional and I don't want to mess with it, but it's interesting/odd.
Thanks for the update.
Ideas from the team at this stage are:
* Try repeating the issue using a different browser. If you’re using Chrome, try Firefox, see if the same issue persists. (Opening the browser console to look at the Network tab etc. is almost the same process in all major browsers.)
* Ask your hosts what value is set for
post_max_size. If it’s possible to increase that value, please, ask them to do so.* Try going to SettingsPage BuilderContent and disabling Copy Content which will reduce the page size.
Hi, have you made progress?