Problem/Motivation
When placing block on a page, you can set the block machine name. But the configuration of this block depends on the theme you place your block in.
On the same websites, if there are multiple themes, you can't place the same block on another theme with the same machine name because it is already used.
Proposed resolution
A best practice would be to prefix block machine name by the machine name of the theme it is in.
For example: block.block.bartik_help.yml
Remaining tasks
- Review patch
- Update core umami and testing modules
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | interdiff-3061184-3-9.txt | 4.51 KB | grimreaper |
| #9 | coder-block_machine_name-3061184-9.patch | 7.24 KB | grimreaper |
Comments
Comment #2
grimreaperHere is a first patch.
It will fail. I can't find why the new rule is not applied.
Comment #3
grimreaperFixed the preg_match pattern that prevents the new sniff to work.
Using YAML::parse() following @klausi recommendations.
Thanks for the review.
Comment #4
grimreaperPostponed until related issues are green.
Comment #5
grimreaperTagging.
Comment #6
alexpottI'm not convinced this rule belongs in coder. I think the core change to add the theme to the suggestions is fine but I don't think we need a coder rule here.
Comment #7
grimreaperIs there a place in Coder to have rules not enabled by default and so people can opt-in for these rules with a custom phpcs.xml config file?
Because at the beginning it is only what I wanted, a rule for custom projects. If people don't want to use this rule, no problem.
I know, for example I encountered someone mentionning it in a presentation at DrupalCon Europe 2020, that there is other people that might be interested in this rule.
If we can avoid having everyone get their one rules in separated packages, I think that may be helpful. If not, fine, I will create my own package.
Comment #8
grimreaperI just found a problem with previous patch.
When the file is a config translation it raises a warning:
It should ignore config translation files.
Comment #9
grimreaperFixing the case of config translation file and updating the code regarding changes in Coder since last patch.
Comment #10
grimreaperChanging to needs review to have some feedback from maintainers.
Comment #11
klausiThanks, can you create a pull request against https://github.com/pfrenssen/coder so that we can see the test cases run?
Comment #12
grimreaperHello,
@klausi thanks for the feedback.
PR created https://github.com/pfrenssen/coder/pull/151
Also have you seen comments 6 and 7?
Comment #13
klausiThanks - I'm also not fully convinced this rule should be in Coder. I don't think people execute Coder on their config sync directory YAML files?
On the other hand I also don't see much harm in adding this rule - if it sees a block.block.*.yml file then it reports on that. Not much that can go wrong with that.
Anyone else that has opinions and wants this?
Comment #14
grimreaperHi,
FYI, I have created my own Composer package to provide this rule, so no more need to place it in Coder.
https://github.com/FlorentTorregrosa/phpcs-drupal
I let maintainers choose of the new issue's status. Should it be considered as "Fixed" or as "Closed (won't fix)"?
Comment #15
klausiThanks, then I'll close this as won't fix for the time being. We can always considers this later again if needed.