Random IDs and their random change
-
I am running into a lot of issues with this IDs, which are added to every block, even when there is no specific styling added (looks like this: block_id”:”e2a1b3e3-882e-4235-baad-9995a8b150d0″). They seem to change randomly, although no changes where made, not to the content of the block, not to the styling of the block, not to the site, just really nothing. The site was opened. That’s it.
1. I have THOUSANDS of “unsaved Reviews” cluttering the database and when I look into them, the only changes are in these IDs, although no changes were made.
2. When I edit for example a button-block, cause I need to add an ID to one button, it’s losing it’s styling and is set back to the defaults. I guess because of the random ID changes…
3. When I use the quick&easy import / export for WordPress to transfer, all manual styles are lost, cause of the IDs not beeing transfered (actually, the IDs are, but not their reference), so i have to do it the more inconvinient way by exporting the whole database.
I don’t know, why this was implemented in the first place and what is achived with that, but it makes front-end work a hell.
-
Hello Vrunda Kansara,
thanks for your quick reply.
Sadly, the custom classes do not solve every problem, I already use them.
# Still thousands of reviews cluttering the database.
# Adding IDs is imposssible in combination with styling through the plug-ins interface. If I style them completly through a class, so I can add both, class and ID for a modal for example or GA-tracking, the whole plug-in doesn’t make sense any more… Too, it’s dramatically limiting the useability of the blocks, if I can’t add custom html. Means no additional heading or a link in a timeline-block. No Buttons, headings, lists in that price-list block, which would make them a good and versatile option for many usecases. (yeah, i know I can put a class on the container and a selector chain down to the “a” to make it look like a button… but what about headings for SEO reasons, lists for many features?)
# Importing the Database via SQL is not the problem with the IDs, using the Import/Export through the WP-Interface is. This is not a big thing, as these function fails on so many ends, that it isn’t an option in the most usecases anyway. I just brought this up, cause this is just another (very minor) inconvinience caused by that ID-method.
Not gonna discuss user experience, cause this depends on, what kind of user you have in mind. I don’t know, what kind of users you aim at and in what direction the future development goes. So this is not really a support-request, but a feedback.
I wanted to point out, that this use of IDs creates a lot of unnesseccary restrictions. It puts the plug-in more on the side of page-builders, where all the options are served through the interface, but whenever the premade options do not fit my needs, I am doomed. So I could create a feature-request for all that above (give me lists and headings in price-lists etc.), but that would end up in a kind of page-builder, not in a versatile helper, that gives me a basement to create whatever I want to achive on top of it.And at this point, I do not see the use of the plug-in anymore: Depending on the project, I would go for a theme + pagebuilder or for something custommade with just some plug-ins as helpers and timesavers. If the helper fails at some needs, and I not only have to write it from the scratch, but too overwrite, it doesn’t save me time.
But again: I am maybe just not the kind of user, the plug-in is made for. I anyway appreciate your time and effort! Thank you.
Kind regards
Dorothee Schuster
- The topic ‘Random IDs and their random change’ is closed to new replies.
