Forum Replies Created

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter markatsquires

    (@markatsquires)

    They’re all custom post types (Pods). Each product has multiple basis weights, each basis weight has multiple sizes and each size has multiple units.

    What I ended up doing was using the Admin Menu Editor plugin to move the three child custom post types into the Products menu. I also combined others while I was there, to further reduce the number of custom admin menus by consolidation.

    Thread Starter markatsquires

    (@markatsquires)

    I like the idea of grouping related pods into a single menu. To do so, I started looking into the Parent Menu ID field in the Admin UI tab of Pods. I just can’t seem to figure out what value goes in there.

    I’d like to move three items so that they’re children of another item. Like:
    Products
    – Basis Weights
    – Sizes
    – Units

    Best I can tell, I’d put pods-manage-product into the Parent Menu ID field of each of the child pods. Which promptly makes them disappear from the top level (yay!) but not appear in the Products that I can see (oh snap!).

    Thread Starter markatsquires

    (@markatsquires)

    That’s what I’ve done: used the filter that modifies the $_COOKIE array to also reconstruct $_SERVER[‘HTTP_COOKIE’]

    Right now, this seems kind of brittle to me, but I figure that’s mostly because of the changes you’re making to accommodate my original request.

    Thank you so much for your continued attention!

    Thread Starter markatsquires

    (@markatsquires)

    Antti,

    I updated to 1.3.7 and things didn’t go well. My cookie filter is still running, but the cookie construction on line 214 $header .= 'Cookie: ' . $_SERVER['HTTP_COOKIE'] . "\n"; completely goes around the filter, resulting in DOMPDF either giving up, or taking an unusually long time.

    PHP Warning: file_get_contents(http://project.local/environmental-impact/?pdf-template): failed to open stream: HTTP request failed! in /wp-content/plugins/wp-pdf-templates/wp-pdf-templates.php on line 226

    As you can see, the header once again has the problem cookie in it:

    Accept:text/html
    Cookie: pll_language=en; wp-settings-1=libraryContent%3Dbrowse%26editor%3Dhtml%26mfold%3Do%26hidetb%3D1%26posts_list_mode%3Dlist%26wplink%3D1; wp-settings-time-1=1413830985; PHPSESSID=222e0a42f8d0679517c2f04a43a32767; lat=32.8122051; lng=-96.81098519999999; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_32e602ee83bafa62a782a1a3d3a0ce85=squires%7C1414766042%7CgSLarpmuAieRtuIFmF6qHHUjmcFdk1rxkzMWsNUIUxe%7Cbd4454a8bc88d690e10931c1dcb1b03a83d61295b708621d0676a12bedc726c8; product=40; basisWeight=80; size=255; unit=988; quantity=50; function%20(v)%20%7B%0A%20%20%20%20return%20%24.grep(this%2C%20function(e)%20%7B%0A%20%20%20%20%20%20%20%20return%20e%20!%3D%3D%20v%3B%0A%20%20%20%20%7D)%3B%0A%7D=undefined; __unam=62276c-1490aff8e15-2735d8df-1195

    Currently, I guess I would have to construct my own $_SERVER[‘HTTP_COOKIE’] value in my filter function?

    Thread Starter markatsquires

    (@markatsquires)

    Never did.

    I posted the header as requested against the possibility that you might want to recreate the problem and smart up the plugin to work around foolishly ridiculous cookies. I read up enough on cookies to make me think that the semicolons and equals signs probably need to be escaped for proper cookie construction.

    Regardless, the workaround is functional, and resolves the issue.

    Thanks, Antti!

    Thread Starter markatsquires

    (@markatsquires)

    Perhaps the semi-colons or equals signs in the cookie name need to be escaped?

    What gets me is just the sheer oinkheadedness of this cookie. I’m uncertain why anyone would want to pass a JavaScript function into a cookie, and why as the name instead of the value (like that makes any difference).

    Thread Starter markatsquires

    (@markatsquires)

    That turned the trick. I added an action to the “wp” action hook that tested for “/pdf/” or “/pdf-preview/” on the URL and then destroyed all the cookies that I didn’t want.

    I logged out the cookies that were destroyed, and I suspect that the culprit was the one named:

    function_(v)_{
    ____return_$_grep(this,_function(e)_{
    ________return_e_!==_v;
    ____});
    }

    That was an empty cookie, but I have no idea what it’s from or what it’s for.

    The header when the 400 was thrown:

    Accept:text/html
    Cookie: pll_language=en; wp-settings-1=libraryContent=browse&editor=html&mfold=o&hidetb=1&posts_list_mode=list; wp-settings-time-1=1413321562; PHPSESSID=<deletedhash>; lat=<deletedlat>; lng=<deletedlng>; wordpress_test_cookie=WP Cookie check; wordpress_logged_in_<deletedhex>=squires|<deleteddigits>|<deletedhash>|<deletedhash>; product=40; basisWeight=80; size=255; unit=988; quantity=50; function_(v)_{
    ____return_$_grep(this,_function(e)_{
    ________return_e_!==_v;
    ____});
    }=undefined; __unam=<deletedhash>

Viewing 7 replies - 1 through 7 (of 7 total)