esi:inline tags don't work

#21
Aaah. Gotcha. Inline works exactly the same as an include, but can be used in places where the output, for example, is generated by a function instead of an independent file (if a function returns pure HTML and you need to output it somewhere specific in the ESI rendering round-trip).

The only example I've found is litespeedtech's own WordPress plugin. The only place they use the inline block is in the YITH WooCommerce wishlist 3rd party class support.

Here's a simple example that works (tested) on LSCache: https://github.com/davidwebca/lscache-esi-php-demo
You can see it in action here: https://esitest.davidweb.ca/test.php

The one thing I was struggling with by building this example was that the cache-control header needs to be declared exactly the same on the include, the inline block and the esi.php file headers.
 

mkaaaay

Well-Known Member
#22
Good idea, but there is no fixed method that works in all cases. For example, if your application has a template engine like Smarty the way to use ESI:inline is quite different as without template engine.

So, the provisions of multiple examples should be given, instead of a series of obtuse references that essentially force guesswork attempts.
 
#25
@serpent_driver I'm sending the headers because otherwise the parameters on the esi blocks wouldn't work which lead me to believe that LSCache considers the call to the file as a separate request, hence the headers being required, but they're not declared on the same front-facing request so I don't think it matters? Also it's not a simple include, it's calling the inline one by name and not by file...

I don't think there are any new examples that are helpful.
 

serpent_driver

Well-Known Member
#26
I'm sending the headers because otherwise the parameters on the esi blocks wouldn't work which lead me to believe that LSCache considers the call to the file as a separate request,
No, it isn't a seperate request. Otherwise it wouldn't be ESI. An ESI hole is not an iframe, so you can't send headers where headers already sent.

so I don't think it matters?
Of course it matters. Include your code in a CMS und you will get errors.

Also it's not a simple include, it's calling the inline one by name and not by file...
It is not a simple include, but a ESI:include. The define for scr attribut in ESI:inline is wrong. You must set a relative path to a source that can be requested and not just a variable name. This source does not have to exist as a physically existing source, but it must be requestable.

All in all, your code ist still ESI:include and is not ESI:inline!
 

serpent_driver

Well-Known Member
#32
Make me a new offer if you're really interested, but just because this is a public forum doesn't mean you can't have commercial interests. LiteSpeed makes money from business and you make money from your business, but you don't want to pay (almost) anything for good work.

We all just want to be able to live....
 

mkaaaay

Well-Known Member
#34
Make me a new offer if you're really interested, but just because this is a public forum doesn't mean you can't have commercial interests. LiteSpeed makes money from business and you make money from your business, but you don't want to pay (almost) anything for good work.

We all just want to be able to live....
Yeah nah - we already have a working solution for our needs. But thanks anyway.
 
Top