DDEV is the official local development tool of Drupal. And like Drupal, DDEV depends on the support of the open source community.| Comment | File | Size | Author |
|---|---|---|---|
| #2 | cont-module-block-exclude-pages-needs-to-add-exclamation-to-front-urls-3375092-001.patch | 1.26 KB | jcontreras |
Issue fork drupal-3375092
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
jcontreras CreditAttribution: jcontreras at Texas Creative commentedComment #3
cilefen CreditAttribution: cilefen as a volunteer commentedComment #4
jcontreras CreditAttribution: jcontreras at Texas Creative commentedSorry, this was supposed to be a pplied to 10.1.x version
Comment #5
cilefen CreditAttribution: cilefen as a volunteer commentedSee https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-...
Comment #6
larowlanCan we get some detail about what the issue is here?
Comment #7
jcontreras CreditAttribution: jcontreras at Texas Creative commented@Iarowlan -
Starting Drupal 10.1 there are some constraints added to pages settings in blocks, that only allow strings "
<front>" and anything beginning with a forward slash "/", there for limiting the use of this settings section. Block Exclude Pages module uses a "!" at the beginning of URLs on pages settings to exclude some pages when a wild card is used.This is to try and figure out a solution to fix the issue https://www.drupal.org/project/block_exclude_pages/issues/3372696
Comment #8
cilefen CreditAttribution: cilefen as a volunteer commentedWhat is the core issue that introduced the behavior change?
Comment #9
jcontreras CreditAttribution: jcontreras at Texas Creative commented@cilefen -
in /core/modules/system/src/Plugin/Condition/RequestPath.php
Comment #10
jcontreras CreditAttribution: jcontreras at Texas Creative commentedIf there is a better way to overwrite the URL limitation via the contributed module rather than patching the Drupal core please advise. Thank you.
Comment #11
cilefen CreditAttribution: cilefen as a volunteer commentedUsing git blame, it is this issue. So what you are saying is that module Block Exclude Pages was using some nonstandard syntax for visibility and Block Exclude Pages is now broken by the validation. Correct?
Comment #12
cilefen CreditAttribution: cilefen as a volunteer commented"Non-standard" isn't the right word. It is better to say that Block Exclude Pages invented a syntax that relies on the field not being validated. Is that more correct?
Comment #13
jcontreras CreditAttribution: jcontreras at Texas Creative commentedBlock Exclude pages is been used on a little over 6000 sites, from drupal 7 to now. I came up with that a few years back because there was nothing to meet the need of excluding/negate specific pages. And yes I guess we can say I "invented" that syntax as it was allowed before in the validation making it more flexible and it worked just fine, but now I have no way to fix it other than doing this.
Comment #14
cilefen CreditAttribution: cilefen as a volunteer commentedUnderstood.
Something that would help spot changes like this in the future would be to have automated tests in the module to run against development versions of Drupal Core.
Can you override the validator method in the RequestPath plugin instead?
Comment #15
jcontreras CreditAttribution: jcontreras at Texas Creative commentedI am still kinda new to OOP and overwriting methods. I'll see if I can figure it out.
Comment #16
jcontreras CreditAttribution: jcontreras at Texas Creative commentedI have been trying to overwrite the "validateForm()" method on class Drupal\block\BlockForm in my .module file...
I tried creating an instance of "BlockForm" but I get an error:
ArgumentCountError: Too few arguments to function Drupal\block\BlockForm::__construct()All variables to pass are protected and I can't figure out how to initiate this method..
Any help on how I would go about rewriting all these validations?
Comment #17
cilefen CreditAttribution: cilefen as a volunteer commentedIt would be exceedingly difficult to help, not seeing your code. Anyway, coding guidance is not often provided in the Core issue queue, although it sometimes happens. The place to get timely answers is in #contribute in Drupal Slack and also in https://drupal.stackexchange.com, provided this hasn't been asked in the past—you should search thoroughly.
Based on everything I have seen I am changing this issue to a support request.
Comment #18
hlopes CreditAttribution: hlopes commentedYou can override the condition plugins using hook_condition_info_alter .
Comment #20
samlerner CreditAttribution: samlerner at CivicActions for Centers for Medicare and Medicaid Services commentedI made a fork here before realizing the fix was better suited in the contrib module, not in core.
I added an MR to #3372696: D10 Warning when enabling path with exclusion that uses a hook to change the Condition plugin to a custom one in the module that allows for exclamation points.
Comment #21
niklp CreditAttribution: niklp commentedLittle bit unusual to suggest this perhaps, but I notice that there is another module that does almost exactly the same as this one, altho exposes functionality slightly differently in the UI - https://www.drupal.org/project/condition_path
I also notice that this module is using conditional plugins, so perhaps you could modify this module to work in the same way as that one, whilst keeping the (IMO, slightly better) position in the UI the same?
Comment #22
quietone CreditAttribution: quietone at PreviousNext commentedThis is a support request, which @cilefen has pointed out are better handled outside of the core queue. And a fix has been applied to the contrib module that was reported in use in the issue summary. @SamLerner, thanks for reporting here on that.
I think this is resolved now.