I have tested this item ✅ successfully on d6494a7

Code review

I'm not sure if it's sufficient to test only by code review. The escape is definitely not necessary for the databases, but maybe the component needs that?

What happens if you add a new tour? Does it escape the quotes again in the extensions column for the newly created records?

In the guidedtours table, there are no double quotes with fresh installations of the latest branch and prebuilt package of this PR.

@Quy And what happens if you create a new tour in backend so a new records gets added by PHP?

@Quy I've just tested what I meant. It is ok, when adding a new tour in backend, the double quotes are also not escaped, so all fine.

Same as the other entries ["*"].

@Quy Except if you select some components, then it is e.g. ["com_content","com_categories"] ?

The question is now: Do we want to add a new update SQL which removes the escapes from beta 4 or rc1 or rc2 versions when updating? I am not sure if it needs that, but I know at least one person of whom I think he would want that.

Sorry I meant to say no \ required in the SQL files and not no double quotes in the table.

I've restored the previous test result in the issue tracker since the commit which invalidated the test count was just a clean branch update.

I have tested this item ✅ successfully on a8969e6

I've verified that on both MySQL and PostgreSQL, the double quotes in the extensions column are already stored in database without escaping when making anew installation without this PR applied. This means that it does not need a new update SQL script for fixing the values when updating 4.3 beta and RC versions because there would be nothing to fix.

I've also verified on both databases that a new installation with this PR applied works fine, there are no errors or warnings in the database server logs (except of the usual ones on PostgreSQL), and the values of the extensions column are still right.

By review all SQL changes of this PR are correct.

RTC

Thank you @Quy for the PR :-)