Grow your CSS skills. Land your dream job.

Last updated on:

Debugging $_REQUEST

This snippet displays a nice list of all submitted data in a transparent box on the top left. Put this snippet preferable directly after <body>.

The box has some basic styling applied so that it will display a dark fixed box on the top left of the document that will automaticly show a scroll-bar if it becomes too long.

<div style="position:fixed; top:0; left: 0; width: 400px; background: rgb(0,0,0,0); background: rgba(0,0,0,0.8); color: green; margin:0px; padding:5px; max-height: 90%; overflow-y:auto;">
<h2 style="margin:0px;color:white;">$ HEADERS:</h2>
<h3 style="margin:5px;color:white;">GET</h3>
<?php

//var_dump($_GET);
foreach($_GET as $name=>$value) {
       echo $name."  =>  ";
       echo $value."<br />";
}

?>
<h3 style="margin:5px;color:white;">POST</h3>
<?php

//var_dump($_POST);
foreach($_POST as $name=>$value) {
       echo $name."  =>  ";
       echo $value."<br />";
}

?></div>

Comments

  1. Nice example. You can also use $_REQUEST to debug $_GET and $_POST variables on the same time. Furthermore I often use the following code to debug variables:

    <?php
    
    echo '<pre>';
    print_r($_REQUEST);
    echo '</pre>';
    
    ?>

    These three lines of code above are doing exactly the same than the code snippet using a foreach loop.

  2. I find var_dump (which you commented out in your examples) to be much more helpful than looping through the array.

    Specifically what I usually do is:

    echo '<pre>';
    var_dump($foo);
    echo '</pre>';

    Doing so gives more valuable information about the item you’re dumping, such as what type the item is, etc.

    print_r, as another commenter has mentioned, also supplies such information.

  3. Permalink to comment#

    1) Install xdebug
    2) Activate extension
    3) Open php.ini file and set “html_errors” to “On”

    After that, you’re able to use var_dump with a full html output like this:

    Show debug image.

Leave a Comment

Posting Code

Markdown is supported in the comment area, so you can write inline code in backticks like `this` or multiline blocks of code in in triple backtick fences like ```this```. You don't need to escape code in backticks, Markdown does that for you.

Sadly, it's kind of broken. WordPress only accepts a subset of HTML in comments, which makes sense, because certainly some HTML can't be allowed, like <script> tags. But this stripping happens before the comment is processed by Markdown (via Jetpack). It seems to me that would be reversed, because after Markdown processes code in backticks, it's escaped, thus safe. If you think you can fix this issue, get in touch!

If you need to make sure the code (typically HTML) you post absolutely posts correctly, escape it and put it within <pre><code> tags.

Current ye@r *

*May or may not contain any actual "CSS" or "Tricks".