Apologies for that.
Nothing is lost or modified, unfortunately the :root rule is not being parsed correctly under the new scheme. We’ll have a fix tomorrow 
Cool!
Is this normal that when SCSS code is invalid, JS errors are thrown in the console and not caught?
And I have another issue with stylesheet beautifier:
It happens when beautifying the following long line (here it is wrapped by editor):
Which becomes:
The problem is that it seems the line break at “+” in the second parameter (calc…) adds some weird escaped symbols (probably the line break itself) in the generated code:
Unfortunately the planned update for today has taken a bit more time than planned and will be pushed later on.
Apologies for the inconvenience.
Can we safely downgrade to 1.2.9.2.2 in the meantime?
All my font, spacings, colors, cards, overlays, button styles, etc, depend on variables…
It’s been two days I fell like working in a text editor 
Hi @yankiara,
My apologies for the inconvenience, this was unfortunate timing and should not happen again.
This should be addressed in 1.2.9.3.
In most cases, downgrading is considered safe.
1 Like
Hello @yankiara,
Just returning to this as I can’t reproduce this on my side. Is this still happening?
Also, the editor wrapping feature does not affect the code that is used for beautifying.
Could you possibly send me this specific snippet so I can test it out on my end?
Cheers
Hi @Louis,
I actually don’t use beautifier any longer for other reasons like this:
Unless we can change this kind of behaviour, I prefer staying manual for now 
That said, issue does not come from the beautifier itself, since I could reproduce it with just manually adding a line break.
And better, trying to reduce the mentionned issue scope, I finally found out that it is probably a wrong use of #{} that was the culprit (so, me!).
@function functestbeautify2() {
@return calc(
2 +
2
);
}
@function functestbeautify() {
@return #{functestbeautify2()};
}
@mixin testbeautify {
--test-beautifier-issue: #{functestbeautify()};
}
root {
@include testbeautify;
}
This produces this wrong CSS:
root{--test-beautifier-issue:calc(2 +\d \a 2)}
If I change @return #{functestbeautify2()}; to @return functestbeautify2();, generated CSS is OK.
So first thing, I think I shouldn’t have used #{} here since internal function return value does not have to be “SCSS evaluated”.
Second, and this is only supposition, if the #{} syntax is valid here (despite that it is useless), maybe the SCSS parser is a bit mislead by the line break…
In conclusion, the issue, if it really exists, is absolutely not from Cwicly, and I’m not even sure it is a real problem because the used syntax might never be used
Hello @yankiara,
I really appreciate you taking the time to put this all down.
I get your point about the beautifier. We’re currently using Prettier which is opinionated, but that does format things in a predictable manner.
Thanks for confirming the issue with the line break. I was able to confirm it on my side as well inside the function.
The safest option here would seem to be removing line-breaks for SCSS compilation, which we’ll add in the next update.
Moving this thread to fixed as initial issue is solved and will update once line-break removal is in place.
Cheers,
2 Likes
Not sure if this is the right place to post this, but it’s the closest issue to what I’m experiencing right now:
I’m in the middle of migrating a cwicly site to a new hosting provider and for some reason neither the global classes nor the global stylesheets seem to be loading on the frontend. In the backend everything looks and functions as expected, all the global classes and global stylesheets are correctly assigned and have the correct contents.
I’ve tried regenerating everything (HTML, CSS, global classes, global stylesheets), changing browsers, clearing browser data, updating cwicly to its newest version (1.2.9.7.4) but nothing has helped so far.
One interesting thing I’ve noticed is that if I update a global stylesheet and then look up the contents of the cc-global-stylesheets.css file through the file manager of my new hosting provider the changes I made in the cwicly editor are not reflected in the cc-global-stylesheets.css file. So there seems to be some sort of disconnect there.
Does anybody have an idea what could be causing this issue? Anything that could point me in the right direction would be greatly appreciated.
And please do let me know if I should rather post this issue as a separate post instead of just a comment here on this one.
Thanks a lot!
Hi @marc,
Sorry to hear you’ve had trouble with this.
It seems that there may have been an issue with the files during the transfer process.
Could you please provide us with more information about how the migration was conducted?
Additionally, if you would like us to investigate further, we would require access to the backend and database.
Please feel free to contact us at support@cwicly.com and share the necessary details using: https://paste.cwicly.com/.
Thank you in advance.
Hi @Araminta,
thanks for reaching out so quickly!
The migration was conducted over the FTP Wordpress migration service my new hosting provider offers as part of the Plesk interface.
Actually, your question on how the migration was conducted gave me the idea to try migrating using the Duplicator plugin instead of the FTP method and see what happens. What happened:
Everything works as expected now 
I had discarded Duplicator because in the beginning it didn’t work, but after editing my /etc/hosts file just now it did.
So yeah, nothing left to do on your side, thanks for giving me the idea to try a different route!
1 Like
Hi @marc,
Thank you for getting back to me on this!
Glad to hear the second migration was successful
Please don’t hesitate to let me know if you have any other questions.
1 Like