- last update
over 1 year ago 29,447 pass, 2 fail - 🇺🇸United States smustgrave
Don't have time to actually rebase but updated target.
- First commit to issue fork.
- last update
over 1 year ago 30,056 pass, 2 fail - 🇫🇮Finland lauriii Finland
I rebased the MR. It was not really possible at first because there were merge commits in the branch. Luckily it was pretty straight forward to get rid of the merged commits because there were no merge commits before the MR commits. I ran
git reset --hard a9d6facb4e
, wherea9d6facb4e
was the last commit before the commits that were introduced by the merge commit. After that I could rungit rebase 11.x
without any difficult conflicts to resolve.Thanks for the review @rkoller! I'm wondering if you've tested the experience before this patch? It would be helpful if we could figure out how the experience changes as the result of this issue, so that we know which issues needs to be tackles here, and which issues should be moved into their own bug reports.
It looks like I mentioned this already in #38, but putting it again here for visibility. Instead of just removing the
datetime_wrapper
fromdrupal_common_theme()
, we need to deprecate it. Unfortunately we haven't defined the steps for this 📌 Provide a mechanism to mark entire twig templates as deprecated Fixed so this is something we'd need to come up with. - First commit to issue fork.
- 🇺🇸United States gcb
Here's the current state of the MR as a patch file for stable use in composer builds. This applies for me on 10.2.4.
- 🇯🇵Japan tyler36 Osaka
Adding note on "current" behaviour for Drupal
10.2.5
with Claro admin theme.I have a custom entity with 2 fields:
-BaseFieldDefinition::create('timestamp')
-BaseFieldDefinition::create('timestamp')
When rendering by
Drupal\Core\Entity\ContentEntityForm
, they appear as such:However, changin the definition to
BaseFieldDefinition::create('datetime')
and clearing the cache:Not sure if current MR/patch updates 'timestamp' too, but I would expect them to both display the same.