🇦🇺Australia @acbramley

As per above

griffynh → credited acbramley → .

Congrats to everyone that worked hard to get this over the line. This is so exciting!!!

This popped up again in BSI. Is this still an issue?

Thanks so much for getting this across the line.

Some projects have adopted the case-sensitive standard already, so a revert creates work again for them.

This was the stance just days after the change was committed. Now we've seen how many more people it's affecting. I think it's safe to say it would have been easier for majority of people to revert this change then. Even now it may still be. Commits are easier to revert than having to phpcbf all of your contrib modules for reasons already explained above.

That's probably due to the fact that layout builder automatically (and blindly) adds fields to layouts even if the plugins don't exist. There's an issue for stopping that too

My changes were following what core was doing, we don't need to strip newlines between html tags for the most part. The test changes are necessary unless we hugely refactor them as well which should be done eventually but isn't required since we can just regex instead

Some suggestions in this slack thread about how to resolve this https://drupal.slack.com/archives/CGKLP028K/p1727992456929179?thread_ts=...

Needs back porting

Given the IS mentions this may not be an actual issue, the amount of time since work has been done on this issue (8 years), and the fact there's been no update since #24 I'm going to close this as outdated.

Please feel free to reopen with the requested information.

Confirming #5 my IDE happily follows all of those methods.

2) Drupal\Tests\webform_ui\FunctionalJavascript\WebformUiElementJavaScriptTest::testElement
TypeError: c.isArray is not a function

This is a random fail and is coming from select2 CDN javascript... I'll see if there's a way we can stop this interfering in completely unrelated tests.

Looks like I missed credit on this one

Getting to the tail end of these failures.

WebformClientSideValidationJavaScriptTest is still failing locally with a javascript error. When reproducing this in the browser the error is:

Can't set value before init

Debugging into this it's coming from Drupal.behaviors.states so I'm assuming something has changed in that API that either webform or clientside_validation needs to fix.

The filter format failure is going to need some thinking

3) Drupal\Tests\webform\Functional\Access\WebformAccessFilterFormatTest::testFilterFormatAccess
Behat\Mink\Exception\ExpectationException: The string "webform_default" appears in the HTML response of this page, but it should not.

In https://git.drupalcode.org/project/webform/-/merge_requests/254/diffs, webform_filter_format_load was added which doesn't seem to get invoked on D11. All this is doing is hiding the default webform filter format on the filter format overview. I'll do a bit more debugging but we may need an alternative solution (e.g override the list builder or something more robust).

I've reset the branch behind some of the commits that were moved out, and then merged 6.3.x in. Much less changes now!

MR needs to be against 2.x

@jrockowitz what are the computed fields you're referring to?

That's really strange, I see what you mean but I don't understand how that could be the case considering tests are self isolated (each test case spins up a fresh Drupal installation and tears itself down)

Test failures are solved by 🐛 Fix Optional parameter X declared before required parameter Y Active - interesting that they fail the pipeline with concurrent enabled.

Few more:

📌 Enable concurrent phpunit Active
🐛 Remove/replace deprecated #drupal-off-canvas selector Active
📌 Fix test module package versions Active

acbramley → created an issue.

acbramley → created an issue.

This can be rebased once 🐛 Fix Optional parameter X declared before required parameter Y Active and 📌 Enable concurrent phpunit Active are in.

acbramley → created an issue.

Moved optional params issue into 🐛 Fix Optional parameter X declared before required parameter Y Active

acbramley → created an issue.

@liam morland legitmate issues, sure, but making phpstan green in CI is not required for D11. The branch also needs a rebase with HEAD.

Tests are green!

Going to start splitting some of these changes into separate issues to make this more manageable.

Modernizr deprecation has moved into 📌 Remove modernizr dependency and code Active
Twig spaceless deprecation has moved into 📌 Twig spaceless filter is deprecated Active

acbramley → created an issue.

acbramley → created an issue.

I would recommend holding off on all of these pipeline fixes until the D11 branch is merged. Otherwise we're going to have major conflicts which will be very hard to manage.

I would recommend holding off on all of these pipeline fixes until the D11 branch is merged. Otherwise we're going to have major conflicts which will be very hard to manage.

I would recommend holding off on all of these pipeline fixes until the D11 branch is merged. Otherwise we're going to have major conflicts which will be very hard to manage.

Needs a reroll into an MR.

Agree with #15

Please feel free to reopen with other ideas if appropriate.

Releases are published.

poker10 → credited acbramley → .

Over a year since PMNMI, closing.

Please reopen with more information if this is still an issue.

Pushed this along a bit. Still needs work to get tests passing.

acbramley → made their first commit to this issue’s fork.

phpunit failure seems unrelated

acbramley → created an issue.

Needs to be in an MR and tests would be nice.

All development should be against 2.x

This also seems like a feature request.

