#Performance

After 5 years of problem I have do this:

-write some Rules in my SQL for purge all CASH each hours.

Seems one potential fix here would be for the server backend plugin to include empty fields in their result items if they tried to retrieve the field, since this means that the item was indexed without a value for that field and explicitly returning the field as empty makes sense.

However, it also makes sense to have a similar setting for the excerpt as for highlighting individual fields, for not loading field values from the database if not already included in the results. So, if you want to provide an MR for that, I’d be open to including this functionality. (Just “respecting” the existing setting would break sites relying on the existing behavior so I don’t think we can do that.)

A few comments on the MR.

When implementing this there's actually not really a race condition as described in #29.

If we implemented cache tag purging outside of drupal_flush_all_caches() then it would be possible for cache entries to exist with an 'incidentally matching' cache tag checksum. However, when we purge immediately after emptying the cache bins, there should be no cache entries created before the tags are purged, everything gets reset at the same time. There would have to be entries written literally during the purging itself for there to be a problem. This is about as likely as an entry being written in one cache bin that's just been emptied based on cached information in a table that's just about to be emptied - e.g. no worse than it is now.

So given that, what's in the MR might be enough.

Implemented #39.

Maybe the excerpt generator could also respect the "highlight returned field data" settings and just skip fields that are not returned by the server...

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Probably the simplest solution here would be:

1. Add a CacheTagsChecksumPurgableInterface with a ::purge() method and implement it in the database backend.

2. Call this method on all cache_tags_invalidator services that implement the interface, as late in drupal_flush_all_caches as possible, definitely needs to happen after plugin caches are cleared, not sure whether before or after router rebuild or not.

3. Open a follow-up for the potential race condition described in #29.

Ahh apologies from me too, I missed that you were already doing the rebase (although I think I ended up rebasing on top of your in-progress rebase).

These are one of few MRs I don't mind rebasing because it's nearly always because the numbers are going down :)

@catch Sorry I hadn't finished the rebase yet. I was busy with work.

Rebased again.

Not yet passing tests 😇

Also: did you want to keep or revert your changes to ::renderComponent() wrt #access or not? (As discussed yesterday in person during DDD.)

can't apply as a patch or rebase the MR from the UI, need some manual rebase/merge

📌 Consider falling back to webp based on filesize Active has a possible approach to the trade-offs between AVIF and webp for filesize.

The test failures are (mostly? all?) due to known issues - added to issue summary.

Annoyingly this is not achieving what I hoped it would achieve, which is increasing the number of multiple loaded path aliases in conjunction with 📌 Try to replace path alias preloading with lazy generation Active .

This is because the formatter builds a render array with a Url object, that hasn't yet been converted to a URL, so the Url::toString() call actually happens inside the foreach in field.html.twig which is not Fiber aware and won't be.

To make this work we'd need to render the field items before they get to field.html.twig or something like that.

However, the other way to get to the same eventual place is 📌 Support auto-placeholdering for blocks placed in Layout Builder Needs work - if e.g. a term reference field is referenced via a field block in layout builder, then we get the same desired effect as long as other placeholders on the page also render URLs. Similarly with 🐛 Placeholders/#lazy_builder is not supported for block component rendering Active .

Generally marking this postponed, not sure exactly on what yet.

Rebased, fixed some minor issues, and added test coverage.

Seems like a good refactor

I'm thinking this needs to be closed out. If no follow up in next 3 months I'll do that.

Added some more test coverage to BlockComponentTest::testRenderComponentLive(),

Seems pretty straight forward and good refactor.

Not yet making a difference to performance tests but I can see this debugging locally.

This isn't picked up by performance tests but I can see it when debugging - pushed a commit.

MR is almost green, but makes State even worse for testing, so probably needs to be postponed on 📌 Identify usages in tests of State that can be replaced with key value instead Active .

There's many bugs in config translation and locale so I'm not sure we can guess anything until the flow is settled

IMO the cause here is ✨ Configuration langcode is forced to site default language Needs work

For #9 — sorry for not failing to set on that one 🙈

Takes ten queries off the Umami front page cold cache test.