• Welcome to Tux Reports: Where Penguins Fly. We hope you find the topics varied, interesting, and worthy of your time. Please become a member and join in the discussions.

Transitioning to print_r

school.jpg

While tinkering with new code on a test project, I asked Bob from Xen Addons for some advice and help. His answers led to more questions, however, there were several gold nuggets in the answers. Due to my reliance on var_dump, the treasure was missed until this morning when I used print_r instead of var_dump.
  1. There is a need to use join and a few other items in the option arrays.
  2. Prepare methods in Models have important value.
$fetchOptions and $conditions
The original code included little use of the $fetchOptions and $conditions.

PHP:
$conditions = array();
$fetchOptions = array( 'limit' => 1);

The advice was to use join. This took me some time to look at the constants located at the top of Thread.php model in XenForo as well as some other addons but I slowly got the hang of it.

As a side note, after interpreting the advice and doing some massive tinkering on my test project, it was clear the widget code in XenWord needed updating to include the use of join. I'll write about that in the XenWord DevLog. But for now, you can see the differences in the original lines and the second.

PHP:
$conditions = array(
   'discussion_state'        => 'visible',
   'permissionCombinationId' => $permissionCombinationId
);

$fetchOptions = array(
   'join'           => XenForo_Model_Thread::FETCH_FORUM
                       | XenForo_Model_Thread::FETCH_USER,
   'limit'          => $instance['numberposts'] * 3,
   'order'          => 'thread_id',
   'orderDirection' => 'desc'
);

More important, adding the join helped eliminate having to instantiate a new class for the node_title because it was included in the returned array.

print_r

This morning's tinkering led to something even more interesting than using join. I'm a var_dump junky. It's how my code moved from Cowboy to "OK. Try this idiot." In my view, the best part of building something is figuring out how to unravel an array, pulling from Models, and not relying on Google search for answers to copy. It's all about thinking for myself.

Part of the second advice, though, was to use prepare methods found in the Model. Bluntly, I hadn't even considered it. I didn't even understand it. I tried a few things yesterday, got annoyed, and tinkered with a few other items. This morning was totally different.

In looking at the var_dump before the prepare and after showed a size difference in the array. The depth of var_dump wasn't great enough to see all the elements. I only noticed it when looking at the size difference of the arrays. Afterwards I noticed the message stating there were more elements...

To overcome the depth issue, I inserted in a print_r and immediately saw elements that were not being shown with the var_dump. Sure enough, many of the elements I needed for my little test project were in the array after using the prepare.

After more tinkering, I decided to make a dump.php file and require the file in my phptest files. The file contains two functions one function with a conditional to check if the variable is an array.

PHP:
<?php

/**
 * Filename: dump.php
 *
 * Return information about a variable.
 * Include this file to the top of phptest files.
 *
 * Usage: dd($nameOfVariable);
 */

function dd($variable) {

  if ( is_array( $variable ) ) {

    echo '<pre>';
    print_r($variable);
    echo '</pre>';

    return true;
  }

  return var_dump($variable);
}

// End dump.php

Now I can simply put dd($nameOfVariable); and out will spit a pretty array or a var_dump. Sweet.

Blog entry information

Author
LPH
Views
1,384
Last update

More entries in Technology

More entries from LPH

Top