Checking if a file exists and otherwise using a fallback shouldn't be done as a general approach for performance reasons, but I can imagine cases where that would make sense.
In general you can use
$templateFile = Mage::getBaseDir('design') . DS . $block->getTemplateFile();
if (! file_exists($templateFile)) {
....
}
This checks if the current template exists anywhere in the configured fallback or the base theme.
Assuming you've setup Magento's admin area to use comapnyname
, as per Ben's answer, if you're still running into trouble, I'd jump right to the source.
The Mage_Core_Model_Design_Package
class is where Magento decides which files to use for a theme. First the current theme is checked. If nothing's found there, then the default
theme is checked. That check happens here
#File: app/code/core/Mage/Core/Model/Design/Package.php
public function validateFile($file, array $params)
{
$fileName = $this->_renderFilename($file, $params);
$testFile = (empty($params['_relative']) ? '' : Mage::getBaseDir('design') . DS) . $fileName;
if (!file_exists($testFile)) {
return false;
}
return $fileName;
}
I'd temporarily add some poor man's logging to this function to see the file's Magento is actually accepting or rejecting during a request.
#File: app/code/core/Mage/Core/Model/Design/Package.php
public function validateFile($file, array $params)
{
$fileName = $this->_renderFilename($file, $params);
$testFile = (empty($params['_relative']) ? '' : Mage::getBaseDir('design') . DS) . $fileName;
if (!file_exists($testFile)) {
file_put_contents('/tmp/design-files.log',"REJECT: $testFile\n",FILE_APPEND);
return false;
}
file_put_contents('/tmp/design-files.log',"ACCEPT: $testFile\n",FILE_APPEND);
return $fileName;
}
My guess is you've got a subtle, hard to spot typo in one of your file paths. Try
ls -l [filename]
with the results from the above logging.
Update: Based on the comments you've made, it sounds like you're working with a system where someone has customized things to work differently, and the behavior is a side effect on that.
The two tacts I'd take on debugging this are
Figure out how your system sets the value for customtheme
, and why this code isn't called when the page renders the Custom Options section
The custom options are rendered via ajax. Normally, this is with a URL that looks like the following
http://magento.example.com/index.php/admin/catalog_product/options/id/166/key/2d18a7efe76c64829ba80b26aa153875/?isAjax=true
and the render is handled in the optionsAction
method of
app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php
I'd look into if this is different on your system, either via a URL rewrite or a controller override of some kind. This may explain why this particular URL is ignoring the custom theme.
Good luck!
Best Answer
Unfortunately the
core/messages.phtml
file is not used for the messages you're speaking of. All the HTML is generated on the Block level inMage_Core_Block_Messages
.The good news is you can control the tags used in the messages by calling these functions:
Mage_Core_Block_Messages::setMessagesFirstLevelTagName($tagName)
Mage_Core_Block_Messages::setMessagesSecondLevelTagName($tagName)
An example of implementing this would be to modify your
layout/page.xml
file by finding the lines that read:And changing them to something like:
And if you need even more control then you could override the block in your own module and customise the
getHtml()
andgetGroupedHtml()
methods.Happy styling!