🇵🇱Poland @shumer

That string is used as additional key to hash you cache ID. This can be any string value, you can use any random string you want.

Hey @umekikazuya I'm going to apply the patch and create a new release this weekend

In Drupal, rendering a block programmatically using the view() method on the block entity's view builder bypasses the usual access checks unless explicitly handled. This behavior occurs because rendering an entity directly focuses solely on generating its display output and does not automatically invoke the access checks associated with the block's entity or plugin.

To ensure the access checks are performed, you need to use the access method of the block entity before rendering it.

Hello @lindsay.wils I've just tried to setup a fresh install of Drupal 10.4 + latest configPages with the patch provided

the patch does work for me. See the screenshot I've included the permission setup + screen of anonymous + authorized user. Can you please share some infor about your setup (the caching setting or modules enabled)? Maybe that will help us to identify the issue you have right now.

Merge Request - https://git.drupalcode.org/project/adv_varnish/-/merge_requests/22/diffs
I did an update to fix the issue there.

@reweb you can try the chenges from the MR that fixes the isuue for me

Thanks for the update. I was in middle of my local setup to check that :)
Closing the issue then.

That's an interesting request, I never had a setup like that so it's hard to provide proper details here (unless someone who used that module with that setup can share knowledge)

I can only imagine that Drupal can talk to Varnish avoiding the PROXY in case you can tell Varnish to bin the additional port to support that

varnishd \
    -a :80 \
    -a :8443,PROXY \ # Existing PROXY-enabled port for Hitch
    -a :6087        # New port for direct connections from adv_varnish
    -f /etc/varnish/default.vcl \
    -s malloc,2g

You should not need to hack Guzzle then, Drupal should be able to reach Varnish on that port.
(But that's just my theory)

@reweb, so all works for you D10 and D11? I'm thinking of merger that PR and make a new release. Looking for confirmation that that works not only for me.

What type of freezes? Like a page timeout? Can you please share PHP error with me.

@reweb
try the udpated branch it works for me both D10 and D11

shumer → made their first commit to this issue’s fork.

greggles → credited shumer → .

Hello @darren.fisher thanks for ping me on that. Totally forgot about D11 launch. Will make a new release today.
cc @MaxPah

The way the entity is loaded here is not like how other entities in Drupal work. The reason for that is that we have Context enabled, so while the entity is being loaded, we need to evaluate which one exactly we need. We can't cache that enity between requests as the context might be different. In case of specific need you can cache the load in the custom code.

When it comes to a static cache we can add that option, but I'm still curious about the use case. I haven't seen anything like this before, despite I'm using that module since 2014... Can anybody from this topic provide me some info about the use case when this performance degradation appears?

Hello, at your screenshot I see you're trying to use numeric ID of the Config page to render, which won't work with that module. You need to provide a ConfigPage ID which is basically machine name of the type:

and then use it in the View config:

then it will be renderd in the view:

The fun fact, we had no reports since the last release... which was a while ago :)
Let me publish fixed version

Hey @andreic,

I've tried to reproduce the issue by the steps proided in the description and had no luck

Can you please provide more info? Some trace of the error, or maybe the composer.json file (in that case I can test with your Drupal setup)
as it might affect on module functionality.

BR, Alex

I don't think that this is appropriate fix that we can commit. You can add multiple lines in the textarea, which purger won't handle.

shumer → made their first commit to this issue’s fork.

shumer → made their first commit to this issue’s fork.

Hey folks!
@heddn and @deviantintegral would you be able to try the code from the PR? It solves the issue for me.

The other question I have, what was the use case for the ConfigPages for both of you? I mean I can hardly imagine the situation like this, so I'm interested in what are you doing with this module? Hope that will help me to avoid issues like that in future releases.

Thx

shumer → made their first commit to this issue’s fork.

Merged, @Aron Novak thanks for the fix.

Hey guys!

We can't just increase hash and hoping for the best.
It will decrease duplicate x tag but not enough.

That's correct. The X tag was initially added to avoid issues with the too big header exceptions.

We can think of mirroring the solution from Acquia Purge, something like a

  /**
   * Create a hash with the given input and length.
   *
   * @param string $input
   *   The input string to be hashed.
   * @param int $length
   *   The length of the hash.
   *
   * @return string
   *   Cryptographic hash with the given length.
   */
  protected static function hashInput($input, $length) {
    // MD5 is the fastest algorithm beyond CRC32 (which is 30% faster, but high
    // collision risk), so this is the best bet for now. If collisions are going
    // to be a major problem in the future, we might have to consider a hash DB.
    $hex = md5($input);
    // The produced HEX can be converted to BASE32 number to take less space.
    // For example 5 characters HEX can be stored in 4 characters BASE32.
    $hash = base_convert(substr($hex, 0, ceil($length * 1.25)), 16, 32);
    // Return a hash with consistent length, padding zeroes if needed.
    return strtolower(str_pad(substr($hash, 0, $length), $length, '0', STR_PAD_LEFT));
  }

and make the $length configurable. So in case of the collisions you can configure the hash length as you wish.

DamienMcKenna → credited shumer → .

Glad that it worked!

Hello,
you almost did it, the context in Config pages a bit more complex then just a raw value:

The code example is here:

    $bundle = 'test';
    $config_pages = \Drupal::service('config_pages.loader');
    $config_page_ast = $config_pages->load($bundle, 'a:1:{i:0;a:1:{s:8:"language";s:3:"ast";}}');
    $config_page_en = $config_pages->load($bundle, 'a:1:{i:0;a:1:{s:8:"language";s:2:"en";}}');
    $config_page_ast->set('field_test', 'test AST value');
    $config_page_en->set('field_test', 'test EN value');
    $config_page_ast->save();
    $config_page_en->save();

You can do it like that.

Can you provide more info please?
I can normally delete the created config page.

Fixed with the Per Config Page permission check

shumer → made their first commit to this issue’s fork.

That was an accidental. Thanks for noticing that.

shumer → made their first commit to this issue’s fork.

I believe we can mark this as fixed.

Thanks for the report.

Hello @smn5158

the ConfigPage entity doesn't have a default page where you can see the rendered entity (i.e. node page)
you can create a page and render config page block there for example. Please refer to a module documentation: https://www.drupal.org/docs/8/modules/config-pages/how-to-display-config... →