Hi Themeco,
Not sure which forum to post this in, I created this bug issue yesterday and also had it here in Beta forum earlier, then decided to the delete from here… the bug issue remains.
Hi @strobley,
Thanks for the heads up here. Typically you’ll get a faster reply in the support forum, especially between cycles. I took a quick look at that and at a glance I think there’s probably a bug in there somewhere. Some of the team already started testing it so I’ll send them a few notes to help, and we’ll get anything that shakes out onto our issue tracker.
Many thanks @alexander 
Edit: quick update to confirm the 2 points relating to this.
- inline style added to the id.
- When using Dynamic Content in Global > Colors they do not render in Preview.
Thanks again!
Another strange bug @alexander
Add Off-Canvas element, set Toggle to Text and in Secodary Text add
{{dc:woocommerce:cart_items}}
One the frontend this adds cart count of the Dnynamci Content to the inline style when items are in the cart.
<a class="x-anchor x-anchor-toggle e1832-43 m1ew-z m1ew-10 m1ew-11 m1ew-15 m1ew-1b m1ew-1f m1ew-1g m1ew-1i" tabindex="0" style="--tco-dc1ew-0:<span data-csdc-wc="cart-items">11</span>; outline: none;" data-x-toggle="1" data-x-toggleable="e1832-43" data-x-toggle-overlay="1" aria-controls="e1832-43-off-canvas" aria-expanded="false" aria-haspopup="true" aria-label="Toggle Off Canvas Content">
I noticed that Dynamic ACF colors aren’t supported as a Grid Cell Background but they work on elements inside the grid-like button backgrounds or text colors. They also work as custom backgrounds using a Div set to 100%.
I’m assuming this is the same kind of issue noted?
Is there an idea on when this may be addressed? It’s throwing a money wrench into something I’m working on and fixing it later is going to be a beast.
Thanks
Thanks for the extra info @strobley. Regarding Global Colors, those will not support Dynamic Content.
@dabigcheeze, thanks! I’ve corrected that issue for the next release.
Thanks for update @alexander, to confirm you mean Global Colors, those will not support Dynamic Content in builders preview only? Asking because Dynamic Content in Global Colors do seem to work on the frontend.
Hi @strobley,
The system isn’t designed for Dynamic Content to run in Global Colors at all. Even though it may be working on the front end, that’s more of a fortunate accident but isn’t stable and I wouldn’t recommend relying on it. We’re going to be replacing the Global Colors system with something new down the road and it’s likely that will stop working.
Thanks for explaining @alexander, most helpful.
Shall the new replacement for Global Colors support either Dynamic Content or CSS Custom Properties, neither or both?
The new system will likely be called “Globals” and will let you create global variables of various types (colors, fonts, dimensions, text, images, etc.) Those Globals will be accessible anywhere you can use Dynamic Content, which is pretty much everywhere now. Because they are actually source of Dynamic Content, it won’t be possible to reference Dynamic Content in them. They won’t be accessible as CSS Custom Properties, but because Dynamic Content is available in the code editors you’ll be able to setup your own if desired.
Thanks @alexander, I’m not sure I completely follow.
Currently I have created custom Dynamic Content using the filter cs_dynamic_content_css_custom_property
Inside the custom Dynamic Content I input {{dc:css_custom_property:color name="my-color-1"}}
This filter in turn returns a CSS Custom Property var(--my-color-1);
I then assign this Dynamic Content to all builder Elements color setting. On the frontend this results the Builder generate inline styles for example:
.m1fr-1y.x-text .x-text-content-text-primary {color: var(--my-color-1);}
.m1fr-1y.x-text .x-text-content-text-primary {background-color: var(--my-color-1);}
I’m sure you see where is the going… it allows color themeing on the front end so users can switch between light, dark or any number of color themes created with CSS Custom Properties.
If the new “Globals” allow color themeing albeit done differently then that’s a-okay. If not, then it not being able to use Dynamic Content to achieve this as it works now feels like a limitation.
That should all continue working! Nice job setting that up!
What I’m saying is you can’t go into Global Colors, create a color and set it to {{dc:css_custom_property:color name="my-color-1"}}, then just select that option from the color palette. You can certainly place your custom DC statement directly in the element color pickers though.
Thanks @alexander, I used the filter principles you kindly shared on the Forum.
Sorry, I’ve realised I did not myself explain correctly.
I do currently create Global Colors for colors, and for each individual global color I set a value to {{dc:css_custom_property:color name="my-color-1"}}. I then use the Global Color with this Dynamic Content in the element color pickers.
This brings the benefit of:
-
All colors being centrally controlled and managed
-
Not having to remember the Dynamic Content values and being able to use the Global Colors.
-
Mimic the native builders behaviour of being able to change a color just once in Global Colors and have all elements immediately reflect the new color. As you know this is really powerful, without using Globally managed colors, instead just using element color pickers directly would mean changes down the line become incredibly time consuming, tedious and error prone.
Again, sorry for not making this clearer, it would be a significant loss to not be able to continue doing this with the new “Globals”. Being able to use the power of builders with Globals together with Dynamic Content and CSS Custom Properties as can be done now is invaluable. A utopian solution would be being able to do this for all new “Globals” (colors, fonts, dimensions, text, etc.).
If the new “Globals” could be togglable to use either Dynamic Content or use hard values this would allow advanced users the choice.
2 Likes
I see, unfortunately in that case, this is what I was describing as unsupported. Global Colors in its current form, and also our new Globals system will not be designed to support running Dynamic Content.
It’s just not a very good pattern because Dynamic Content is designed to be contextual, and let you pull data from the current post. The Globals themselves are defined and established prior to any of that context existing. For example, you couldn’t set a “global” to Dynamic Content and expect it to pull a color from the current post. It would be confusing if we offered “Dynamic Content”, but then a majority of possible values couldn’t be resolved properly.
Your case is a bit different since you are using a custom Dynamic Content statement that is hardcoded. At most, we could add an action filter in the backend and you could tap into that to adjust values on the fly. In theory, your custom code could call cs_dynamic_content which would attempt to run Dynamic Content on your value. This would probably work for your case, but only because it isn’t post specific.
To summarize, it won’t be officially supported, but there will be some viable workarounds to explore involving custom PHP.
Sure @alexander - I completely see your point, how I’m using Dynamic Content is not content. It is my attempt at using this feature to enhance the builders.
As a thought, would it be possible map new “Globals” directly to a CSS class? Essentially this what I’m a doing, creating a Global class with a CSS Custom Property.
As an idea, if the new “Globals” behave like Tailwind CSS for example, single use utility CSS classes that are that are added to Elements. Then each Global class could have a CSS Custom Property set in custom CSS. The new Global CSS class name could be that of the Global name, or the Global name with the type name prefixed.
For example, if the Global type is Font and I create a Global font named Content Main, the class could be cs-ff-content-main. A Global Color named Primary 900 could be cs-cl-primary-900. I’m just making up names but think you get the idea.
The new Global classes could then be applied to Elements, and because of the cs- Cornerstone prefix, in addition to the Global Type prefix, ff- Font Family, cl- Color, etc. the naming is ensured to be unique and advance users can apply CSS Custom Properties these these Global utility classes.
Agreed this would mean users should not create Globals of the same type with the same name, but why would someone do this? Maybe an increment integer could be appended as a suffix to duplicate Global names… all just an idea for consideration 
@strobley, I don’t think we’ll autogenerate classnames like that because on sites with lots of variables, it could get polluted quickly and even with things that aren’t even in use. What’s helpful about our CSS generation system is that it only outputs what is actually being utilized. That being said, because Dynamic Content will work in custom CSS, in theory, you could do something like:
.my-class {
font-family: {{dc:global ..... }}
}
That would allow you to expose only the ones you need.