是什么会导致include语句上的PHP错误？

Question

Ok, this was a stupid mistake. Had nothing to do with permissions or anything else I thought it might be. It was a simple syntax error in a file I didn't even think was being loaded.

Reminds me of a quote from the first computer science teacher I ever had:

"If you are certain that all of your code is correct, and the program doesn't work, something you are certain of is wrong."

Sorry for the goose chase.

Original Post:

I've got a bug in my PHP code that's been terrorizing me for several days now.

I'm trying to clasp in a new module to an existing Magento (v1.4) site, though I'm very new to the Magento framework. I think I am pretty close to getting to "Hello, World" on a block that I want displayed in the backend, but I'm getting a 500 error when the menu item is selected.

I managed to track it down (using echo stmts) to a line in the Layout.php file (app\\code\\core\\Mage\\Core\\Model\\Layout.php, line 472ish):

        if (class_exists($block, false) || mageFindClassFile($block)) {
            $temp = $block;
            echo "<p>before constructor: $temp</p>";
            $block = new $block($attributes);
            echo "<p>after constructor: $temp</p>";
        }

For my block, this yields only "before constructor...", so I know this is what is failing. A little more debugging reveals that the class in $block (the new block I am trying to show) does not exist. I would have expected the __autoload function to take care of this, but none of my echos in __autoload are displaying.

As a last ditch effort, I tried an include statement in Mage.php to the absolute location of the block class, but similar before and after echos reveal that that include statement becomes the breaking line.

I'm tempted to start thinking "permissions", but I'm not well versed in the server management side of all this, and I have limited access to the test server (the test server belongs to the client).

To anticipate the question: there are no errors reported in the PHP log file. I am actually not convinced that this site is reporting errors to the log file (I haven't seen anything from this site), though the client is certain that everything is turned on.

IIS 7. Integrated mode, I'm pretty sure. Anyone know what could be causing this?

Per Joe's questions:

The name of the block is FiveTalent_BikeCompat_Adminhtml_Block_Bikes .
The class is in the file [magento_root]\\app\\code\\local\\FiveTalent\\BikeCompat\\Adminhtml\\Block\\Bikes.php . The mageFindClassFile function confirms that it finds the file for the class.

I'm pretty sure I am using Magento's loading methods properly. Admittedly the path pattern is a little different from your example, but I think this is because I am trying to create an Adminhtml block. This is the action on the controller that is executing:

public function indexAction() {
    $this->loadLayout();
    $block = $this->getLayout()->createBlock('adminhtml/bikes', 'bikecompat');
    $this->_addContent($block);
    $this->renderLayout();
}

Again, I'm back to the question of the webserver (IIS, in this case) having rights to read the file. I'll see if I can't get hold of someone with access to the server to check this.

Answer 1

error_log php configuration directive can be used to set custom error log
and log_errors one will direct all error messages there.

Answer 2

Errors in __autoload will NOT be displayed, evar. Youre on your own in __autoload. I'd seriously test my __autoload function. I'd check for capitalization errors, it might be an issue.

Answer 3

The Magento autoloader works just fine. Please echo the value of $block and add that to your question. Your block name will probably follow the naming convention: YourCompany_YourModule_Block_Some_Path . If that not the case, that is probably your error. If that is the case, please make sure that the file (obviously, switch path to match your class) app/code/local/YourCompany/YourModule/Block/Some/Path.php exists and contains the right class declaration. If that is also true, make sure that Apache has the rights to read that file.

Once you've figured out this issue, you may want to consider moving over to Magento's loading methods. The "right" way to do this in Magento (assuming the above classname again) is:

<?php
Mage::getLayout()->createBlock("yourmodule/some_path");

Using the Magento loader will save you a lot of trouble later down the road, and allow others to use your Magento code with more assurance.

Hope that helps!

Thanks, Joe