@caesius
Hope the issue with the page break. Still, the issue persists after the
https://www.drupal.org/sa-core-2024-004 →
patch moved. I can replicate it today also on the latest pull.
Hope the issue persists, to handle the exception.
Created a new MR against the 3.0.x commerce branch.
arunkumark → changed the visibility of the branch commerce-3118588-3118588-unable-to-_rb to hidden.
arunkumark → changed the visibility of the branch commerce-3118588-3118588-unable-to-_rb to active.
arunkumark → changed the visibility of the branch 3118588-unable-to- to hidden.
arunkumark → changed the visibility of the branch commerce-3118588-3118588-unable-to-_rb to hidden.
Able to replicate the issue in my custom Form with Table.
Try to debug the issue on the file RenderElementBase.php
it seems that the Ajax button added inside the Table was not taking into the Ajax render element.
Might be table parent elements causing this issue. I tested with other Form elements like LINK
, and it was working fine. Updated the draft MR with the link field working.
Unable to find any solution to fix, Need help in solving the issue.
arunkumark → made their first commit to this issue’s fork.
The issue seems the same as 🐛 Able to create user accounts with the same email address Active . On the issue, it was trying to handle the case insensitively with mb_strtoupper(). But am unable to match the words example and éxample.
Below is the observation received on ISO-8859-1//TRANSLIT
as per https://stackoverflow.com/questions/471021/comparing-strings-in-php-the-...
echo iconv('UTF-8', 'ISO-8859-1//TRANSLIT', 'éxample'); // Output is �xample
I tried this ASCII//TRANSLIT
is working as fine. As per, https://stackoverflow.com/questions/24504331/how-to-compare-two-strings-...
echo iconv('UTF-8', 'ASCII//TRANSLIT', 'éxample'); // Output is example
Creating as MR as per the above suggestion. Feel free to update the MR.
arunkumark → made their first commit to this issue’s fork.
As per comment #39 created a new MR for 11.x version.
Resolved most of the Test case issues, few pipeline issues are unable to fix.
@cjunior already MR is available please convert your patch into the MR.
Updated the issue summary. Moving to NR.
arunkumark → made their first commit to this issue’s fork.
Verified the issue with Drupal 11.x version. The issue still exists. Below are the observations,
1. Created the custom module with routing
2. Added below routing
foobar.vote:
path: '/foobar/vote'
defaults:
_controller: '\Drupal\foobar\Controller\FooBarController::vote'
requirements:
_method: 'POST'
_permission: 'access content'
3. Accessed the URL /foobar/vote
via the browser (i.e GET request by default)
4. The page can be accessible without any deny
5. Verified the URL link via the POST-MAN on GET and POST both are working.
So, the issue may still persist.
Also there is no change in the routing parameters. Hope #15 → will not be valid.
Created MR for the 11.x version. Moving to NR.
@steveoriol
Can you please and the functionality details.
Created MR for patch.
Done the rebase for the latest 11.x version. Now the auto test is green, moving to NR.
Done the rebase to the 11.x
arunkumark → changed the visibility of the branch 9.4.x to hidden.
arunkumark → changed the visibility of the branch 2358537-do-not-require to hidden.
arunkumark → created an issue.
The issue might have been resolved, but I think the translation will not work if a simple language key is added to the configuration yml file. Attaching the screenshot of config export, run after enabling the language modules. It cleary says language specific config not exported.
I think we have to extend the ConfigTranslationFormBase.php
to translate the configuration of other languages.
Might be wrong, any suggestions?
Created MR for the patch #3. Not sure do we need a test case for the additional contrib module. Already there is a check for the title suffix and contextual link in /core/tests/Drupal/FunctionalTests/Theme/ClaroLayoutBuilderTest.php
arunkumark → made their first commit to this issue’s fork.
arunkumark → made their first commit to this issue’s fork.
Seems like a false positive. After latest merge moving to NR.
There is no active development for Drupal 7. I am moving this fix for the 7.x-1.x version. Kindly check the same issue is happening in 2.x version.
arunkumark → made their first commit to this issue’s fork.
arunkumark → made their first commit to this issue’s fork.
Created MR from #12 patch against Drupal core 11.x branch.
arunkumark → made their first commit to this issue’s fork.
Moving to works as designed. Feel free to open, if needed any support.
@shalini_jha It seems the pipeline issue was random. After rerunning it, it was resolved. I also verified the file; it was irrelevant to the change made.
arunkumark → made their first commit to this issue’s fork.
@james.williams
I made a small change in the Cache dependency for the Breadcrumb. To handle the invalid Breadcrumb exception. Kindly check is the made will resolve your issue.
Currently moving to Needs Review.
arunkumark → made their first commit to this issue’s fork.
Created drafted
Change Record →
. Feel free to update the change record if needed.
https://www.drupal.org/node/3484054 →
As per the comment, I added a test case to check the unique class for the multi-field value. Moving to NR now.
arunkumark → made their first commit to this issue’s fork.
arunkumark → made their first commit to this issue’s fork.
arunkumark → made their first commit to this issue’s fork.
Seems like a false positive moving to NR.
arunkumark → made their first commit to this issue’s fork.
Resolved the Test case failures.
Created the Draft Change record for the issue. Feel free to edit the description. The screenshot needs to be updated.
Change Record: https://www.drupal.org/node/3482370 →
arunkumark → made their first commit to this issue’s fork.
arunkumark → made their first commit to this issue’s fork.
Done the backmerge to 11.x
arunkumark → changed the visibility of the branch 3091547-same-alias-nodefault to hidden.
I faced the issue of creating MR against the 11.x branch. Now it is working to update the MR
arunkumark → changed the visibility of the branch 2982582-hookrequirements-doesnt-say-d11 to hidden.
arunkumark → changed the visibility of the branch 2982582-hookrequirements-doesnt-say to active.
I faced the issue of creating MR against the 11.x branch. Now it is working to update the MR
arunkumark → changed the visibility of the branch 3353388-type-error-implode-d11 to hidden.
arunkumark → changed the visibility of the branch 3353388-type-error-implode-fix to hidden.
arunkumark → changed the visibility of the branch 3353388-type-error-implode to active.
arunkumark → made their first commit to this issue’s fork.
Created MR against 11.0.x, Now able to review.
arunkumark → changed the visibility of the branch 2982582-hookrequirements-doesnt-say to hidden.
arunkumark → changed the visibility of the branch 3353388-typeerror-implode-argument to hidden.
arunkumark → changed the visibility of the branch 3353388-type-error-implode to hidden.
As per Comment #4, I have created the Test case for the patch. Verified the patch changes, Seems require manual test for change. The code changed for FormElementHelper.php
, the class used in all form.
breidert → credited arunkumark → .
arunkumark → made their first commit to this issue’s fork.
I did the manual review in my local. Below are the steps I followed,
1. Took the Clone from git@git.drupal.org:project/drupal_cms.git
2. Checkout to the git checkout -b '3479507--tugboat-composer-2.8.0' --track drupal_cms-3479507/'3479507--tugboat-composer-2.8.0'
3. Executed ddev composer install
4. Verified the version, ddev composer --version
Composer version 2.8.1 2024-10-04 11:31:01
PHP version 8.3.10 (/usr/bin/php8.3)
Run the "diagnose" command to get more detailed diagnostics output.
5. Executed ddev composer update
6. Verified the version, ddev composer --version
Composer version 2.8.1 2024-10-04 11:31:01
PHP version 8.3.10 (/usr/bin/php8.3)
Run the "diagnose" command to get more detailed diagnostics output.
Still, the version shows 2.8.1. I verified the website is working but the expected composer version is not applied my local.
Please help me the way tested the correct?
Created MR for the issue. Verified after making the change still the Query parameter was added. Do we required this line?
arunkumark → changed the visibility of the branch 3477609-custom-validation-no-message-fix to hidden.
As per the comment, I made a minor change to the default value in the comment section.
arunkumark → changed the visibility of the branch 3477609-custom-validation-no-message to hidden.
arunkumark → changed the visibility of the branch 3477609-drupalcorevalidationexecutioncontextaddviolation-argument-1 to hidden.
As per comment #29 created MR and done the Unit testing on ProtectedUserFieldConstraintValidatorTest.php
On the file, ProtectedUserFieldConstraintValidatorTest.php will have logic for passing messages and without messages for the Violation. So any additional test case hope not required.
if ($name) {
$context->expects($this->once())
->method('addViolation')
->with($constraint->message, ['%name' => $name]);
}
else {
$context->expects($this->never())
->method('addViolation');
}
arunkumark → made their first commit to this issue’s fork.
As suggested in #24 rebased the issue fork with latest update.