@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 🐛 JS #states behavior does not have a detach method Needs review 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 !
All PHPCS and PHPStan error fixed
No matter what I do, I still have the message to rebase. I followed this documentation here => https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → and was able to rebase, but still not working, I tried once again with accepting all commits from 3.0.x prior to mine but it's not working...
Well, in my opinion, since the module is using js and css, eslint must be enabled. Adding gitlab-ci to modules is the new norm. Helps improve the code quality and best practices overall. We will open other tickets to fix code issues.
pbonnefoi → created an issue.
@VladimirAus good to merge now after rebase :-)
Add the .gitlab-ci.yml to run PHPCS, PHPStan and PHPUnit and improve future code quality of the module.
Well I added it because it was necessary to see if all errors were fixed. What do you suggest I should do ?
I think the 3.0.x needs to stay as it is the new version standard (And I've done some work to update the code to the latest standards). A release in 3.0.0 would be nice and let the branch 8.x be only the one working on Drupal 8 and 9.
All PHPCS and PHPStan errors are fixed and PHPUnit up and running. Needs code review and merge I guess (with a new version)
pbonnefoi → created an issue.