I've pinged several maintainers (all the ones I could find in slack) here https://drupal.slack.com/archives/C1BMUQ9U6/p1727322868231979?thread_ts=...

acbramley → changed the visibility of the branch 2.x to hidden.

acbramley → made their first commit to this issue’s fork.

Needs a reroll on 11.x on an MR.

It's been over a year since #7, closing as cannot reproduce

If this bug is still valid, feel free to re-open with steps to reproduce from a clean Drupal install.

No response unfortunately, I haven't pinged anyone directly though. There are 13 maintainers on this project, has anyone tried contact forms or direct messages?

I've got something that works! Thank you @el7cosmos for showing me the Quality Tools > External Formatters setting.

Steps to setup code formatting on save:

1. Go to PHP > Quality Tools. Select "PHP Code Beautifier and Fixer" (this seems to run phpcbf)

2. Go to Tools > Actions on Save. Tick "Reformat code" and choose PHP files (or others if you want). Make sure Whole file is selected, changed lines doesn't seem to work properly).

Now when you save, it will effectively run phpcbf which seems quite fast and will fix up incorrectly ordered use statements, as well as other stuff for you.

This will still have issues with contrib development as per above, but is a nice stopgap.

Latest commit fixes composer issues with next major and they're all green!

Just realised I reviewed the wrong MR yesterday 🤦‍♂️

I've reached out on slack to see if any maintainers can comment.

A workaround is to install the Drupal coding Standard in phpstorm with newest Coder, then the use statements will be ordered correctly.

I tried this and it did not work. The only thing I can think of is people have phpcbf running on save which of course would fix it but as per #78 is not always going to work.

Left some comments, it seems like almost all of the changes in the xmlsitemap.module file could be reverted.

This was also mentioned back in #62 - PHPStorm users are essentially now forced to disable Optimise imports which is quite a shame...

Developing contrib is going to become more cumbersome as well since phpcbf is not always runnable on contrib (e.g if it doesn't have a committed phpcs.xml file).

This issue came up in BSI triage. There hasn't been a comment here in almost 6 years. Because of this, I'm going to close this as outdated due to the time it has been since the last comment. It does seem like we still add a field in https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views... but only if one is passed in.

If anyone thinks this is still a bug that needs fixing, please feel free to reopen.

I'm closing this as it does seem likely a duplicate as per #6.

Please reopen if this is incorrect.

acbramley → changed the visibility of the branch project-update-bot-only to hidden.

Can we also please update the default branch to 2.x?

acbramley → made their first commit to this issue’s fork.

Would be good to get this committed, nice n simple fix.

@quietone yes that is different, PHPStorm has a built in "Optimise imports" function which, on save, will sort use statements. This is not case sensitive from my testing.

#48 doesn't seem to be correct, I've got a bunch of files failed on Diff module that have been sorted via PHPStorm. E.g

use Drupal\Core\Url;
use Drupal\node\Entity\Node;
use Drupal\node\Entity\NodeType;
use Drupal\Tests\views\Functional\ViewTestBase;

If I reorder these with case sensitivity, and then run PHPStorm's action, it will put them back like this. This is going to cause major headaches for people using storm.

acbramley → created an issue.

Rolled into MR, still NW based on #78

Needs a reroll onto an MR.

It's been over a year since this issue was set to PMNMI, it's very likely other issues were similar to #18

I'm closing this for now, if anyone is still having this issue with valid libraries.yml files, please reopen with steps to reproduce.

Thanks!

We have 3 patches, 8 branches, and 6 MRs on this issue. That's basically impossible for anyone to review or know what to contribute to. Can we please get these cleaned up and documented in the IS?

acbramley → changed the visibility of the branch 11.x to hidden.

acbramley → changed the visibility of the branch 10.2.x to hidden.

+1 for D

Opened ✨ Allow users with administer users to see Roles tab via a setting Active as this caused a regression for us.

acbramley → created an issue.

This has been in PMNMI for over a year therefore I'm closing it as cannot reproduce based on #15

Please feel free to reopen with steps to reproduce from a fresh Drupal installation.

Hmm I removed the custom validators but it looks like they are needed for this "per form" file size limit... not really sure how to manage that without a decent amount of rework.

The file tests are failing on next major due to
The "webform_file_validate_extensions" plugin does not exist.

This validator is added in WebformManagedFileBase. I don't know the background as to why this exists, it only seems to be used to support comma delimited extensions (in webform_preprocess_file_upload_help)

Please use dependency injection for any new code. I know there is a lot of use of \Drupal:: currently; let's not add any more.

That's in procedural code, can't use DI there.

Bit confused why you'd split up different file validator fixes, they are all consistent. There is no use of file_validate() in the project.

It is the standard gitlab template with some modifications.

I was able to reproduce via the steps in the IS and got some test coverage going for this bug. Obviously the fix still isn't working (since it's breaking existing tests) but this'll give us something to test against (TDD :))