A problem with unique ID and id attribute on frontend

[elzadj]

Linked to #4967

Ok, so we decided to go away from our way to generate styles, fonts and meta per page, because it makes archive pages, custom taxonomies, loops, reusable blocks, FSE, etc. broken.

So we now generate everything per a block, and add styles, fonts, etc. to new DB tables that are working per a block. Then we check all blocks on frontend and load the styles / etc. we need. We also add a php style processor and generator to run without the Gutenberg editor.

PROBLEM

Now, we have a problem with our uniqueID attribute, that is also the id attribute on frontend, because it's not really unique on the site, it's unique per a page. And all our styles, scripts, meta, fonts, everything work by that id.

I've fixed the styles by adding a really unique attribute styleID for data-maxi-style-id on frontend:

So I've changed something like
body.maxi-blocks--active #number-counter-maxi-1
to
body.maxi-blocks--active #number-counter-maxi-1[data-maxi-style-id=maxi-1689071551556-pgtx66x]

and it works great for styles generation, but we still have number-counter-maxi-1 as the id.

And if we open a category page with several posts that have NCs, we have several NCs with #number-counter-maxi-1 (same for the containers and everything else). Now, styles are not broken because of the [data-maxi-style-id=maxi-REALLY_LONG_SHIT], but the html is still invalid, because we have duplicated ids. Same problem for any loop or blog with posts that have Maxi blocks. Doubled ids everywhere.

Beginning with HTML 4.01 specification dated Dec 24, 1999 it is invalid if the id attribute has a duplicate value.

SOLUTION

One idea that I have to resolve it is to merge uniqueID and styleID into one really unique thing, and use it as the id in html. Migrations are going to be a nightmare, but we still need to migrate all the existing blocks to 'per block' DBs anyway, so... it's already a nightmare.

I welcome any other ideas or possible solutions, because we can't really generate any invalid html.

[elzadj]

Other plugins don't use ids to generate styles, Kadence uses unique classes like .kt-block-spacer-_5675b5-64

I also think we need to make the REALLY_LONG_SHIT shorter, maybe something similar to kadence, like 8 numbers and letters. Then, if we merge it into one uniqueID, it should look like container-maxi-342ds3w4

[elzadj]

We can check only the last row tho and then add +1 to it. That's an option too. 🤔

[Fybex]

That will take some seconds to check the DB table on a big site. Too long, and we need to do it each time we add or duplicate a block.

K, but if we use this random big thing, we'll still check if there's a key like that in the database, right? It might match anyway

We can check only the last row tho and then add +1 to it. That's an option too. 🤔

Yes, but have to be careful if the order has been broken by deleting blocks. I mean, if we need to look, we can find something more optimized than a big random identifier, but we should be careful

[elzadj]

The '1689071551556' part is generated from the current timestamp, so the matching with previous values seems almost impossible. + a set of random letters, + if we add the block name, it makes it even more improbable.

But yeah, need to be careful, the fewer numbers / letters we use, the more the probability of a double is.

[elzadj]

@Fybex just an idea (I ran it with AI) - what if we link the unique number to the autoincremented column number in DB? Then we can check the last existing one just once. Removing is not going to be a problem, because the values are not re-used. The max limit can be a concern tho. 2147483647 for INT and 9223372036854775807 for BIGINT. Both seems big, but it's still a limit.

Undo and redo need some fixes for that tho.

[Fybex]

Sounds easy and safe IMO 👍

[Fybex]

Now, we have a problem with our uniqueID attribute, that is also the id attribute on frontend, because it's not really unique on the site, it's unique per a page. And all our styles, scripts, meta, fonts, everything work by that id.

Isn't this problem was solved by adding to block from for example FSE head template part -header-template-part slug to uniqueID? There are some drawbacks to this approach of course, like on moving from template part to template, we're changing uniqueIDs, but I thought it's not that critical. Is there any other problems, which I don't know about? 🤔 And if yes, why we can't use the same approach. I like yours approach with static unique for the whole site uniqueID more, less side effects will happen, when uniqueID is static, but I thought, that already used approach is just working and not that bad for MVP IMO 🤔

[elzadj]

I would prefer to use the same approach for all blocks on the site, without supporting a unique thing for FSE. There is also a reusable block issue too - if we create a reusable block in the editor, and then we add it to FSE too - we need it to keep the same styles everywhere.

[ckp267]

Agree with all of this you say. Especially reusable blocks, wrapper blocks, fse - same styles everywhere preferred.