I think the quickest, and most robust, answer here is to set a default list of extensions that include all the files that Gutenberg's default configuration allows. Right now it falls back to core's default list of file extensions. Relying on core for this is bad for a few reasons but mostly these two.
1. Core has multiple lists of default file extensions.
2. Gutenberg's default configuration has blocks that require uploading files of more extensions than core allows.
We cannot do anything about the first problem here but we can solve the second. Currently, if someone does a minimal installation of Drupal and Installs only Gutenberg, and it's dependencies, then they will not be able to use any of the multimedia blocks offered by Gutenberg.
More information on the difference between the Null Coalescing operator ?? and the Elvis (ternary shorthand) operator ?:.
https://www.designcise.com/web/tutorial/whats-the-difference-between-nul...
I pushed up a fix for this on the 3.0.x branch. This bug also exists on 4.0.x-dev
I will be working on a patch next week.
frob → created an issue.
I don't see anything stopping someone from calling warmMultiple manually. Or do you mean in the UI. I the only way I have seen to trigger a warming operation is with the Queue UI module.
Can we add a plugin type or hook for adding authorization options? That should make it easier to manage in the long run.
I have not reviewed the MR but I don't quite get the expected DX here. So far everything this module does is in code. I think it is odd to add configuration to this. You're saying now, after a developer writes a plugin, they will need to go through and set the config for their new method in the UI somewhere?
I think something like that might be a good sub-module if it allows for overwriting the auth options for existing plugins but I would expect to be able to set the allowed auth types in the plugin definition.
Update: I have now reviewed the MR and I see something I had not considered. The Auth type is set for the jsonrpc route so it doesn't make the most sense to have it set on a per method basis, though I do think, maybe, an extra level of method filtering for auth types wouldn't be a bad idea. That is likely out of the scope of this issue.
How would one go about adding more auth types if this MR goes live. I use jwt → when I am using this module and that doesn't seem to be supported out of the box nor does a way present itself to add this as an option.
I don't understand why it would be OR. I am planning on using both.
The DX has been that alternative auth was required to be added through a route alter.
if ($route = $collection->get('jsonrpc.handler')) {
$route->setOption('_auth', ['jwt_auth']);
}
Are you saying that you're adding this as an option in the UI or through the plugin attributes? I would be all for adding this as a configurable option in the plugin.
The only way I was able to recreate this error is when I had a faulty call to hook_library_info_alter that added an array as a dependency.
I'd like a migration guide. Just doing that doesn't actually fix the issues with removing this module. We had to completely rebuild some of the functionality this module offered.
The way this has been handled has been really disappointing. The maintainers of this module should be ashamed. This module still works with Drupal 10.3 but it cannot be installed without some serious issues. I agree we should turn new users away from this module. Mark it deprecated and say no further work will be done here but as it was handled this module actively blocks the upgrade of sites.
In the end, I had to fork this module and maintain a custom version to keep it going. It isn't in the budget to migrate to another stop-gap module just to migrate to core functionality when it eventually comes out.
Here is a patch file if that is how you prefer to work.
I checked against Drush and there doesn't seem to be much difference here, except that the drush version has more options and does more.
https://github.com/drush-ops/drush/blob/151b70439cdacda5b95546ca853f271d...
I'd love to see what is different between this command and drush php:cli
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?