I am unable to test the new version at the moment. However, the test is pretty simple. If you visit `/user/login?destination=internet` then it should break with the OP's error.
To fix this ourselves we patched the `public/modules/contrib/legal/src/Form/LegalLogin.php` file to ensure the destination is valid. It looks like you where leaning toward a solution which involved the redirection service so I didn't submit my patch.
Replace
$redirect = $_GET['destination'];
with
$destination_path = $_GET['destination'];
if (strpos($destination_path, '/') !== 0) {
$destination_path = '/' . $destination_path;
}
$redirect = $destination_path;
Granted
frob → created an issue. See original summary → .
Sorry, I didn't mean to change all the fields.
I ended up going a different direction.
I see, that is what I thought when I read the code. I have a custom entity 'announcement' that doesn't have revisions or a canonical reference. Looks like if I add it to AccessPolicyInformation::isParagraph like this.
return $entity_type->id() == 'paragraph' || $entity_type->id() == 'announcement';
It might make sense to turn isParagraphinto an api that allows developers to specifically add custom entities to the allowed entities list.
I have not tried any of the patches, however, I can confirm that this issue is still present on 3.0.1
That's great. Do they need to show June and December? The dates should still be listed in the tables. How many releases need to be in the chart?
I would only expect the +/-3 months of releases. I could see showing the rest of the D10 release cycle.
That's great. Do they need to show June and December? The dates should still be listed in the tables. How many releases need to be in the table? I will bring this up over in 📌 Template for Core release cycles diagram RTBC
Honestly, all the tables are just confusing. I spent 10 minutes making a gantt chart with Mermaid. The dates are mostly BS in that chart at the moment but it is something we can use to better illustrate what this page is supposed to be saying. If this type of chart is useful to people then I can take a crack at making it accurate. At the moment this is a proof of concept.
https://mermaid.live/edit#pako:eNptUctqwzAQ_JVFZ6toFaemvrW4OcUUmlPBF2Ets...
We could then keep a copy of the mermaid code in an html comment in the doc page and more easily generate a png or svg with the up to date tables. This might be easier than trying to keep a google drawing up to date.
I think I might be experiencing something along these lines as well.
For us storing a value in the browser session is shared when masquerading.
This patch causes issues with D10. I will see about getting an updated patch along soon.
Here is an updated patch that makes this module installable with d10.
Why move to Manage Display if Manage Display is going into core? Why not stay on this module till Manage Display moves into core and then move to what core is doing.
I agree this module duplicates effort but moving isn't an insignificant amount of work.
So everyone had to move to manage display so that everyone could eventually move to core. Am I the only one who thinks its a bit much to upgrade to d10 twice for one module. Especially when, the module works fine with D10 and the migration requires a manual editing of every display mode of every entity?
Why was this marked as wont fix?
@thatipudir I think it is save to say that this will never work on Drupal 9.5
I have also seen this with a recent update to 3.0.1
As far as I can see this isn't fixed with the 3.0.x-dev branch. Maybe it's an upgrade only issue.
I pushed an MR with a new hook for allowing modules to determine if the exemption should happen.
I think I've got it. This isn't about access at all but rather rules surrounding permissions and roles. Instead of a permission being an absolute value of yes or no it becomes an "it depends" type of check.
The reason I linked the other issue is that I could see policy that is checking a value within the entity (or a linking entity) to see if the policy is applied.
Some example scenarios:
- Delete nodes created after a certain date
- Manage nodes that link to a taxonomy or term
Something in core that could depend on this API are the CRUD based own node permissions.
- View own nodes
- Edit own nodes
- Delete own nodes
View published content is another place I could see switching to a policy over a permission.
There is a 13 year old core issue about expanding the Entity Access system to match that of the Node Access system that should be considered here as well. ✨ Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() Needs work Work has been done on that issue and a contrib module has been created to provide the functionality described there. https://www.drupal.org/project/raft_entity_access →
Curios about the differences between RAFT Entity Access and Flexible Permissions → .
With regard to 🌱 [Meta, Plan] Pitch-Burgh: Policy based access in core Active is what is proposed in this issue still a good idea? I would rather we don't have multiple access and control systems hanging around. Maybe once 🌱 [Meta, Plan] Pitch-Burgh: Policy based access in core Active is in core the resolution here would be to deprecate the existing node access rights system rather than expand it into entities. Or maybe break node access and entity access into a node sub-module. Having multiple systems that do the same thing is generally bad DX.
Is there anything stopping this from getting committed? It has been RTBCed and rerolled for over 3 years.
More can probably be added but this should do for now.
I have add a Makefile with a validate target that can be used to validate the php.
I absolutely agree. I am not sure how we got here either. Maybe at some point updb was run before cim.
I dunno, that patch is just a template. Anyone could override the template in their theme.
I don't know what you mean by "Complete."
Drupal 9 will not get any CKEditor 5 updates, because Drupal 9.5.x is the last minor version for Drupal 9.
I am not quite sure I get this. If the fixes come before EOL of Drupal 9 why wouldn't 9.5 get the fixes? I thought 9.5 was a part of the CKE4-5 upgrade path for D10
Your branch doesn't have any changes. Looks like all that needs to happen is changing this line https://git.drupalcode.org/issue/ace_editor-3284429/-/blob/3284429-js-lo... to look for the first wrapping div.
I ran into this bug when trying to use the ace editor in layout builder.
Is there a reason we don't just attach it to the nearest wrapping div element?
Any way to get permission to use their https://github.com/php/web-php/blob/master/images/supported-versions.php script to generate an svg for this graphic?
Updated IS
Is this really fixed by https://github.com/ckeditor/ckeditor5/issues/13777? It looks like that issue is only about table based elements.
Looks like we are still waiting on:
https://github.com/ckeditor/ckeditor5/issues/13341
https://github.com/ckeditor/ckeditor5/issues/11577
Both are needed to close this issue.
Whats the timeline for rolling this into core? Will it be in the next version of 9 as well?
I think this is more of a Legal module issue. Here is a link to the issue in the legal module https://www.drupal.org/project/legal/issues/2638224 🐛 Add exemption api to allow a Masquerade module exemption Needs review
Instead of exempting based on some arbitrary rule, can we add a hook that allows a module developer to define the circumstance?
I would expect that with Modern Drupal's caching system we could probably take care of 70% of the performance issues of doing what is proposed in #231
Drupal is already logging 404 errors and login request errors so why not log jsonrpc request errors?