Open jnachtigall opened 2 years ago
Allright. Thanks for the bug report. You’re kinda hitting the current limit of the uid feature.
The uid will be used in the filename and therefor cannot contain characters which are not supported in filenames on your OS. I’ve allready escaped two characters (semicolon and forward slash) see issue #14 and #56. Though because you’re using a title like field as the uid there are many characters that are likely not supported in a filename.
As you suggested we need to encode the uid value to be a valid filename, and we also need to be able to decode that filename back to it’s original state. Otherwise we can’t match the uid value in the DB.
I’m not planning on fixing this any time soon, but I’ll leave it open for reference. In your case it is best to use another field as the uid. You could create an extra field of type uid which encodes the headline field and saves that in the DB in a seperate field. Than that seperate field can be the uid for your custom config type.
We might have to consider dropping the uid
system as it is, and switch to a uuid approach.
That would solve this and a lot of other issues.
I'm rebranding this issue from a bug
to an enhancement
.
I would like to see a new major version of the plugin with a proper uuid
system.
As of writing this comment the config types are required to have a unique field that is used to match entries across databases. Though that is very prone to errors and is why this issue (and a few others) were created.
I would suggest we inject a uuid
field onto the config types in the register function of this plugin, or we use some 3rd party plugin to do that for us. Then that value can be used to write the JSON filename, and be used as a unique identifier.
With Strapi 5 being stable, we might be able to use it's CUID documentId as the unique identifier of config types. I'll do some testing to see if this can be added to v2 of the config sync plugin
I just realised that by using the document ID as the unique identifier we lose the ability to exclude certain configs by default. Those configs are excluded here and are referenced by their names. If we were to use the document ID, that would mean that the names will be different for every instance using this plugin. Losing the ability to exclude these by default.
Soo.. I'll likely stick to the uid system as it is.
Something that we could do is make the uid
optional and if it's left empty fall back to the document ID. That way custom types can be registered without a uid
, but the default types will still have the custom uid
to exclude some configs by default. Though I don't have much incentive to build this as I believe it's quite a niche feature, and I'm not sure how many people use the custom types feature anyways.
We have a custom type, that only has a uniq
headline
(in german) and atext
fieldThis gets exported as
On the filesystem you then have files like
This works fine on Linux or in WSL2. However, on Windows this results in these
git
errorsThis seems like a pretty well known error, see https://stackoverflow.com/questions/63727594/github-git-checkout-returns-error-invalid-path-on-windows
FWIW, doing the suggested
git config core.protectNTFS false
did not work for us (resulted in read/write errors and a bluescreen).We worked around the issue by adding a field
articleId
withinteger
to the above custom type and used this asuid
instead.Not sure you want to fix this in your plugin, but maybe a encoding/decoding of non-ascii characters would be good in the filename?
System