I wanted to test the 1.1.0-beta. Updated from 1.0.2 . On 1.0.2 i had set up one storage type. After the update i've created a new storage type. as name pattern i've chosen the example string from the field label ( [storage:string-representation] ) . Both storage types have a text (formatted) field and a text (formatted, long, summary) field. when i create a new storage entity with the storage type created with 1.0.2 everything works flawlessly but when i try to create a storage entity with the storage type created in 1.1 beta i get an error message on save with the description This values should not be null.
1. composer require version 1.0.2 and drush en storage
2. create storage type (title set and all four checkboxes checked)
3. create storage entity with the 1.0.2 storage type
4. set the version of the storage module to ^1.1@beta and update the module (run drush updatedb afterwards)
5. create another storage type (title set, name pattern: [storage:string-representation] and all four checkboxes checked)
6. create another storage entity with the 1.0.2 storage type
7. create storage entity with the 1.1.0 beta storage type
Tested with Drupal 9.2.7
Comments
Comment #2
mandclu commentedThanks for filing this. Was there more to there error that was logged?
Comment #3
rkollerno there weren't any log entries unfortunately. :/
p.s. perhaps related perhaps completely unrelated it looks like the name pattern has no activity or effect at all when creating the corresponding storage entity. there is also not the usual "browse available tokens" link in the storage type. will create and write up a separate issue tomorrow (just no time left tonight, next meet up starts soon and then its already bedtime). but wanted to note as a possible clue in the context of this issue already.
Comment #4
mxh commentedThanks for reporting this issue. I will have a look into this.
Not every input that supports token replacements shows a token tree browser, it's up to the implementation whether a browser is shown or not. It's in fact not related to the problem here, but thanks for the hint - might be something to consider to include it at this point (should be addressed in a separate issue though).
Comment #5
mxh commentedComment #7
mxh commentedAdded a check whether the name field is used in the form, despite of having a name pattern defined. Also changed the description of the name pattern input a little bit, in hope to get the understanding right what it does. The
[storage:string-representation]token could need some TLC in regards of documentation, but that should be covered in a separate issue too IMO.Essentially that token falls back to load "string" field values (up to 2 items) and would use those if any available - otherwise when no value of such a field type is available, then that generated value is empty. One could discuss about whether it makes sense to include more field types in that fallback generation, but I see it actually not to be the right place to do so. The paragraphs module does a similar thing with a "summary" field, but that does way too much for some of my projects, so that I had to change that behavior. In this regard, if you have some special requirements regards automatic name pattern generation, you can use a different token, or implement implement the according hook
hook_storage_get_string_representation(documented in storage.api.php).Please test the current development release whether the error is now gone.
Comment #8
mxh commentedComment #10
mxh commentedComment #11
rkollerThanks for the quick fix @mxh! I've updated the 1.1.0 beta1 to 1.1.x-dev and created a a new storage entity based on a storage type containing a set naming pattern. The storage entity is created without any complaint - the error isn't happening anymore. :)
About #4 - thanks for the explanation i was unaware that the token tree browser isn't mandatory for modules using the token module system. but never the less i have to admit from a user experience perspective, that me as a user have no idea which tokens would be eligible to be used in the name pattern field at all tbh (even the example from the name pattern label
[storage:string-representation]has no effect so that a name is auto generated - what i would expect based on the description and naming). so i agree that thinking about adding the token tree browser with a future issue might be a reasonable step.Comment #12
mxh commentedThank you @rkoller for testing this and giving feedback, happy I could help you out on this.
Created a follow-up issue regards the Token tree browser: #3243797: Name pattern: Give the user the ability to browse for available Tokens
Comment #13
mxh commented