This is the correct patch for 10.1.81 (the previous one was for 10.1.64).
This is the correct patch for 10.1.81 (the previous one was for 10.1.64).
abautu → created an issue.
I confirm #10 worked for me (applied to date_recur module).
#2 worked for me.
I had exactly the same error (using drush 11). I did composer update drush/drush -W
and drush updb
worked after that.
One of the servers that I deployed this patch on is using a web proxy to access internet. Drupal is configured properly (ie. http_proxy_config settings), but the patch from #21 failes to retrieve the files because it uses file_get_contents for HTTP requests. in this patch, I replaced file_get_contents with Drupal::httpClient()->get(...)->getBody()->getContents(), which does the same thing, but uses HTTP proxies as configured in Drupal.
Same patch as #5 but with some whitespace fixes AND patch paths fixed.
Same patch as #5 but with some whitespace fixes.
I attached a patch with the same fix, but also the tests for this use case.
On the patch from #19, I fixed two more issues:
- the library name is addtoany.front (instead of addtoany)
- the path to the static page file was missing a / before the page.js (i.e. addtoany/menu/cached_id/page.js)
I tested this with 1.20 and 2.0 and works well.
In addition from changes in #4, there is also a typo that needs fixing or site will crash with fatal error.
I ran into this issue also, while preparing the upgrade from 9.5.11 to 10. Patch from #3 is the correct _temporary_ fix (should be removed after upgrade), but it declares $catch parameter as bool (while in D9.5 core, it is mixed). Therefore, the update will still crash when patch is applied. I created a new one that replaces "bool $catch" with "$catch".
For me, patch #8 fails to apply via composer (due to 2 lines in info.yml), so I created the attached one (which is essentially the same).
The reason why the module doesn't install even when you apply the patch is that the patch is applied to the module code only if instalation is succesfull (so that Drupal 10 can install the module). However, before instalation, composer checks the module metadata (from https://packages.drupal.org/files/packages/8/p2/drupal/contextual_range_... and finds out the module requires drupal/core:^8 || ^9) and refuses the instalation.
Therefore, you need the patch for Drupal, but you also need this for composer: define a package repository in your composer.json and tell composer this package works with drupal/core:^10. Add this lines inside repositories
, above your the https://packages.drupal.org/8 repository.
{
"type": "package",
"package": {
"version": "1.0.0",
"dist": {
"type": "zip",
"url": "https:\/\/ftp.drupal.org\/files\/projects\/contextual_range_filter-8.x-1.0.zip",
"reference": "8.x-1.0",
"shasum": "0e7d74a9b6762b2aec881ae0580433884661972f"
},
"type": "drupal-module",
"name": "drupal\/contextual_range_filter",
"require": {
"drupal\/core": "^8 || ^9 || ^10"
}
}
},
Patch from #36 failed to apply to dev. I updated it here.
I have prepared and tested a smaller patch. It doesn't offer all the features from the previous patches, but I'm adding it here in case it helps anyone.
It does only these things:
- enables chunking on all dropzone elements (using default chunk size of 2M from DropzoneJS)
- fixes missing response in the succes callback (in 5.7, the response parameter of success callback is an empty string for chunked uploads; this has been changed in 5.9 to be consistent between chuncked and regular uploads)
- fixes the upload callback to correctly write/append each chunk.
I tested it by uploading files from 5 to 200MB on a PHP server with 20MB upload limit.
I am using this patch on some projects that use version 7 alpha3 and alpha4 of the module. Recently I noticed that when accessing some of the /admin/config/search/search-api/index/index_name pages (for large indexes) I was getting 500 errors, caused by PHP reaching its memory limit. After debuging, I found out that Search API themeing function (template_preprocess_search_api_index) does a query with offset 0 and limit 0 to check if the search index is alive. However, this patch turns that 0 rows limit into 10000 and that simple stats page tries to load tons of data.
I updated the patch to use !isset instead of empty. This will make a difference between Search API (using limit 0) and Display all page (using no limit, i.e. NULL).