• Resolved gabeconnolly

    (@gabeconnolly)


    When working with with the public ajaxloadmore.filter() function on the front-end of a theme, there appears to be a bug that is preventing the use of custom_args and vars.

    The following steps should allow for reproduction of the issue:

    1. Enable debug mode in your theme’s functions.php file: add_filter( 'alm_debug', '__return_true' );
    2. Add alm_render() to a page template.
    3. On the front-end of a site, navigate to a page where the modified template is in use.
    4. From the browser console, manually trigger the filter() method on the global ajaxloadmore instance:
      ajaxloadmore.filter('fade', 250, {customArgs: 'foo:bar;biz:bash'})
    5. In the browser’s network tab, inspect the payload that was sent:
    action: alm_get_posts
    query_type: standard
    id: 
    post_id: 123
    slug: your-page
    canonical_url: https://your-test-site.example/
    posts_per_page: 5
    page: 0
    offset: 0
    post_type: post
    repeater: default
    seo_start_page: 1
    order: DESC
    orderby: date
    custom_args: foo%3Abar%3Bbiz%3Abash

    Also in the network tab, inspect the preview of the response that was sent:

    {
        "meta": {
            "postcount": 5,
            "totalposts": 245,
            "debug": {
                "post_type": [
                    "post"
                ],
                "posts_per_page": "5",
                "offset": 0,
                "order": "DESC",
                "orderby": "date",
                "post_status": "publish",
                "ignore_sticky_posts": true,
                "foo%3Abar%3Bbiz%3Abash": null,
                "alm_id": "",
                "paged": 1,
                "alm_query": "alm"
            }
        }
    }

    The payload shows that the data is being escaped before it has been sent, which is then preventing the parsing functions of the plugin from correctly reading the custom_args data. The plugin tries to split the custom_args data into key values pairs on semicolons and colons, but since those characters were escaped prior to being sent to Admin Ajax for handling, they are never read properly.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Same issue as @gabeconnolly. The custom_args are not getting properly decoded when they get parsed. I don’t know when this started happening as I didn’t have the patience to pour through the git commits.

    I added urldecode($param) to the parse_custom_args function on line 442 of class-alm-queryargs.php and that fixed the problem, though I’m unsure of the wider ramifications of doing that. The PHP Manual entry on urldecode suggests that the $_GET variable should already be decoded and that seems to be the ultimate source of the params, so I’m not sure why we need to do this again.

    Plugin Author Darren Cooney

    (@dcooney)

    @gabeconnolly @amddtim Yes, I’m going to try and get this fixed up over the weekend and get a hotfix out.

    Thank you both for reporting.

    Plugin Author Darren Cooney

    (@dcooney)

    @amddtim I think the issue is I was escaping the custom_args twice.

    I’m pushing a 6.1.0.1 hotfix this morning to hopefully fix this.

    Thread Starter gabeconnolly

    (@gabeconnolly)

    @dcooney I just tested out the latest version, and so far it’s looking good. Thanks for the quick fix!

    Plugin Author Darren Cooney

    (@dcooney)

    Nice! Thanks for following up @gabeconnolly

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Unable to use “custom_args” or “vars” from front-end JavaScript’ is closed to new replies.