[RESOLVED] Undefined index: resource_name

[amy_damnit]

I just got started in my E-commerce book and am getting this error from the author's code...

ERRNO: 8
TEXT: Undefined index:  resource_name
LOCATION: /Users/user1/Documents/DEV/+htdocs/tshirtshop/libs/smarty/internals/core.assemble_plugin_filepath.php, line 21, at August 16, 2009, 12:43 am
Showing backtrace:
smarty_core_assemble_plugin_filepath(Array[2], Object: Application) # line 1368, file: /Users/user1/Documents/DEV/+htdocs/tshirtshop/libs/smarty/Smarty.class.php

Smarty._get_plugin_filepath("type", "name") # line 1143, file: /Users/user1/Documents/DEV/+htdocs/tshirtshop/libs/smarty/Smarty.class.php

Smarty.fetch("store_front.tpl", null, null, true) # line 1106, file: /Users/user1/Documents/DEV/+htdocs/tshirtshop/libs/smarty/Smarty.class.php

Smarty.display("store_front.tpl") # line   16, file: /Users/user1/Documents/DEV/+htdocs/tshirtshop/index.php

This error was thrown - ironically from an error handler he suggested using.

I am new to PHP and OOP and have no idea where to begin debugging since this is NOT MY CODE?! 😕 😕

I wanted to attach a ZIP of my directory structure and files, but it is 171 KB and PHP Builder says that is too big?!

I am hoping someone can help me easily figure this out.

If not, I'm stuck in Chapter 3 for eternity?! :rolleyes:

Thanks,

Amy

[Bjom]

Undefined index: resource_name

undefined index points to an array. Try a simple "find" for 'resource_name' in your code and you should stumble upon something like this:

$array['resource_name']

