The changes in MR 8092 worked great testing them now on a D10.3.6 install. Thanks.
We're still using this in conjunction with the core patch
https://www.drupal.org/project/drupal/issues/2681953#comment-15330315
✨
Allow exposed form to preserve URL query parameters
Postponed: needs info
Had to reroll it for BEF 6.0.6 so attaching patch here.
I've created an MR with a potential solution for this. Basically if there is no known error code then attach the code received from Google to the log message.
I've created an MR with a potential solution for this. Basically if no code matches the 'official' ones then attach the actual code received from Google which could provide more information to devs as to what the actual issue is (as it did in our case regarding the free quota)
I've had to install it recently so took the opportunity to test the patch and the link works correctly.
breidert → credited oldspot → .
We have the same problem on one of our sites - leaving the node edit form page open results in that modal box opening with a 'server error' message.
The network tools show 2, 3, 4 or more successful Ajax resuests to "/node/NID/edit?ajax_form=1&_wrapper_format=drupal_ajax" and then suddenly it will respond with a request that lasts 1 minute and a 503 response (that happens to be our timeout).
I can confirm that we had the same issue with thumbnail url not being present for private videos in the request which meant it would throw a 500 error when loading the media browser and file edit page.
The patch works great.
According to the project page though this module is looking for maintainers which is why i guess this patch has not been committed in the last 4 years since it was implemented.
I can confirm without this extra patch to domain_conf our image styles were not being generated.
Created MR with potential solution. This worked ok in the tests I've made.
I checked with a normal non-image document too and that didn't cause any issues and simply skipped over the deletion since the 'derivative' files don't exist.
The reason I didn't put it in the ImageImport plugin specifically is because you can still import images with the base FileImport plugin (as it was in our case).
I had the same error on a Drupal 7 site so I rolled the above patch including the improvements from #4 into this patch.
Let me know if you prefer raising a separate D7 issue.
We've been experiencing these intermittent issues with URL generation and after debugging the "tokens" hooks being called I realised the field_tokens hook wasn't registered in order to be able to replace some URL pattern tokens.
I then came upon this issue and the patch in MR #42 in comment #17 fixed it instantly.
There seems to be an issue raised by 'Project Update Bot' https://www.drupal.org/project/shopify/issues/3289593 📌 Automated Drupal 10 compatibility fixes Needs review so this one can probably be closed as duplicate?
Had the same issue on a user with a lot of revisions and the patch works great.
After upgrading to PHP 8.1 and latest diff module version I got the exact same warnings.
Can confirm this patch fixes them and can no longer see them.
Thanks
The solution really is to either set the value to Deny or Sameorigin depending on your website’s needs. In our case we just set to Deny.
The proposed resolution above is mainly to help people in the future by preventing them from choosing the broken option.
We’d also have to decide what value to set it to for sites that already have the value set to Allowfrom - should they default to Deny or Sameorigin?