Update PHPCS config to match Drupal 11

Created MR
The commit with changes to the core.phpcs.xml.dist was already in the fork, so I have created MR for it.

Pipeline has been passed successfully

🤩 Thanks, @traviscarden — that's wonderful! This is the logical next step after @tedbow's 🐛 CI: use a snapshot of core's phpcs rules as changes in Drupal core will break MRs with limited benefit to module development Fixed 👏

@denist3r There's still lots of phpcs violations — we need this MR to update XB's code to comply with the latest rules. @traviscarden made it easier to create issues like this, but the actual work this MR must do is not yet done! 😅

denist3r → closed merge request !766

Wow, epic progress here, thanks so much, @traviscarden!

I'm quite skeptical/wary of pointless boilerplate though, and seems like we're being forced to add quite a bit of that here 🫠

I'm personally totally in favor of avoiding boilerplate by excluding some rules in XB's phpcs.xml 🤓 I'm curious what your thoughts are on that!? 🙏

traviscarden → changed the visibility of the branch 3511705-update-phpcs-config to hidden.

traviscarden → changed the visibility of the branch 3511705-update-phpcs-config to active.

Prefatory note: Let the record reflect that I wrote a masterpiece of a comment--a work of art, really--that will be forever lost to the sands of time and faded dreams because Drupal.org thought it would be funny to log me out when I hit "Save". Just take my word for it that the following is but a faint reflection of the veritable paragon of literary excellence that was my original composition. To wit...

I'm personally totally in favor of avoiding boilerplate by excluding some rules in XB's phpcs.xml 🤓 I'm curious what your thoughts are on that!? 🙏

My thoughts are good riddance! I'm glad we're in agreement, because I think they're clearly a net negative in test code--added overhead with no benefit whatsoever. Whoever thought they were a good idea may have them along with my pity.

All PHPCS tests pass now. The Cypress tests seem to have failed due CPU/memory issues. I'll restart the job and put this issue into "Needs review" on the assumption that the very minimal changes in this MR couldn't be the cause.

@denist3r, thank you for your contribution! Good catch on your second commit, in particular. I made sure you got commit credit. 🙂

#12: 😭 Hate it when that happens! Tip for the next time, that's worked for me: open a new tab, log in there, and then hit the back button on the form data you just lost.

(By the way: not even Google gets this right! 😬)

My thoughts are good riddance!

😁

P.S.: I'm not a native speaker but I find inconsistent phrasing distracting and annoying, and I sense you're kinda like me with regards to that 🤓😇 So here's a thing I noticed: the issue queue component is called , the codebase uses AutoSave (meaning: two words, not one), but you used autosaved in a bunch of places. What is correct and why? Can you shine your native speaker light on this and make it consistent? 😇🙏 According to https://www.merriam-webster.com/dictionary/autosave, you wrote it correctly, and 📌 Create AutoSave service and HTTP API to retrieve all entities with pending changes Active got it wrong? 😅 But https://en.wiktionary.org/wiki/auto-save#English says it can be either. I'll let you be the judge 😄

Concerning spelling, @wim.leers, ordinarily I go with the primary spelling provided by Merriam-Webster dictionary. If it's not in the dictionary or it has a more domain-specific use, I go with the most authoritative reference I can find or, if there isn't a clear authority, favor the closesst Wikipedia article title.

In this case, I followed the precedent in the nearest code examples, but upon closer inspection of the whole codebase I see we have overall favored the hyphenated form. I've created 📌 Decide between autosave and auto-save and standardize Active to discuss standardization.

Automatically closed - issue fixed for 2 weeks with no activity.