🇵🇱Poland @shumer

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