Oh wow! Thank you so much. I will dig into whitelisting my own server because I really love that feature.
1 Like
Hi @Louis
Good question about the signhing. With local I need to manually trust the certificate in Keychain as per their knowledge base article. But Valet does it differently and when it issues a certificate it is trusted with no further action needed.
Cheers,
Mark
Thanks @MarkH.
Can I ask for one last favour 
If you don’t already have it, could you install and activate the Query Monitor plugin: Query Monitor – WordPress plugin | WordPress.org
Once activated, can you go to WordPress dashboard → Cwicly → Settings and let me know if you see any HTTP Call errors reported inside the Query Monitor.
Thanks in advance.
Hi @Louis
thanks for the Query Monitor suggestion, awesome tool. Looks like a cURL error, this is on the Valet install with the same errors on the Local install:
Now for some research.
Cheers,
Mark
These errors suggest that this is a setup/Gutenberg issue, much like the HTTP Auth and SSL issues mentioned above.
What’s basically happening is that Gutenberg requests all files loaded via the add_editor_style() function as HTTP calls (it has to process them to add a specific class).
At this time, we can’t do anything on our side unfortunately.
I am having the same exact problem as the folks above. I am not technical, so all the suggestions are way above my head.
I am on a iMac Ventura 13.0.1
Local WP version 6.6.0+6231
Felix
I just did a fresh install of Cwicly using version 1.2.8.7.1, and the menu worked as it should.
Really curious what’s the main cause.
Some people have issues, some not.
There are dozens of threads regarding this, but seems there is no proper solution.
It’s definitely not Cwicly related, but finding the issue would be a starting point at least.
I found the following post, maybe someone can get some useful info out of it:
Did you assign an ssl certificate and change the url to https inside the general settings?
I followed the instruction in Local WP to add make the URL trusted. No, I did not set the general settings to HTTPS; when I did change GS to HTTPS, the menu was revered to a vertical unordered list.
So I was not able to get it to work again. I give up. I will wait for the next update to see if the problem is fixed. I am still testing the app.
Well I’ve tried this on two different Macs using two different local environments - Laravel Valet and LocalWP. As soon as the https: is entered in the global settings the menu reverts to an unordered list.
I’m sorry @louis but I’ve spent hours trying to work this through and have not been able to find an actionable fix. With the header and menu appearing on every page I edit this makes Cwicly unusable for me. I’m not prepared to waste any more time so am giving up on Cwicly.
While I do understand @MarkH, the issue is clearly logged as: self-signed certificate. It is not a Cwicly issue.
We cannot do anything currently as Gutenberg is loading these assets through an HTTP call and parsing them afterwards.
Why can’t we parse them ourselves? Gutenberg gives no direct hook to insert elements in the iFrame, making it extremely difficult to keep up with.
Once again, it is not an issue directly related/caused by Cwicly.
Hi Louis do any of your technical wizards have any ideas as to how to resolve? While I’m technically competent I am not a developer. And as I said I’ve tried two different Macs and two different local environments. This is not an issue that I’m facing alone. Do you have any contacts in the Gutenberg community who may be able to help?
What comes to my mind (in your functions.php or with a code snippet plugin).
add_filter( 'https_ssl_verify', '__return_false' );
But this can and should only be used on a local environment.
Moving this to fixed as I’ve not received any further comments and the below should fix things if necessary.
2 Likes
Thank you so much for providing such a quick and easy workaround @Louis.
It’s working on my side and I’m very grateful there is finally a solution now, as a tool which prevents me from local development would be a massive letdown, even though Cwicly isn’t responsible for it.
Just one question.
Is there any drawback using this method?
As long as using https, there shouldn’t be any difference, right?
Especially in terms of migrating a finished site to a live environment, where of course the snippet needs to be removed.
Hi there @Marius,
Thanks for letting me know, I really do appreciate it.
No drawbacks to my knowledge with this method as long as used on a local environment. All it does is remove the verification of the SSL connection, which for cURL was causing this issue.
Most important as you have said is removing the snippet once on an installation that isn’t on a local environment/self-signed SSL.
1 Like
Thank you, Louis; your fix worked on Local WP.
Felix
1 Like
I just ran into this myself with Local on a Mac, Ventura and manually trusting a SSL cert. The above code worked for me (in functions.php). Thank you!
1 Like
@Louis Hi Louis, just want to thank you for the fix on this issue.
I had the exact same problem discussed in this thread and the code snippet you provided fixes the problem.
QUESTION: Is there a more permanent fix for this in the works?