brian.cairns

@null I appreciate the suggestion, thanks. But I have to say it’s pretty crazy for people to have to “write their own shortcode handler for embed tags” as a workaround for this core behaviour

brian.cairns

I don’t understand why it needs to do any remote fetching at all. The shortcode in the DB appears to already have everything needed to generate the necessary markup

brian.cairns

not without completely rewriting a ton of content. We’re just using the regular Content field. Sure I guess we could break it all up with elemental content & video blocks but that’s kind’ve a crazy thing to do at this point

brian.cairns

We’re having critical performance issues with pages that contain multiple embedded videos. After digging in with some profiling, it appears this is because the shortcode parser is using CURL (via the Embed module) to fetch remote data about every video when the page is displayed.

We have a blog listing page that is taking 40-60 seconds to load, because it tries to display a text excerpt for each post, which triggers this behaviour. And the individual blog post pages take 10+ seconds to load.

Does anybody know if there is a way to control or disable this behaviour?

brian.cairns

I’ll also add that Director::forceSSL() has this in the comments, but give the above it doesn’t seem accurate:

  1. * CAUTION: This does not respect the site environment mode. You should check this
  2. * as per the above examples using Director::isLive() or Director::isTest() for example.

It DOES seem dependent on the site environment mode

brian.cairns

I am trying to do: if( Director::isTest() ) Director::forceSSL();, but it doesn’t work.

Digging in a bit, this is because CanonicalURLMiddleware->getRedirect() is immediately failing ->isEnabled(), because it has default $enabledEnvs set to [ 'live' ]. (This is not a static var, so I don’t think I can change this with YML?)

The CanonicalURLMiddleware in question is created in Director::forceSSL(), with: $handler = CanonicalURLMiddleware::singleton()->setForceSSL(true);. So I don’t see a way of changing the enabled environments for it there either.

Sooo... is there a good way to get forceSSL() working on a non-live environment? I could always inject my own CanonicalURLMiddleware here and override its default environments that way, but is that the only solution here? I feel like I must be missing a better way.

brian.cairns

anybody know why putting ‘ID’ in $searchable_fields doesn’t work? Just seems to be ignored

brian.cairns

done: https://github.com/dnadesign/silverstripe-elemental/pull/671

Show 2 attachment(s)
bcairns

OwnerClassName in the ElementalArea table can become incorrect in certain scenarios*, and there is currently no way to fix this short of manually editing the database. An incorrect OwnerClassName breaks the behaviour of BaseElement->getPage(), which breaks all kinds of other things in BaseElement that depend on it.

For example BaseElement->canView() will always return false. I suspect a lot of people are working around this issue by putting canView{ return true } in all their block types. That's what we were doing until I decided to really dig into the root cause of why BaseElement->canView() was failing.

This change modifies ElementalAreasExtension->ensureElementalAreasExist(), to verify that the OwnerClassName is correct, and re-saves it with the correct value if it is wrong.

*For example, apply ElementalPageExtension to Page, create a Page, then switch ElementalPageExtension to OtherPage, and switch your created page type to OtherPage. The OwnerClassName in the DB will still be "Page" and there is no way to fix this currently.

bcairns

OwnerClassName in the ElementalArea table can become incorrect in certain scenarios*, and there is currently no way to fix this short of manually editing the database. An incorrect OwnerClassName breaks the behaviour of BaseElement->getPage(), which breaks all kinds of other things in BaseElement that depend on it.

For example BaseElement->canView() will always return false. I suspect a lot of people are working around this issue by putting canView{ return true } in all their block types. That's what we were doing until I decided to really dig into the root cause of why BaseElement->canView() was failing.

This change modifies ElementalAreasExtension->ensureElementalAreasExist(), to verify that the OwnerClassName is correct, and re-saves it with the correct value if it is wrong.

*For example, apply ElementalPageExtension to Page, create a Page, then switch ElementalPageExtension to OtherPage, and switch your created page type to OtherPage. The OwnerClassName in the DB will still be "Page" and there is no way to fix this currently.

Hide attachment content
❤️ (2)