Fails for anon when anon not enabled ($this->request is null).

Hello @liquidcms

Error: Call to a member function getRequestUri()
The getRequestUri performed on request object and returns the requested URI (path and query string).
This has no deal with Excluded domain option which can be empty.
Here is an example with the default VCL povided by module:

As you can see it works as expected. In your case it looks like your request object was empty.... which is weird.
Are your sure that there were no any additional steps done?
Have you tried to clear caches after module was installed/configured?

BR, Alex

If you're going to make a patch. Can you add a debug to see the state of request?
Maybe this will help us to understand the problem and fix it properly.

@shumer, I have followed the instruction and deployed a copy of the default.vcl file with the required modifications.

It does not appear that the issue we are observing is linked to the varnish vcl config. If I leave our previously used varnish vcl in place and enable adv_varnish + configure + drush cr the same error is present... I even remove varnish altogether and got the same error showing up... so, I suspect it is something specific to our site/environment that might be causing this...

We deploy our site on a kubernetes cluster using the drupalwxt helm chart: https://github.com/drupalwxt/helm-drupal

We leverage a varnish pod, nginx pod, redis pods, php fpm pod and a mysql pod.

This won't help you figure out why, but I figured it might be worth noting.

To get the request we're using '@request_stack' service which is recommended way to get the request object.
In case of D9 specfic - my screenshots was done on the 9.3.5 Core.

Interesting moment that this is a Symfony component, I don't think that you overrride it somehow... unless you have somewhere calls to `pop` method from there.

Are you able to check the Symfony\Component\HttpFoundation\RequestStack
we're interested in value of:

    /**
     * @var Request[]
     */
    private $requests = [];

you can debug `push` and `pop` methods to see how the Drupal handle the request lifecycle.
Also can you share the local setup with me? I can try to reproduce the issue to help you with the fix.

Could be in some contrib module i guess.

that's can be our issue. Can you share the list of enabled contrib modules? Composer file maybe?
I'll try to reproduce that and maybe you'll be able to use the module :)

That's fine.
One last thing can you also share
drush pml --status=enabled
so I won't have to enable ALL of them

Thx for the list, I'll try to deploy the project at my local tomorrow,

Question.. the page where you see that error. is it build with the page manager?

@liquidcms, can you try to replace:

$request_uri = $this->request->getRequestUri();

with

use Drupal\Core\Url;
$request_uri = Url::fromRoute('<current>', [])->getInternalPath();

if it works we can prepare proper patch and make a new release.

Hi,

Just kick out stupid purge modules from my project and i got a brand new issue.

Wonderfull

I am so glad that someone got the same error before me.

Btw, the fix purposed in #17 only solve an error to bring another one.

Error: Call to a member function getHost() on null in Drupal\adv_varnish\CacheManager->cachingEnabled()

Like request object is empty, it s logical that every call's to it fail :(

Adding those line at the beginning of the method seems to solve every issue

if(empty($this->request)){
    $this->request = \Drupal::request();
     }

Here 's my full patch btw

diff --git a/src/CacheManager.php b/src/CacheManager.php
--- a/src/CacheManager.php (date 1645106840879)
+++ b/src/CacheManager.php (date 1645106840879)
@@ -450,6 +450,9 @@
*/
public function cachingEnabled() {

+ if (empty($this->request)) {
+ $this->request = \Drupal::request();
+ }
// Check if user has permission to bypass varnish.
if ($this->account->hasPermission('bypass advanced varnish cache')) {
$this->log(RfcLogLevel::DEBUG, 'Cache disabled by Bypass Varnish permission.');

Thanks for helping with this issue guys,

@amaud-brugnon - that was a great idea, actually I was done some research for this issue, looks like we have the same situation with the Forms in Drupal Core...

Anyway, I did a patch that work in Drupal Core way. IF someone of you can test it would be awesome.
In case of success I'll do a new release.

P.S. it works fine at my local setup.

Sorry wrong file was attached.
The proper one here:

Well, it don't see why this may not work.

I will test it tomorow in the morning and i will let you know.

Btw, good work with your module, i love it (i waste so much time to this stupid purges modules)

It works for me.

Perfect, thanks

Btw, good work with your module, i love it (i waste so much time to this stupid purges modules)

Nice to hear :)

Thanks guys for your help on this issue. New release with the fix was published.