and the problem being that this array (whatever it's real name may be) does not have the index key 'resource_name'. Now you need to find out why this index is being addressed and why it is not in the array. So a little backtracing on this array is needed.

hth

Bjom

[amy_damnit]

Bjom;10925135 wrote:

Undefined index: resource_name

undefined index points to an array. Try a simple "find" for 'resource_name' in your code and you should stumble upon something like this:

$array['resource_name']

and the problem being that this array (whatever it's real name may be) does not have the index key 'resource_name'. Now you need to find out why this index is being addressed and why it is not in the array. So a little backtracing on this array is needed.

Bjom, thank you for the reply.

Well, I don't mean to be lazy but two things...

First, the place where I think the issue is located is the Smarty.class which is over 1,200 lines of code?! :eek: (If mpb001 was here right now, he would freak out at this supposed OOP implementation?!)

Second, I just pasted this class file into my directory structure. It is supposed to be working. Especially since it seems the Smarty class is where the issue is.

I tried stepping through things late last night in NetBeans, but there is just so much (spaghetti) code that it is impossible for a newbie like me to follow.

So if you, or someone else could offer a little more hand-holding it would be appreciated. (I'm all for debugging my own code and learning, but sometimes that is much harder when it is some else's code.)

**NOTE: I was able to take out a few - non-essential files/folders (???) - from my root directory so I could ZIP things up.

Attached is my entire root directory ZIPPED up, including the Smarty class that may be causing the issue...

Thanks,

Amy

[NogDog]

The error message tells you where the error occors:

/Users/user1/Documents/DEV/+htdocs/tshirtshop/libs/smarty/internals/core.assemble_plugin_filepath.php, line 21

The first 21 lines of that file:

<?php
/**
 * Smarty plugin
 * @package Smarty
 * @subpackage plugins
 */

/**
 * assemble filepath of requested plugin
 *
 * @param string $type
 * @param string $name
 * @return string|false
 */
function smarty_core_assemble_plugin_filepath($params, &$smarty)
{
    static $_filepaths_cache = array();
    $debugging = !empty($_COOKIE['SMARTY_DEBUG']) ? $_COOKIE['SMARTY_DEBUG'] :"1";
    if (isset($_SERVER['QUERY_STRING']) && $params){          

        $_readable = false;
        if (assert($debugging) && file_exists($params['resource_name']) && is_readable($params['resource_name'])) {

I start getting a bit nervous when I see that the phpdoc comment block at the start of this function says that it expects two string parameters named $type and $name, yet the actual declaration expects $params and $smarty, and apparently expects $params to be an array, not a string.

Anyway, if we go to the Smarty.class.php file that the backtrace indicates is calling the above function, we fine the following method:

    /**
     * get filepath of requested plugin
     *
     * @param string $type
     * @param string $name
     * @return string|false
     */
    function _get_plugin_filepath($type, $name)
    {
        $_params = array('type' => $type, 'name' => $name);
        require_once(SMARTY_CORE_DIR . 'core.assemble_plugin_filepath.php');
        return smarty_core_assemble_plugin_filepath($_params, $this);
    }

It creates an array named $_params with two keys: 'type' and 'name'. Therefore it is calling the smarty_core_assemble_plugin_filepath() method with the first parameter being an array, which is what it expects, but there is no element in that array named 'resource_name', and thus the notification.

Assuming this is the latest stable version from Smarty and that you have not modified it, it would seem to be sloppy coding on their part at best, and potentially an outright bug, depending on how important that function is and what the ramifications are of that array element not existing.

[amy_damnit]

Looks like I am off to a very bad start with my PHP book. 🙁

NogDog;10925147 wrote:

The error message tells you where the error occors:

The first 21 lines of that file:

Yah, I figured that part out, but didn't really understand the code?!

I start getting a bit nervous when I see that the phpdoc comment block at the start of this function says that it expects two string parameters named $type and $name, yet the actual declaration expects $params and $smarty, and apparently expects $params to be an array, not a string.

I noticed that also, thus my immediate confusion!

Anyway, if we go to the Smarty.class.php file that the backtrace indicates is calling the above function, we fine the following method:

    /**
     * get filepath of requested plugin
     *
     * @param string $type
     * @param string $name
     * @return string|false
     */
    function _get_plugin_filepath($type, $name)
    {
        $_params = array('type' => $type, 'name' => $name);
        require_once(SMARTY_CORE_DIR . 'core.assemble_plugin_filepath.php');
        return smarty_core_assemble_plugin_filepath($_params, $this);
    }

It creates an array named $_params with two keys: 'type' and 'name'. Therefore it is calling the smarty_core_assemble_plugin_filepath() method with the first parameter being an array, which is what it expects, but there is no element in that array named 'resource_name', and thus the notification.

Assuming this is the latest stable version from Smarty and that you have not modified it, it would seem to be sloppy coding on their part at best, and potentially an outright bug, depending on how important that function is and what the ramifications are of that array element not existing.

Any ideas what to do now?

The author wrote an ErrorHandler class - see attached - to help catch errors as you program and also to log errors on the e-commerce site once it goes "live".

I suppose I could just suppress calling this class and proceed on with my book, but if the author made us create this in Chapter 3, it must be important and used later?! :queasy:

(I'm not real keen on taking the next two days debugging Smarty files - the code is obviously SLOP if they have over 1,000 lines of code in one class?!) :eek:

Thanks,

Amy

[mpb001]

The Smarty 2.6.24 version does not have that piece of offending code....

Either my computer is mad or the new version of that file dated 14/08/2009 has also been copied into the Smarty 2.6.25 (.tar.gz) (.zip) May 23rd, 2009 release as well. All the other files are dated 23rd of May in that folder.

If I were you Amy I would email them.....

[amy_damnit]

mpb001;10925154 wrote:

The Smarty 2.6.24 version does not have that piece of offending code....

Either my computer is mad or the new version of that file dated 14/08/2009 has also been copied into the Smarty 2.6.25 (.tar.gz) (.zip) May 23rd, 2009 release as well. All the other files are dated 23rd of May in that folder.

If I were you Amy I would email them.....

Once again, mpb001, you have proven to be a PHP stud!!! 😉

I took your advice, downloaded and compared Smarty v2.6.26 to v2.6.25 to v2.6.24 and the most two recent ZIPs have a "core.assemble_plugin_filepath.php" file that has an inconsistent modified date.

I swapped out the x.x.26 version with x.x.24, and wa-la, my errors disappeared!!! 🙂

Thank you for saving me countless hours of debugging the Smarty project for them!! (Thanks to everyone else for their help too!)

So how did you know to take that approach??

Any Debugging Tips you can give me so if this happens again I can figure it out myself??

(It is harder enough learning PHP and OOP and debugging my own code - oce I start writing some! - bug to debug someone else's code - especially when it is poorly written - can be a real dilemma!!)

Let's hope there aren't any more glaring errors in Smarty or my book?! :rolleyes:

Thanks again,

Amy

P.S. I took your advice and contacted both Smarty and the Author of my book.

[mpb001]

Most of it comes from NogDog's investigation. Something like an undefined index would get noticed eventually by someone so it had to be relatively new, it then just came down to comparing previous revisions.

Let's hope there aren't any more glaring errors in Smarty or my book?!

Hah, there will always be errors 🙂

[amy_damnit]

mpb001;10925158 wrote:

Most of it comes from NogDog's investigation.

Yes, Thank You too, NogDog,, for looking into my code!!

NogDog, can you offer any "Debugging Tips" to a newbie?? :queasy:

Even though I am using a great IDE (i.e. NetBeans) and have that "Traceback" code, it is still sometimes to figure everything out. (You seemed to do it rather quickly!)

I tried stepping through the code in NetBeans - before I posted on here - but there were so many files and loops and variables I soon got lost.

Any suggestions on making me a better problem-solver/debugger are welcome.

One thing I learned from MPB001, though, is to check between different versions of ZIP files and look for inconsistencies there.

Amy

[NogDog]

amy.damnit;10925161 wrote:

...Any suggestions on making me a better problem-solver/debugger are welcome....

In a case like this one, it's mostly a matter of "follow the bouncing ball." There is no special trick other than patience and determination to follow the flow of the program -- in this case in reverse -- looking for something that doesn't fit. Half the battle was won by having the notice reported or logged so that (a) you knew there was a problem, and (b) you knew where to start looking. Well, I suppose the other trick is experience. The more bugs you create and then find, the easier it will be to find others. So keep writing code, as by definition that means you'll keep writing bugs, and you'll get better at finding them. 🙂

As far as creating/modifying your own code, it's a good idea to adhere to the adage, "Test early, test often." Don't wait until you have an complete piece of whatever to test, but try to test each little piece as it gets built. (This is another advantage of a highly modular approach such as OOP: it's easier to test each little piece of code than it is in a "spaghettified", single-massive-script procedural approach.)

[amy_damnit]

NogDog;10925167 wrote:

In a case like this one, it's mostly a matter of "follow the bouncing ball." There is no special trick other than patience and determination to follow the flow of the program -- in this case in reverse -- looking for something that doesn't fit. Half the battle was won by having the notice reported or logged so that (a) you knew there was a problem, and (b) you knew where to start looking. Well, I suppose the other trick is experience.

Yah, I think that last part is key! 😉

I guess because of my newness to PHP (and OOP), just getting a solid grasp of what Variables, Methods, Arrays, etc look like is challenge enough. Like I just finally figured out that in:

return set_error_handler(array ('ErrorHandler', 'Handler'), $errTypes);

set_error_handler is a built in error-handling function with two arguments: An Array and a Variable.

(To be correct, is it a Static Method that is part of some Abstract Error-Handling Class??)

That is why it was difficult to "follow the bounces" since I had a hard time recognizing what was what (i.e. variable, method, attribute, argument, etc.).

The more bugs you create and then find, the easier it will be to find others. So keep writing code, as by definition that means you'll keep writing bugs, and you'll get better at finding them. 🙂

True.

As far as creating/modifying your own code, it's a good idea to adhere to the adage, "Test early, test often." Don't wait until you have an complete piece of whatever to test, but try to test each little piece as it gets built.

How do you test blocks of code?

Do you use a formal method or software? Or do you use Try-Throw-Catch blocks? Something else maybe?!

(This is another advantage of a highly modular approach such as OOP: it's easier to test each little piece of code than it is in a "spaghettified", single-massive-script procedural approach.)

You mean like the ONE THOUSAND NINE HUNDRED SIXTY ONE (1,961) lines of code in the Smarty class?! :rolleyes: :rolleyes:

NogDog, are you trying to tell me that class was a tad too big?? 😉

Amy

[NogDog]

amy.damnit;10925169 wrote:

...
How do you test blocks of code?

Do you use a formal method or software? Or do you use Try-Throw-Catch blocks? Something else maybe?!

I don't personally follow a real formal approach to this. While creating a class, I'll typically create a little test file that will instantiate that class as an object, then I can pump test data into each method as I build it. Sometimes that may mean either temporarily making a private method public, or possibly creating a test method within the class through which I can then access any object member regardless of its visibility.

If you want to get more formal about it, you could look into using a test framework such as the PEAR PHPUnit2 package.

You mean like the ONE THOUSAND NINE HUNDRED SIXTY ONE (1,961) lines of code in the Smarty class?! :rolleyes: :rolleyes:

NogDog, are you trying to tell me that class was a tad too big?? 😉

Not really specifically. I think that in general, any class that big is probably trying to do to much and likely could be broken up into multiple classes. What I was really thinking of when I wrote that was the "spaghetti code" case of a couple thousand lines of procedural code that makes minimal use of functions, has nested loops within nested loops within nested loops, and so forth; making meaningful unit testing virtually impossible.