I chatted with @ultimike about this yesterday, and this might not be a huge lift.
The input is simply <input type="date">. Changing it to type="text" and placing a token in the field magically works, since all the data from that field is just stored in a text column. We tried substituting a token, and it worked out of the box.
Mike thinks (and I agree) that the hardest part here is designing the UI correctly. I made a very quick and dirty prototype for what it could look like, attached as a screenshot here.
So we could:
- Add button and some javascript to toggle the "type" attribute on the input
- Add some logic in the form to render the correct type initially (if the saved data doesn't look like a date, use text. Otherwise, use a date.)
- Does there need to be anything else?
Happy to discuss this further, but I think this would make sense.
I find these sentences confusing:
You can also specify how the entity should be validated (
node: \d+). This is useful if the used routes are /foo/{node}and /foo/bar, where {node} is a node ID.
Is \d+ a regex string? Is the expected value of such a key always a regex string? If so, can we say that explicitly? I think that's right, but I've been unsure about it for years.
I'm dealing with the "edge case" described in #14. Comments #12, #13 and #15 do not appear to be helpful in resolving it. +1 for this being a bona fide issue that should be resolved.
I've done some playing with this as well based on @j. ayen green's findings.
The really perplexing thing is that, when running composer install with said patch, the command line reports:
Could not apply patch! Skipping.
However (at least some of) the code from the patch indeed is applied. And then, when removing the patch line from composer.json and running composer update or composer install, composer believes that the code does not need updating. It reports: Nothing to install, update or remove even though the (partially?) patched code persists. I have to manually rm -rf web/core after removing the patch line from composer.json, and then run composer install to get the correct version of the code in place.
I'm not clear on whether this is normal behavior for composer and cweagans/composer-patches, but it certainly seems odd, given that the terminal says that the patch was being skipped.
I'll look into raising this at cweagans/composer-patches, since I think that's the correct place to put the issue. But, I also wanted to notate it here in case anyone else comes across this. I'll also see if I can replicate this with a different patch.
+1 A stable release for 10 would be very helpful for us.
#3 works well for me against 2.0.1-alpha6
benjifisher → credited miwayha → .
Chris McGrath → credited miwayha → .
benjifisher → credited miwayha → .
Here's a patch which creates the submodule and gets the registration form looking presentable. It meets the requirements listed in the issue, but I expect there to be different ux work. None of the submit logic has been started.
Quick patch to address the above issues. I'm not as familiar with the functionality, so I wouldn't completely know if I inadvertently broke something, but it looks like its working at first glance.