Hey @clarkssquared, I checked for existing coding standard issues and have fixed them.
@lavanyatalwar, I was able to reproduce the issue using:
phpcs --standard=Drupal,DrupalPractice --extensions='php,module,inc,install,test,profile,theme,info,yml'.
It would be helpful to have this set up as an alias on your local machine.
jaswinsingh → made their first commit to this issue’s fork.
Hello,
I have created a patch and replaced the assets classes using the ContainerAwareEventDispatcher dispatcher with Symfony's EventDispatcher.
jaswinsingh → created an issue.
Hello,
I have created a patch for 3.0.x to make it compatible with Drupal 11.
jaswinsingh → created an issue.
Hello,
I have created a patch for 1.4.x to make it compatible with Drupal 11.
Hello,
I have created a patch for version 1.0.0-beta2 to make it compatible with Drupal 11.
The packaging script from DO added a scripting code to the info.yml file, so this patch will fail to apply. As a workaround, we can use the orakili/composer-drupal-info-file-patch-helper package, which prevents the patch from failing.
jaswinsingh → created an issue.
Hello,
I have created a patch for 4.0.0-alpha5.
Hello,
I have created a patch for 8.x.1.15 to make it compatible with Drupal 11.
Since there is a scripting code info.yml file added by the packaging script from DO. So this patch will fail to apply, We can use orakili/composer-drupal-info-file-patch-helper package that prevents patch from failing as a workaround.
Hello,
I have created a patch for version 1.2.0 to make it compatible with Drupal 11.
jaswinsingh → created an issue.
Hello
Since there is no release for the D11 version, and the
#2
📌
Automated Drupal 11 compatibility fixes for flat_taxonomy
Active
patch is not getting applied to the 2.0.0 version because of the text difference(packaging script) in the .info file.
We have used orakili/composer-drupal-info-file-patch-helper package as a workaround to get this patch.
Hello
I have created a patch for D11 compatibility for 2.1.7.
Hello,
I have created a patch based on changes available on #2788507-116 ✨ Add revision support Needs review for the 2.0.0.
Also the changes from #2788507-116 ✨ Add revision support Needs review do not work for existing eck entities. so I have modified the update_hook which will make the existing entities revisionable.
Note - This patch will make all the existing eck entities revisionable.
benjifisher → credited Jaswinsingh → .
I agree with @carolpettirossi. We are facing timeout issue of larger results.
Hello,
I have reviewed the patch in #8, and I noticed it removes the destination query parameter. I believe this is not the intended behavior, as the destination parameter is essential for the entity edit form and other pages. The language switcher provided by Core operates similarly. it retains the destination parameter.
Patch #5 works well, but there is an additional concern. When the language is changed, the destination parameter retains the old language prefix. So, if a user changes the language on the entity edit form and submits it, the system will redirect to the old language based on the destination parameter. This issue also exists in the Core language switcher.
+1 Facing similar error, I have an eck entity referenced in the user entity, where the eck entity is created on the user register form using IEF. This entity has workflow already attached to it, After using the latest version 1.8, I am getting this error when saving the user register form This value should not be null
#11 worked perfectly, but since we are revoking the permission which is not valid, it would be handy if those permissions are displayed as logs. I have modified patch #11 and added the code that logs the invalid permissions before revoking them.
Hello,
I'm using the 2.1.0 version with Drupal 10.1.7. I'm getting an error on visiting the new form mode (?machine_name).
Warning: Undefined array key "#type" in Drupal\Core\Form\FormHelper::processStates() (line 211 of core/lib/Drupal/Core/Form/FormHelper.php).
Hello, the patch in #5 was not getting applied for 8.x-1.0-rc3 version. Re-rolled the above patch.
Hello, The patch available for lightning_scheduler #33 🐛 Scheduler needs to maintain its base fields properly Needs review was not getting applied to lightning_scheduler as a sub-module. Re-rolled the patch.
Had the same issue, where node_type defined in block configs and block configs were in config ignore. #13 worked successfully. Thanks @smulvih2
Patch #15 and #41 do not get applied for the 4.0.0 version. Re-rolled the patch with the latest changes.
Hey,
Here is the patch.
In the patch, I have added a number field on the config form to configure the number of QA accounts. By default, it has the value of 1. I have also added validation of the QA accounts should not be more than 10 as I guess that will be enough.
Each QA account for example will be uniquely identified as qa_administrator_1. The numerical suffix denotes the count of users per role.
I have also added an update hook to change the existing username to a new username.
Hey,
Here is the patch.
In the patch, I have added a number field on the config form to configure the number of QA accounts. By default, it has the value of 1. I have also added validation of the QA accounts should not be more than 10 as I guess that will be enough.
Each QA account for example will be uniquely identified as qa_administrator_1. The numerical suffix denotes the count of users per role.
I have also added an update hook to change the existing username to a new username.