Hello!
I’ve found a potential bug with the new save feature that I wanted to ask about. I spent around an hour in the “Expanded Mode” of the “Site Origin CSS” Plugin, and when I attempted to use the new save feature to save my work, I received a popup from my Localhost install that said “the supplied nonce is invalid.” The same thing will happen if you leave the tab open to go work on something else for an extended period of time.
Since I could not save my work, I copied the few lines of code I had written over to my notes, then clicked the “Expanded Mode” button once more. After this, the code I had written was no longer there. Thankfully, I just pasted the code from my notes to the default Custom CSS menu, and clicked the “Save CSS” button at the top left. I have no problem as a result and know how to get around it in the future, but I thought it would be worth mentioning here.
I’m not too familiar with the term “nonce,”
Hi Evan
Thanks for taking the time to report your experience. Apologies for the hassle. I’ve asked our developer Alex to attend and update you once he’s taken a look.
Hi Evan
Thanks for the wait.
We’ve run a test for a few hours. At the moment we’re unable to replicate the issue.
A nonce is a “number used once” to help protect URLs and forms from certain types of misuse, malicious or otherwise. WordPress nonces aren’t numbers but are a hash made up of numbers and letters. Nor are they used only once, but have a limited “lifetime” after which they expire. During that time period, the same nonce will be generated for a given user in a given context. The nonce for that action will remain the same for that user until that nonce life cycle has completed.
Nonces “expire” after 24 hours, the session expires (closes the browser), or the user logs out. We’re unsure why the expiry happened while you were working. Apologies for the hassle. I’m glad you didn’t lose any work. We’ll continue to monitor for this issue.
Thanks for the reply, Andrew.
I think it might have something to do with WordPress’s login feature, and was not the fault of the plugin, though I was unaware of this at the time of posting.
My apologies.
No worries. Have you made progress?
First, I’d like to thank you for your quick responses, even though I’m not using a paid version of the plugin. Nobody else has been this helpful. I will recommend this in the future to others. Besides that though, yes, though I have run into another issue that’s preventing me from continuing towards the last few steps of finishing my site.
Whenever I try to load Woocommerce’s checkout page in the expanded visual editor, it does not allow me to view the page, and sets the editor on my “cart” page. I have set the URLs such that it’s …/wordpress/checkout, and …/wordpress/cart, so I am confident that I am plugging in the correct address. The same issue is prompted if I I have noticed that Google Chrome gives me the “not secure” message when I my local install’s checkout page, and I believe that might be the cause of the issue. My live site has SSL, whereas my local install does not, as I do not know how to implement it. I use XAMPP on windows. I prefer to work this way as I have easier access to files.
Here is a link to a clip I recorded of the issue, on google drive. It’s set so that anyone with the link may view it.
https://drive.google.com/file/d/1lr_pGZ-noUqZGe219L3YjYPYrRGlyUpv/view?usp=sharing
I’m a beginner CSS/HTML/PHP coder working as an intern. My knowledge is minimal, though I feel confident that I can understand most things said to me. If there seems to be a simple enough way to fix this with code, please let me know.
Thank you again, Andrew and Alex.
Hi Evan,
Thank you for the video. I’ve had a look over it and based not the results it’s very likely that this issue is linked to the page not being secure, and the WooCommere setting Force SSL setting. That setting should remain active so it’s not directly an issue. You’ll need to identify what isn’t secure about that page. The easiest way to do that is to check the browser developer network tools as it’ll that’ll allow you to identify any HTTP requests (which should be HTTPS).
I note that in your video that the inspector interface isn’t visible, and you’re not prompted to navigate to the standard method (click, and then additional click to confirm navigation – this is to allow you to style links) so it’s likely you’re facing JavaScript-related error.
Can you try disabling all non-SiteOrigin plugins and see if this fixes the issue? You’ll need to clear all your caches after disabling your plugins.
If it does fix the issue, then try re-enabling your plugins one by one until the issue comes back. This procedure will help diagnose which plugin is causing the issue.
Once we know that, we’ll be able to look at what might be causing the conflict and either solve the problem or help you find an alternative plugin.
You can also try temporarily switching to one of the default WordPress themes to see if the issue is theme related.
Kind regards,
Alex
1.) “Force Secure Checkout” was already checked, as I thought it might fix my issue before.
2.) Deactivating all plugins fixed the issue. (Except WooCommerce, as that’s what creates the Checkout page.) I will look into this further myself and find out what plugin caused the issue, and let you all know here. My use case is probably quite niche, as I’m using a custom theme that I strapped WooCommerce support onto early on, and I can’t be arsed to rebuild the site with a new one.
3.) You mention in your comment something referred to as the “inspector interface”… is that the feature in SiteOriginCSS that highlights the Divs? If that’s what you’re mentioning, then I’d like to add that it WAS FUNCTIONAL, just a bit sluggish, likely as a result of other plugins. My PC is decently fast, so I’m not particularly worried about that being the bottleneck on my local system. (I only mention this because of my Localhost/XAMPP install).
I made sure to take a backup via the duplicator plugin before doing any of this, so I’m not worried about losing progress. Thanks again for the help.
Hi Evan,
1. Sorry, I wasn’t clear. The Force Secure Checkout setting is intentionally causing the redirect. You should identify what is causing the insecure content (the browser network tab I mentioned will help with that) on that page and correct it.
2. Awesome. Let me know how you go. :)
3. The Inspector interface is a panel at the bottom of the preview. It gives you an overview of properties and suggested selectors. Here’s a screenshot.
Kind regards,
Alex
Hello,
I figured out part of the issue I was having. It was not plugin related, as I was able to turn all of the plugins back on without the editor breaking. I have found that caching is responsible, though I’m not sure what’s being cached that causes the issue. If I clear cache and cookies from the last 24 hours in Chrome, log back into my site, and then attempt to open said page in the expanded editor, it opens up with no issues.
Hi Evan,
It’s great to hear you were able to identify a solution. To confirm, is that in regards to the WooCommere Checkout or your initial nonce issue?
Kind regards,
Alex
Hi Alex,
The nonce issue never showed itself again after my initial post. The WooCommerce Checkout not loading in the editor was what I had fixed.
Thank you.
Hi Evan,
Awesome! :)
Let me know if this issue occurs and we’ll pick this back up. Please feel free to post a new thread if anything else comes up.
Kind regards,
Alex