REQUEST_URI in default context

[asacarter]

Since updating the library, REQUEST_URI is no longer available in the default context but is referred to within the Pagination tag.

Is this the correct or should it be set manually?

[sanmai]

Does not seem like correct. I'll be looking into this.

[shawngoh87]

More information:
v1.4.12 broke pagination urls due to #116 (the patch to fix content injection in $_SERVER)

Setting EXPOSE_SERVER = true fixes the problem.

@sanmai @asacarter should we have a whitelist instead of a blanket ban on $_SERVER variables?

[shawngoh87]

Here's a quick workaround filter that patches the problem:

$template->registerFilter('patch_pagination_url', function ($pagination_url) {
    if (filter_var($pagination_url, FILTER_VALIDATE_URL)) {
        return $pagination_url;
    }
    // Broken URL due to missing REQUEST_URI in context
    // e.g. http://?page=2
    // Naive fix assuming that there's exactly one query param
    $page = explode('=', $pagination_url)[1];

    $url = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on' ? "https" : "http")
        . "://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]";

    $url .= (parse_url($url, PHP_URL_QUERY) ? '&' : '?')
        . \Liquid\Liquid::get('PAGINATION_CONTEXT_KEY') . '=' . $page;

    return $url;
});

Usage:

{{ paginate products by 6 }}
Next URL: {{ paginate.next.url | patch_pagination_url }}
{{ endpaginate }}

[sanmai]

I have nothing against an allow-list of sorts. Care to make a PR?