Not sure if it’s a bug of if I do misunderstand this function.
When copying a relative style, CSS values of the original and the copy are “linked”.
So when I change something either inside the original or the copy, the changes will reflect in both.
Edit: Seems to be inconsistent. Might involve copying from a copy.
Will investigate further and update here if there are new findings.
Actually, I can remember it also was happening before the copy/paste feature was introduced.
It was in my extended testing phase with v18.104.22.168.5. So the issue might be not related to copying relative styles. I just realized that when reading your answer.
No global classes were invloved, but in both cases it was the div block.
I will try to reproduce the issue today and will update then.
Edit: Just wanted to add that in both cases there were additional classes involved that didn’t “exist” (with no styles applied) . These were helper classes to change styles with interactions, when toggling classes, like .active or .open
Hope that makes sense.
May I ask if the properties are transferred to the RS editor in both instances? Meaning that when you edit the copied RS, those modified properties appear modified in the original RS?
Or is this simply applying in the CSS?
It is indeed an issue with(in) the RS editor.
Everything I was talking about is happening there.
There is no issue with the CSS output on front-end. All styles are applied properly, so each set value is reflecting 1:1.
As soon as the issue occurs, it doesn’t matter which property/value I change. Everything is transferring to the other classes.
So it is also the case that I change one value inside the RS editor and that particular style applies to all other created (RS) classes within that block.
This is actually the case.
No complex classes were created, just something like .blockclass.active
Somehow the properties/values are linked in some cases and since it happened also before the RS copy feature was available I guess the issue might be not related to it.
Btw. both times that happened took place inside the template editor / Cwicly Themer, editing custom templates.
As soon as I am able to reproduce this I will share a screencast and if needed give you access to the installation.
Thanks for that.
I wonder if what you’re referring to is something we found just a few days ago (fix coming out later today) with Flex properties not being applied to the specific RS rule but to the original block also.
Basically, there was a bug with Flex properties not being saved for RS and directly modifying the original block rules (outside RS).
Didn’t face any issue in context of flex properties, at least as far as I can remember.
In v22.214.171.124.5 I had issues with width and max-width.
I do remember that because I had a specific use case and it drove me crazy.
I also remember I had a workaround, so the values wouldn’t change anymore, still the issue was there. It’s been months, so no clue what I actually did.
Yesterday, using current version of Cwicly, it was the transform property.
To double check if it is an issue with a certain property, I changed also the background-color and font size.
Each property I tested was affected. I could “fix” it by deleting the RS item and create a new one.
This is also the reason why I can’t show you an existing related issue.
Was able to find it over there and could kind of reproduce it, it’s a similar issue but 100% related to.
Not sure what’s going on, I recorded a quick video.
In case you need admin access to investigate, please let me know @Louis.
As you can see, the original block sizing properties are also affected, but this might be fixed with v126.96.36.199, not clear for me.
Not able to replicate the actual issue that values are linked.
Maybe the issue which is shown in the video is a good starting point to investigate further.