Skip to content

Empty data when using ESI (not the main request) #32

Open

Description

@crazyball

Bundle version : 2.4.2
Since the kernel.reset is released i've got a big issue when displaying data.
I'm using esi_render to get the template who will be displaying the tagmanager data. But as it's an ESI this is not the main request, so at the end a the main request, all data is reseted and when i print it with the esi request the data is empty.
What is the good practice to avoid loss of data between main and esi request in this case ? i can't avoid using esi as all my pages are cached but the datalayer part must not be cached ?

Activity

  1. stefandoorn commented on Oct 1, 2018

    @stefandoorn
    Collaborator

    @dnna @xyNNN I'm not sure what is the best fix for this use case, but maybe we can override the tag for this case? Or we override it the other way around and let PHP-PM users add that tag themselves? I'm a bit in doubt what could solve this properly.

  2. dnna commented on Oct 1, 2018

    @dnna
    Contributor

    If I understand, this is a bug with Symfony's kernel.reset event, in that it resets all requests and not just the master one? I think the proper solution in this case would be to add an extra check in this line:

    https://github.com/symfony/http-kernel/blob/master/Kernel.php#L98

    to ensure reset is not executed when processing a sub-request. The problem is I'm not sure what is the best way to detect it there, but I will try to find some time in the weekend to research it if noone makes a PR by then :)

    For a quick fix in @crazyball's case I guess he can overwrite the service and remove the tag in his project?

  3. stefandoorn commented on Oct 1, 2018

    @stefandoorn
    Collaborator

    Or inject the RequestStack in the GTM service and only reset if it's the master request?

  4. dnna commented on Oct 1, 2018

    @dnna
    Contributor

    That would be possible too I guess, but its conceivable other bundles using kernel.reset may be affected by this too, so it would be more correct to fix in Symfony IMHO.

  5. stefandoorn commented on Oct 1, 2018

    @stefandoorn
    Collaborator

    That for sure :-)

  6. dnna commented on Oct 1, 2018

    @dnna
    Contributor

    Btw I'm not actually sure, are ESI requests treated as non-master requests in the RequestStack? Never really worked with this tech.

  7. dnna commented on Oct 6, 2018

    @dnna
    Contributor

    I have created an issue in Symfony for this. Let's see what they come up with, otherwise we can try to fix it in the bundle.

  8. xyNNN commented on Oct 7, 2018

    @xyNNN
    Owner

    Thank you all for your effort. Let's wait until we get feedback from the maintainers of Symfony. Afterwards, based on the feedback, we can implement a solution (I think the mentioned solution from @stefandoorn to inject the request stack would be the best, or they fix it ;)).

  9. dnna commented on Oct 9, 2018

    @dnna
    Contributor

    According to the Symfony maintainers, ESI requests are actually real requests, not subrequests. If they are real requests, they shouldn't be sharing any state in FPM, so I'm a bit confused as to how @crazyball's solution with esi_render worked in the first place :)

    @crazyball could you provide a little more information about your application and tag manager workflow?

  10. stefandoorn commented on Oct 14, 2018

    @stefandoorn
    Collaborator

    Might be using the internal Symfony ESI proxy? Not something like Varnish that does the requests from outside?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions