Account created on 12 February 2007, almost 18 years ago
#

Merge Requests

Recent comments

🇷🇴Romania abautu

This is the correct patch for 10.1.81 (the previous one was for 10.1.64).

🇷🇴Romania abautu

This is the correct patch for 10.1.81 (the previous one was for 10.1.64).

🇷🇴Romania abautu

I confirm #10 worked for me (applied to date_recur module).

🇷🇴Romania abautu

#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.

🇷🇴Romania abautu

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.

🇷🇴Romania abautu

Same patch as #5 but with some whitespace fixes AND patch paths fixed.

🇷🇴Romania abautu

I attached a patch with the same fix, but also the tests for this use case.

🇷🇴Romania abautu

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.

🇷🇴Romania abautu

In addition from changes in #4, there is also a typo that needs fixing or site will crash with fatal error.

🇷🇴Romania abautu

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".

🇷🇴Romania abautu

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).

🇷🇴Romania abautu

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"
            }
          }
        },
🇷🇴Romania abautu

Patch from #36 failed to apply to dev. I updated it here.

🇷🇴Romania abautu

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.

🇷🇴Romania abautu

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).

Production build 0.71.5 2024