-
Hello,
Do you have any advice for automatically migrating global styles?
I am well aware that it is indicated in the doc “there is no automatic way to migrate from the old system to the new system. This would require us to mass auto-replace data in your content, which we don’t like doing.” https://docs.generateblocks.com/article/migrating-from-legacy-global-styles/
But I agree to “mass auto-replace data in your content”, how do I do it?
Could you consider that migrating a site would mean:
– Recreate all styles
– apply them to all the content, that’s the problem, it’s not nothing to go to all the blocks on all the pages. I’m not a program, I risk forgetting things, it’s not easy to “Once you have replaced all instances of the legacy Global Style”
– check the site again on mobile, tablet, desktopCould you answer these questions so that I can make a decision for future projects:
– do you have other developments to come which use this same logic of “legacy” not automated (that of the old container and now the styles.. believe me for the old container it was impossible to use a mix of the old and the new system, it was disgusting and it was starting to bug, I finished migrating all the sites at the end of the year on my vacation). So I doubt that I will be able to keep two style systems in the long term. regarding maintenance, I have to update that
– does this seem normal to you? It’s a professional tool, it’s for the global styles that I chose GP and GB (because I’m an integrator and it allowed me to apply global styles that I won’t have to retouch). So I overuse these global styles, it’s a good practice, right? I feel penalized for that (of course users who don’t care about maintaining the code, the performance, and never use them will not be impacted: but us?)
– We choose your tools to have clean code and a clear interface for our users, do you take this into account? Having two style management systems that coexist, are you committed to ensuring that it doesn’t glitch at any point? Should I leave it like this?I think it’s important for you to know that I’ve been crying for 2 hours, because I just tested a migration on a small site in dev and I can see that I couldn’t migrate all the sites manually without do stupid things. It’s too much work. So I tell myself that the maintenance of these sites, which is essential for me, is over, and that I have chosen my work tool poorly.
You can help me ?
-
Hi there,
first off, our apologies for causing you any alarm or frustration, it is not our intention.
The mass auto replacement of data in your content, is not a feasible option. The process would be super complicated and prone to error.
The main question to answer is: Do you need to migrate ?
Simple answer is No.
If you already have a global styles system in place and it provides the sites requirements then there is no need to migrate.
The Legacy Global Styles will continue to work today and in the future.
There is no concern for conflicts with the newer system as they both operate independently of each other.If you feel the need to migrate then you could do it piecemeal.
1. In the migration article, you can perform the first stage and jsut create a new Global Style for each legacy Global Style.
2. Then you can quick edit the legacy global styles and set the status to “draft”, this will disable those legacy styles.And thats it for now.
Any blocks in your content that has a legacy global style attached to it will keep that classname attribute which will attract the new global styles of that same classname.
In the future, if you so wish, you can manually replace the global styles in the editor. But you do not have too as the blocks will still attract the new styles regardless.
To answer your other questions:
1. do you have other developments to come which use this same logic of “legacy” not automated ?
Inevitably there will be future updates where legacy must be maintained. As per the Container Block example; like all blocks it gets saved in the block data of your post content. Which means it can only be updated by either editing the post or by a mass database repalcement. The latter is not an option as it is too prone to error.
We therefore fallback to Legacy options ie. blocks that are already added to the content maintain their legacy version, whilst newly added blocks can use the newer versions.
This is always happening and in most cases it goes unnoticed, for example the basic Container Block is now on version 4. And many older sites will contain all versions without any issue.
Where possible we will look to gracefully upgrade existing systems as opposed to making replacements. But our main focus has to be to maitain legacy and backwards compatibility as no one wants to see their site break on an update.2. does this seem normal to you?
I wouldn’t say it was normal, but the alternative would have meant that we did not make this update. And i can only apologise again that this update although it does not break anything, it does mean Pro users wanting to migrate may feel penalised having invested in the legacy tools.3. are you committed to ensuring that it doesn’t glitch at any point?
Maintaining backwards compatibility and legacy is something that we have always been committed too. And from my personal experience and the many users we have supported, i can confidently say that this will not change, and yes you could leave it exactly as is.I hope my answers help somewhat, your investment and feedback is important to us and if theres anything more we can do then please let us know.
-
Hello,
Thanks for your response, ok I’ll leave the styles like this for now
My feedback on the new system:
– It’s really great to be able to combine several styles (I dreamed of it ^ ^ it completely changes the way of thinking about the CSS of the site)
– it would be great to have a shortcut to directly replace one style with another (rather than deleting it then selecting another, it’s a manipulation that I often do)Looking back, I’m happy to have migrated all the old containers, I can’t imagine clicking on a container having 2 Legacy messages (one for the block and another for the style). it’s sure it’s functional but on the editor side these are messages which pile up and which don’t look very professional (I train them to edit an article, with the pattern library but also the styles, I just have to warns that the new message is “normal”)
—
By the way, in my eyes what is currently missing the most is the list tag (ul, li) and the possibility of personalizing items with the icon library, it’s still a tag important at the semantic level (using Heading Bloc as a paragraph to get around the problem works visually but not semantically if they are indeed list elements). I’m tinkering with WordPress styles but it’s a bit frustrating. I’ll post the code if it’s useful to anyone.
function site_register_block_styles() { register_block_style( 'core/list', array( 'name' => 'my-list', 'label' => esc_html__( 'My list', 'generatepress_child' ), ) ); } add_action( 'init', 'site_register_block_styles' ); ul.is-style-my-list{ }Thank you for your response ^ ^
-
Thank you for your understanding, and feedback. It really is appreciated.
For Lists we have that on our radar too.
And we look to build some functions into blocks that will give your the same control as Container Blocks for creating your list and list items.For now, if you wish you can use GB Pro data-attributes to set the
rolefor a block so they are recognised as list and listItem. See here fore more info: -
Yes! I want lists too! I’m using headlines with icons now, but that is not semantically correct.
Can’t wait…
-
For now as a Pro user you can add the
roleattribute:From the browsers perspective and any accesilbility devices it will treat it as a list 🙂
- You must be logged in to reply to this topic.