pbonnefoi → created an issue.
pbonnefoi → made their first commit to this issue’s fork.
I hadded a fix to clone entity reference properly when translating a translation as new entity. Part of the solution was in the EntityCloneSubscriber so I added a service to handle this case both in the subscriber and in the cloneReferencedEntities method. Might be improved, no unit tests yet.
Sounds good to me, good job. Hope a maintainer will merge this anytime soon.
I think your patch is outdated that's why it does not apply. Anyway, I have another problem when sub entities reference subentities as well. For exemple, if I have a node with paragraphs which have sub paragraphs, the sub paragraphs are not translated properly only I clone a translation without the master. I'll try to dig into it to find why.
I think your patch is outdated that's why it does not apply. Anyway, I have another problem when sub entities reference subentities as well. For exemple, if I have a node with paragraphs which have sub paragraphs, the sub paragraphs are not translated properly only I clone a translation without the master. I'll try to dig into it to find why.
pbonnefoi → created an issue.
pbonnefoi → made their first commit to this issue’s fork.
pbonnefoi → made their first commit to this issue’s fork.
pbonnefoi → changed the visibility of the branch 3481344-drupal-11-support to active.
pbonnefoi → changed the visibility of the branch 3481344-drupal-11-support to hidden.
@gaurav_manerkar, just in case, I had similar issue and adding this to my form fixed my problem :
$form['#attached']['library'][] = 'core/drupal.dropbutton';
pbonnefoi → created an issue.
pbonnefoi → made their first commit to this issue’s fork.
Thanks for your help ! Indeed, it seems rather difficult to write a functional test since this bug is a combination of core and paragraphs.
Patch worked for me on Drupal 10.3 and Drupal 11.
pbonnefoi → made their first commit to this issue’s fork.
Super, thank you !
pbonnefoi → created an issue.
pbonnefoi → created an issue.
pbonnefoi → created an issue.
I tried the patch from 3258535-2.x-translatable-entity-reference and fixed my problem of translated entities wrongly cloned when translated from an entity that is not the master of the translations.
pbonnefoi → created an issue.
Great, thank you !
Works for me :-)
Thanks for the info @nod_ any idea which fix to apply yet ?
@ManojSelvan, @tunic, I confirm that there was a problem and an issue attached to it => https://www.drupal.org/project/drupal/issues/3468860 🐛 Form field #states not woring with entity reference fields Active with a patch already that fixed the problem in my case.
I had the problem with states visibility on a custom form (which was in a modal with ajax reload) and I confirm that the patch fixes my problem :-)
pbonnefoi → created an issue.
I would say replace accordion field group by detail.
pbonnefoi → made their first commit to this issue’s fork.
Merged
Rerolled for 10.3.x
It seems that this is not working on the latest version. I'm investigating.
pbonnefoi → made their first commit to this issue’s fork.
Great work @nils.destoop !
Last patch from #155 works great on 10.2.5
I'm having the same issue
pbonnefoi → created an issue.
Patch #35 for 1.11 applied on d10.2.3. as well and fixes my problem.
I think accordion should be removed from the module and be in another sub mobule. It's also consufing because "Detail" field group is also like an accordion.
Glad I could help !
Ok good to know, thank you very much for the insights !
I have a similar problem trying to fix a unit test on a contrib module, but adding $this->getSession()->reset(); did not work. Do you add it right after drupalLogout() ?
An improvement on the error message would be very nice as well because it does not make much sense.
The unit test causing problem is from the redirect_after_login contrib module.
Well, you might be right. I thought about it but didn't know how to proceed.
Hello, the module does not handle custom entities with no bundles yet, but feel free to contribute if you have some spare time :-)
Indeed it was accessible to anonymous user. I changed it and it's kinda working but it's odd for me that the bearer is not checked prior to the content access permission and besides there is no logging that helps you really understand why it's not accessible.
I have the problem on another project where we have a custom rest route with permission only to authenticate users and it's not working. Maybe it's du to accessCheck on query not there (as now it's mandatory since D10).
@johan-den-hollander I opened an MR with the patch from #2765895 (with little improvements) I have other ideas, but need to find time to implement it.
I made this feature as an option with the following settings :
You can set flush_redis_on_drupal_flush_cache to TRUE to flush Redis cache when clearing all Drupal cache.
$settings['flush_redis_on_drupal_flush_cache'] = TRUE;
You can set flushdb and flushdb_async to TRUE to use the Redis native flushDB when clearing Drupal cache.
$settings['redis_flushdb'] = TRUE;
$settings['redis_flushdb_async'] = TRUE;
You need to set a redis base properly to use this feature. By default, Redis gets cleared getting all keys using cache_prefix. This is not recommended on production as it could be an expensive task to clear all the keys.
pbonnefoi → made their first commit to this issue’s fork.
pbonnefoi → made their first commit to this issue’s fork.
pbonnefoi → created an issue.
pbonnefoi → created an issue.
Thanks, it was merged and released in both 8.x-2.3 a,d 3.0.0. Thanks @chipway
Thanks @Soubi for the report, duplicate of #3005314. I will credit you as well for the patch.
Available since the release 8.x-2.1
pbonnefoi → made their first commit to this issue’s fork.
pbonnefoi → made their first commit to this issue’s fork.
Great ! Thank you !