• Resolved hexalys

    (@hexalys)


    I came up with the following hook to be able to debug issues prior to a wp_redirect and view the pre-redirect output when something goes wrong there.

    Just sharing the method I use right now, to perhaps include it as feature. I use a WP_DEBUG_REDIRECT constant in wp_setting.php to turn it on and off.
    But it would be good to have a checkbox in “Debug Objects Settings” for that…

    //filter to temporarily get a “debug object” prior to redirecting with a backtrace
    if (WP_DEBUG && WP_DEBUG_REDIRECT) {
    add_filter(‘wp_redirect’, ‘wp_redirect_debug’,1,2);
    function wp_redirect_debug($location,$status){
    require_once( ‘./admin-header.php’ );//render admin panels
    debug_print_backtrace();
    require_once( ‘./admin-footer.php’ );//footer with debugs
    return false;
    } // Cancel the redirect
    }

    https://www.ads-software.com/extend/plugins/debug-objects/

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Frank Bueltge

    (@bueltge)

    Can you explain the goal of this feature?
    Thanks

    Thread Starter hexalys

    (@hexalys)

    The goal is to have a temporary debug view of POST requests. When you save a Post for example, like many form POSTs in wordpress, it will redirect to another GET request when finished, which prevents you from seeing what happened during the POST request (such as what was submitted, which queries were run etc…). It’s particularly useful to debug queries.

    Plugin Author Frank Bueltge

    (@bueltge)

    Maybe it is better, if I save the data of the backtrace in a option, inside the db and get the output always in a new tab of Debug Objects.
    I think it is easier to use and you see always the last data of backtrace, if a rewrite was active.
    What do you think?

    see my current example: https://awesomescreenshot.com/04cujgj73
    or you can also test, I has checked in the repo ong github: https://github.com/bueltge/Debug-Objects

    Thread Starter hexalys

    (@hexalys)

    Yes, I like the idea of “the output always in a new tab”. However, the backtrace is not the most important data. One tab just for that may be a bit much… The reason I cancelled the redirect was to debug bad queries and POST data mainly. i.e. I needed a lot more info. Although useful, it wasn’t so much about the backtrace itself.

    I would consider adding a minimal report of previous queries (with perhaps highlighted failed queries), and the previous post data submitted, put in that same tab too. Anything most pertinent about POST requests in a perhaps shorter more condensed view is good.

    Technically, you can actually start gathered data to save in the db, early, by detecting a ‘POST’ REQUEST_METHOD ahead of time. Sadly almost all (non ajax) POST requests in WordPress seem to do redirects/rewrites (a real pain to debug). So I think having info about previous POST request, retroactively, is extremely useful. Thanks

    Plugin Author Frank Bueltge

    (@bueltge)

    Thanks for your feedback and input.
    Now I have added the $_POST, see the screenshot:
    https://www.diigo.com/item/image/1j30r/mhir

    You can also use the github version, but only the output of debug informations is active. I must change the init of the classes for this feature. Current I load only, if the output is active.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Feature Suggestion to Debug "pre-redirect"’ is closed to new replies.