Patch in #32 works
That makes sense, thank you. I'll give it another try from the dev branch.
This looks good, although I'm getting this message now:
Missing dependencies: In order to rate-limit regular traffic at the ASN-level, you need to install the GeoIP2 PHP API.
I did download the a test ASN database, GeoLite2-ASN-Test.mmdb,
Full message is:
CRAWLER RATE LIMIT Enabled
- Configured to use memcached backend.
- Rate limiting bot/crawler requests at the bot/crawler-level. 100 requests allowed per bot/crawler over a 600-second interval.
- Rate limiting regular traffic requests at the visitor-level. 200 requests allowed per visitor over a 1400-second interval.
- Rate limiting regular traffic requests at the ASN-level. 600 requests allowed per ASN over a 600-second interval.
- Issue(s) detected that prevent rate limiter from functioning. In order to prevent fatal errors rate limiting has been disabled. You must fix all the errors or disable the Crawler Rate Limit.
- Missing dependencies: In order to rate-limit regular traffic at the ASN-level, you need to install the GeoIP2 PHP API.
#5 π¬ Available Updates Page - No update information available. Closed: duplicate worked for me on a test site
darrell_ulm β created an issue.
For me it was solved by this:
https://www.drupal.org/project/drupal/issues/3410301#comment-15370309
π
Deprecate system.performance stale_file_threshold
Fixed
drush cdel system.performance cache.page.use_internal
drush cdel system.performance stale_file_threshold
drush cdel system.performance reponse
Hmmm, #43 not working here for Drupal 10.1.n, will keep looking, but thanks for the update, it make work for some.
Seeing a very similar error but only when run for the command line drush cron.
The error does not appear when running it from the web interface cron.
Type | search_api
Message | Symfony\Component\HttpFoundation\Exception\SessionNotFoundException while trying to render item entity:node/1000:en with view mode default for search index Default Solr content index: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of vendor/symfony/http-foundation/Request.php).
While the patch above applies, seeing this error when trying
Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Input value "edit" contains a non-scalar value.
Could this actually have been a change to Drush version 10 or 11 ? Running Drupal 10.5, or I don't think this was always the case, possibly Drupal 10.1.1, the error seems to be more with Drush than Drupal.
permission groups for Ubuntu used for file directory only are
www-data:siteuser
as per
https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... β
like:
drwxrwx--- 7 www-data greg-group 4096 2008-01-18 11:02 files/
drwxr-x--- 32 greg-user www-data 4096 2008-01-18 11:48 modules/
-rw-r----- 1 greg-user www-data 873 2007-11-13 15:35 index.php
When new JS and CSS files are created rather than keeping these permissions
drwxrwx--- 7 www-data greg-group 4096 2008-01-18 11:02 files/
the permissions are re-written to
drwxrwx--- 7 www-data www-data 4096 2008-01-18 11:02 files/
and this could be because the js and css directories appear to be deleted completely before they are repopulated. this can be seen after doing a directory permissions sweep and then running
drush cr
once.
I notice that when running Drush from webroot as as the www-data user, drush cr works fine as would expect, but still changing the js and css directory permissions, likely because Drupal now deletes the js and css directories, and they are recreated as:
www-data:www-data
for the user groups.
sudo -g www-data ./vendor/bin/drush cr
Drupal cache clear works fine.
However, drush as the non www-data user does not work once the js and css directories have been populated with the
www-data:www-data
user + group.
$ drush cr
[warning] unlink(.../sites/default/files/css/css_bdWeT0sNlgIx6Vhnvg713u12RoNiC0AwD6fXvvLan-8.css.gz): Permission denied FileSystem.php:124
In FileSystem.php line 326:
Failed to unlink file 'assets://css/css_bdWeT0sNlgIx6Vhnvg713u12RoNiC0AwD6fXvvLan-8.css.gz'.
Hope this gives some insight, as it definitely works back in Drupal 9.
Did anyone figure out how to fix the trackID error without directly changing the vendor .php file?
Thanks for the fix in
#137
π
4.0.0-alpha1 release compatible with D10/Symfony6
Fixed
as it did work.
There may be a config.php or authsources.php parameter that is missing that is causing this?
Back-port to D7 for this could be nice for legacy sites. If I get a chance, I'll take a look.
Seeing this error recently for Drupal 10 branch when running
drush sapi-i
for search_api_solr
Tested https://www.drupal.org/project/simplesamlphp_auth/releases/4.0.0-rc1 β in a project. Worked for me.
Tested as working, after adding the 'entityID' param.
That may be true, but it will be an upgrade path, and due to similar code dependencies, other Drupal modules also require Drupal 10 for the upgrade. Testing could be done on a dev or test site beforehand.
Also seeing the same thing when applied in dev environment.
Patch provided here, works for me and fixes how email nameID works.
darrell_ulm β created an issue.