Applied the patch for the 2.x branch and it works well. Not moving to RTBC since I did not try the 3x branch.
Sounds like it's timing out when it is trying to gather the files to process. Have you tried the drush command?
drush scan-js
drush minify-js
drush minify-js-skip
Confirm that you're using the latest version of https://github.com/matthiasmullie/minify (it's 1.3.73 at this moment in time). If you're not using that version, use composer to update it.
If that doesn't fix it, I would say create an issue at https://github.com/matthiasmullie/minify
There is an option to disable all functionality on admin pages. Would that solve your issue?
It's going to be tough to debug this error without knowing more about the error from your server logs, the webserver type and config, etc.
Based on your description this is the path to exclude - /fullpath/mysite-d10.2.4/html/sites/mysite/.redisOff
Is the base director for Drupal /fullpath/mysite-d10.2.4/? If so the exclusion should be html/sites/mysite/* and not sites/mysite/*. Have you tried that?
slydevil → created an issue. See original summary → .
slydevil → created an issue.
slydevil → created an issue.
Tried to reproduce this with 10.2.3 and 10.2.4 and it works for both. There must be something specific to your site that is causing the issue.
Ping me on the #minifyhtml slack channel if you want to look into it more.
slydevil → created an issue.
slydevil → created an issue.
slydevil → created an issue.
slydevil → created an issue.
Updated the project page.
Yeah, I'll update the project page with some additional details.
The scanner starts at the DRUPAL_ROOT and finds all JS files from the DRUPAL_ROOT and above. Any files below that (other non-Drupal files) would not be included. I believe the scanner will follow symlinks.
Added a patch - let me know if this works for you.
Essentially, I've added a "File Sync" action to the configuration page that allows you to create managed file entries in the file_managed table for every object in the bucket. You'll need to run "Refresh Metadata" before you run "File Sync".
Once you have the files in the file_managed table, you can use in file field or media, but you'll need a file/entity browser.
slydevil → changed the visibility of the branch 3408985-move-existing-google to hidden.
Amazing, so the underlying issue was with Drupal core!
I didn't build anything into the module, but I can look into as a new feature.
@sense-design, I created a minifyhtml channel on the Drupal slack, you can find me there are we can work through this.
@zcht, that looks related to minifyjs and not this module. Please open an issue on that module for that issue.
@sense-design I will try your config and see what happens.
@sd123 not saying that your issue is unrelated, but going to focus on the QUIC error first.
@danthorne are you using http3?
I spun up a test site - https://master-7tjf71h6euc42njvewo8pyv5jvdx0712.tugboatqa.com/ - and I don't see any issues. The latest minifyhtml version (2.0.3) is installed on this test site.
The username/password is 'admin'.
Please visit the test site and let me know if you are still having the issue.
There must be something specific about your site that is incompatible with the module. After searching (I had never heard of this protocol before) this is the top result: https://kinsta.com/knowledgebase/err_quic_protocol_error/. I'm not suggesting that disabling the protocol is the answer as it's default browser functionality, but it could be related to an incompatible browser extension or proxy settings.
If you can provide a copy of the unminified HTML, I can use the module to minify it and see what happens.
I re-installed the module and everything is working now.
I'm also seeing this error when I click on Manage Instances. I have the Smart Date formatter set. Same error, different place in the code:
Error: Call to a member function getOptions() on null in Drupal\smart_date_recur\Controller\Instances->buildRow() (line 235 of /var/www/web/modules/contrib/smart_date/modules/smart_date_recur/src/Controller/Instances.php).
There were no smart date formats. I created one and assigned it in the display settings and everything is working now. Is the module supposed to create a default smart date format?
Really, there should be a message displayed to the user that the smart date format is not set rather than an exception being thrown.
Anyway, thanks for your help.
slydevil → changed the visibility of the branch 3406852-exception-thrown-when to hidden.
slydevil → created an issue.
Are you using composer to add the module?
slydevil → created an issue.
slydevil → created an issue. See original summary → .
slydevil → created an issue. See original summary → .
slydevil → created an issue.
slydevil → created an issue.
Updated the dependency from google/cloud (entire google cloud PHP SDK) to the google/cloud-storage package only. Added a beta4 release with this fix.
Testing the update uncovers another issue:
$ composer require 'drupal/gcsfs:1.0.x-dev@dev'
./composer.json has been updated
Running composer update drupal/gcsfs
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- drupal/core-recommended is locked to version 10.1.1 and an update of this package was not requested.
- drupal/gcsfs dev-1.0.x requires google/cloud ~0.213 -> satisfiable by google/cloud[v0.213.0].
- google/cloud v0.213.0 conflicts with psr/log >=3.
- drupal/gcsfs 1.0.x-dev is an alias of drupal/gcsfs dev-1.0.x and thus requires it to be installed too.
- drupal/core-recommended 10.1.1 requires psr/log ~3.0.0 -> satisfiable by psr/log[3.0.0].
- Root composer.json requires drupal/gcsfs 1.0.x-dev@dev -> satisfiable by drupal/gcsfs[1.0.x-dev (alias of dev-1.0.x)].
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
Unfortunately there is no version of google-cloud-php that can use psr/log and can also use psr/http-message:^1.1 or ^2.0.
In the meantime I need to lock this to Drupal core 10.0.
The version of google-cloud-php package that this module includes is "google/cloud": "^0.191" as you can see here: https://git.drupalcode.org/project/gcsfs/-/blob/1.0.x/composer.json#L18
That version of google-cloud-php package requires "psr/http-message": "1.0.*", as you can see here: https://github.com/googleapis/google-cloud-php/blob/v0.191.0/composer.js...
The latest version of google-cloud-php package requires "psr/http-message": "^1.0|^2.0", as you can see here: https://github.com/googleapis/google-cloud-php/blob/v0.213.0/composer.js...
Looking into the composer documentation, because in my mind composer should choose the latest version (0.213), but there is some explicit language around pre-1.0 versions that is the root of the issue. Because the version of the google-cloud-php package is 0.191.0 and 0.213.0 and the composer json file is using caret notation it's essentially locking the version to 0.191.0 when my intention was to set it to between 0.191.0 and 1.0.0. The caret notation does not work that way but can be accomplished with the tilde notation "google/cloud": "~0.213".
Apologies for the explanation, writting it down has helped me to keep it straight.
I'll play around with the composer config for the module to see if what I've outlined above will work. Stay tuned.
slydevil → created an issue.