I started a MR from the latest patch and added back some argument types that were unnecessarily removed.
dieterholvoet → made their first commit to this issue’s fork.
Drupal\role_delegation\Access\RoleDelegationAccessCheck exists specifically for the /user/%/roles page, which should not be accessible when the user can manage roles through the user edit form, hence the administer users permission check.
I think a better fix would be to stop using this access check for the action plugins, since they aren't strictly related to the /user/%/roles page.
What if a user only has administer users? They cannot edit roles on user/UID and they do not have access to user/UID/roles.
I was able to reproduce the issue, but only when the 'User name and password' field is hidden from form display. The issue seems to be that the role_change field is assigned to the account group which is hidden, which in turn hides the role_change field. I'm not sure why this $form['role_change']['#group'] = 'account'; is necessary, but removing it doesn't seem to change anything, so let's do that.
I'm reverting the change in RoleDelegationAccessCheck because it's not necessary. Users without the administer permissions permission can still manage roles through the edit form, because of this separate role_change field.
The test fail is expected: visiting /admin/structure/webform/manage/test_element_access/element/textfield_access_property/edit gives a 403 because in the textfield_access_property element of the test_element_access form, #access is set to FALSE. Not sure how you want me to proceed here. Should we remove the test_element_access form from that test?
You can ignore 3364421-add-support-for-14.x, that's for an upcoming Drush version where Drush commands will extend Symfony Console commands. I'll open a new issue for that at some point. I accidentally pushed these changes to 3364421-add-support-for as well, that has now been fixed.
No it's not, all what was done is the type of the $dependencies property was changed. But as I said before, the structure of the core dependencies array is more complex than just an array of module names. This will break whatever core intends to do with that array, because we're putting stuff in there in the wrong structure.
I reviewed the code, tested it on an existing website and validated the new config using Configuration Inspector → . Looks great! I'm going to leave this a couple weeks for other people to test and unless anyone objects I'll merge and release it after.
This should probably be made optional, through a setting or by moving it to a separate submodule, because by introducing this we introduce the risk of a lot of blurry images being generated unnecessarily, impacting site performance.
dieterholvoet → changed the visibility of the branch 1.0.x to hidden.
dieterholvoet → made their first commit to this issue’s fork.
Never mind, I was able to make it backwards compatible. The one module dependency constraint remains though.
The current MR doesn't work. The structure of the core dependencies array is more complex than just an array of module names. I pushed an alternative proposal to the MR. The only limitations are that current field enhancers will need to be updated (inevitable I think) and that only one module dependency per plugin can be added.
dieterholvoet → changed the visibility of the branch 3561878-readonly-property-redeclaration to active.
dieterholvoet → changed the visibility of the branch 3561878-readonly-property-redeclaration to hidden.
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → made their first commit to this issue’s fork.
dieterholvoet → made their first commit to this issue’s fork.
The MR isn't ready yet, so for now nothing is being released.
I'll go ahead and merge this. I suggest you open follow-up issues for any other improvements that seem necessary to you.
I removed the entity cache reset and I updated the project description. I also tested the changes, seems to work.
there's a chance that the page might timeout, leading to an incomplete queue
Did you actually encounter this issue or is it hypothetical? Since it's not really necessary to load all these entities, we could also query the database tables directly and create queue items based on the results of that. That would be fast enough so we don't have to worry about timeouts.
New admin UI allowing users to specify entity types within the allowed pathauto configurations to queue up.
I'm open to any MR's implementing this, but I think if we could speed up the queueing process, this wouldn't be that important.
I would like the pathauto changes to be somewhat instanteneous after making changes, so I think we can explore one of the solutions specified in this drush issue
I created Drush Queue Run All → , I use that command together with the example systemd config and the install-systemd-service.sh script to install the service. But all that is not really the responsability of this module, we could point people in the right direction in the documentation, but that's it.
I fixed the automated tests and code style issues, I'm going to go ahead and merge/release this.
FYI this error is still appearing in logs every now and then:
Compile Error: Cannot redeclare class Drupal__Core__Entity__Sql__SqlContentEntityStorageTrash6936a8faddf9d (previously declared in /var/web/vd32004/deploy/shared/web/sites/default/files/php/trash/Drupal__Core__Entity__Sql__SqlContentEntityStorageTrash6936a8faddf9d/s4DjUG_7nC2Ip3vqkmzrN1DPbOOWBzHxqPUcTEx5QyE.php:8)
I also saw it happening once myself, when loading a page while config was being imported. I'm going to try to add this to settings.php, hopefully that fixes it:
$settings['php_storage']['trash']['class'] = \Drupal\Component\PhpStorage\FileStorage::class;
That should make sure that classes with the same class suffix are always stored in the same file. The MTimeProtectedFileStorage protects against "rogue" upload scripts that take filenames from $_GET, so it shouldn't be necessary in this case.
I merged 11.x into the issue branch and moved the change to the new Drupal\node\NodeBulkUpdate class.
dieterholvoet → made their first commit to this issue’s fork.
This is quite opinionated and will change the way submissions are outputted for existing users of the module, possibly breaking workflows. I think a solution in the direction of ✨ Support tokens Active would be a better idea.
Seems like I hadn't enabled issue notifications yet for this project, I did now. I'll review your patches in the coming week.
I added an extra warning for users proxying the script.
I added support for the new snippet format in the MR, could you test it? You'll need to update the module configuration at /admin/config/services/plausible.
@Dieter, "they'll"? But they already have, as shown. The module doesn't work any more...?
You're telling me that the snippet that's currently being output doesn't work anymore? Because it does still work on all my projects. Maybe Plausible keeps track of what sites are using what version of the snippet and only projects created before the new snippet can use the old snippet.
In that case you're right, this is more urgent. I found this upgrade guide: https://plausible.io/docs/script-update-guide
Did you test the latest changes in 2.x-dev? It was changed so that entity type keys are only added when their relevant settings are turned on, so the changes in the current MR shouldn't be necessary.
Seems like a duplicate of 🐛 Error after upgrading 2.0.0-alpha2 to 2.0.0-alpha3 Active .
I rebased the issue branch. @gxleano feel free to share any doubts you have about this MR
Let's add support for Taxonomy Enum at the same time after ✨ Add helper method to get enum instances of a multiple field Active lands.