I found that this patch can result in a 502 error due to a to large response header.
So use it with care.
To big header issue
When the response header is to large the server will return a 502 and will log something like: upstream sent too big header while reading response header from upstream, client
Possible solution:
Validation before saving as done on another platform.
https://really-simple-ssl.com/instructions/content-security-policy-maxim....
As stated they first check the impact of the content security policy configuration against the server configuration before saving.
Combination with downloads:
When the configuration is just below the maximum it will work on normal pages but in our case resulted still in the `to big header` issue on downloads. Probably due to additional header info in a download like mime-type. Is the Content-Security-Policy really needed on a download? Otherwise the solution might be to not include it in the header in downloads.
Patch for the simple (quick & dirty) solution.
Note that it changes the behaviour of the disable_user_view module.
With this patch `/user/{uid}` will not result in a 403 but will redirect to `/user/{uid}/edit`.
That should not be a problem for security because `/user/{uid}/edit` is still repsonsible for it's own access check.
But for some use cases that might not be the solution where you're after.
As suggested a nicer solution might be possible in UserEditController.php
Floris Vedder → created an issue.
Made a new patch.
The first patch didn't include the necessary properties.
This one does.
Patch to remove the constructor property promotion to keep support for php 7.4
Floris Vedder → created an issue.
@znaeff thanx for your quick response.
I see that the patch that I provided is removed somehow.
So I provide a new patch that includes your solution as well as the check on the array type which otherwise might cause php issues when there are some older settings stored for the cron state.
Floris Vedder → created an issue.
Apparently this part isn't working anymore.
$this->getFieldsHelper()->filterForPropertyPath($item->getFields(), 'entity:node', 'field_domain_access');
So I solved that with a patch.
Basically by changing that to:
$field = $item->getField('field_domain_access');
Keep in mind that the result is slightly different here we only get one field. For more info see the patch.
-- Alternative solution --
I also created an alternative solution.
Where I added an or condition in the filter itself.
$or = $this->query->createConditionGroup('OR');
$or->addCondition($this->realField, $current_domain->id());
$or->addcondition('field_domain_all_affiliates', TRUE);
$this->query->addConditionGroup($or);
In that way the data in the search api stays unmodified.
Downside of this solution is that it's always there and not configurable.
I did an attempt to refactor the patch.
Refactoring of the patch mostly is about moving the additions from xmlsitemap.drush.inc to src/Commands/XmlSitemapCommands.php
But I didn't get it to work.
After that I tested the normal `drush xmlsitemap:rebuild` command which worked well for our scenario.
Number of records in xmlsitemap: 3400
Memory Limit setting: 256M
So the patch seems obsolete for our case.
I also did a test with the #21 patch on the 1.3.0 version of xmlsitemap in combination with drupal core 9.4.8. Expecting that it worked but in my case it didn't. The drush command `drush xmlsitemap-queue-rebuild` wasn't recognized.
Additionally the patch seems not to take entity types without bundles into account. Therefore the patch fails in that case on: $entity_type->getKey('bundle'). I partly fixed that with an $entity_type->hasKey('bundle') check.
Since the patch seemed already broken or at least not working for our scenario with the 1.3.0. version and a recent drupal core version. And since the already available `xmlsitemap-rebuild` command works fine in our scenario. I decided to not further investigate and/or refactor the patch for 1.4.0. With the WIP for 1.4.0 the drush command works, but in my case it didn't fill the queue table.
But maybe for future use or for someone else the WIP is usefull, so therefore it's added with this comment.
As said it isn't ready for (production) usage yet. To apply it as a patch you'd probably have to change the extension from .txt to .patch.