I'm struggling with an issue for which I can't find an explanation. I have two development environments that I use for my projects. I created a simple module for Magento and I tested it on one environment. After overcoming all Magento's complications, the module works as expected. This is on XAMPP.
I then copied the module to the development Linux environment, on a hosted server, and it crashes miserably. I did some debugging, and I found out that a call to Mage::getModel() returns bool(false) instead of the instance of the Model I requested.
I double checked all files and directories, and they match. Database is not involved (not from my side, at least, I don't need tables) and both environments have only me as a User, with Admin permissions.
Any suggestion on where should I start looking is welcome, thanks.
Added on 2012/07/09
Model contains a class named Diego_ClientCustomModule_Model_ExternalUserData, which is invoked with $model = Mage::getModel('clientcustommodule/externaluserdata');. Model file resides in Diego_ClientCustomModule\code\local\Diego\ClientCustomModule\Model\. The curious thing is:
If model file is named Externaluserdata.php, it works.
If model file is named ExternalUserData.php (i.e. it matches the class name), it doesn't work.
I'm aware of case sensitivity stuff etc, but, if the alias is all lower-case, how comes it can load a file having the first letter capitalized?
Configuration file
0.1.0
Diego_ClientCustomModule_Helper
Diego_ClientCustomModule_Model
Diego_ClientCustomModule_Block
standard
Diego_ClientCustomModule
ClientCustomModule
Snarking about the framework for which you are asking for help may not be the best strategy for receiving help.
Your issue is likely one of cache (remove var/cache folder to check) or one of improper casing. Note that the first letter of each directory and filename for files loaded by the autoloader (blocks, models, and helpers).
It seems I have found the root cause of the issue, although I can't figure out what kind of logic has been implemented to make it happen.
Model's file name was UserCustomModule.php, which reflected the class name UserCustomModule. That made sense, and worked wonderfully in XAMPP. Once I installed the same module on a Linux box, Magento silently ignored the file and, as previously stated, there's been no way to track down Magento's actions.
Following benmark suggestion, I went through all the files again to check the casing, and everything seemed to match. I then made something, in my opinion, completely stupid, and I renamed the Model file to Usercustommodule.php, leaving the class name untouched (after all, PHP should behave the same on both platforms, unlike the file system). Magically, the module now works! The file name looks cr*p, but it works.
This solved the problem, yet it raises more questions:
For what reason Magento has troubles loading a file with a CamelCase name? If it's Autoloading, it should simply find a file and load it. After all, it loads the Controller, the Block and everything else, and they are all in CamelCase.
Is it written anywhere that one or more files must have only the first letter capitalized? I got enough surprises already, I'd like to avoid new ones, if possible.
Thanks again for the help.
Related
I'm having an Issue with a blog extension in Magento CE 1.6.2.0.
I installed this extension: Neotheme_nBlog.
I created an entry in the administrator.
Then I went to http://www.example.com/index.php/blog/ to see the recently created entry.
What I saw was an error like this:
Fatal error: Call to a member function getName() on a non-object
in /home/example.com/public_html/app/design/frontend/default/caramel/template/magicat/left.phtml
I searched in google the terms: "template/magicat/left.phtml" getName and what I only found is sites having this issue, but no support at all.
Please note: I know what does that error mean in PHP ("unfortunately" I'm not new at that). What I don't understand is what's happening with such [NON/null] object and how to fix it without killing a dozen of kittens.
Question: What can I do to solve it? What is the nature of the error, regarding Magento?(again: not PHP).
Notes: The Magento site (http://magento.stackexchange.com) is somewhat poor and strict to bring support of such nature, so asking there is not an option.
Edit (as answer to comment, and to clarify):
Neotheme is still not responding the request.
Don't know what should I look on such file (instances are not initialized there, but only accessed).
I'm using the default theme (caramel), which has esthetical changes (does not have layout changes).
It's hard to say without seeing your system specifically, but on this
template/magicat/left.phtml
It looks like you've added a template named magicat/left.phtml to your system -- either via an extension or custom development. Somewhere in this file PHP's called getName on a non-object. There's a variety of reasons this could be happening, and without seeing the specific line of code PHP's complaining about in your system, it's hard to say. It'd also be helpful to know if magicat is part of the extension or something else.
The most common reason for this error in a template is code that relies on a block being there that's been removed by another extension (eitehr via layout XML or observer methods)
$this->getLayout()->getBlock('some_block')->getName();
The next most common is people using the registry to communicate between templates and views, but a registry key not being set
Mage::registry('some_item')->getName();
Without knowing the variable and context, it's doubtful anyone will be able to help you.
I installed a new module and now I get this error and can't log into the admin area of Magento:
Warning: include(Mage/Awautorelated/Helper/Data.php): failed to open stream: No such file or directory in /var/www/spasandstuff.com/lib/Varien/Autoload.php on line 93
I have removed the module, cleared the cache and session folders and it still gives me that error.
I ran grep -r "Awautorelated" * and found nothing on the server. I restarted Apache to clear APC cache. Magento uses Lightspeed but I believe that just uses the Magento cache directory which I cleared. So I am at a loss as to how to fix this issue. Is there a database table that caches module info?
Any help will be greatly appreciated.
Somewhere, a piece of Magento code is attempting to instantiate a helper class with code that looks something like
Mage::helper('awautorelated');
Mage::helper('awautorelated/data');
Since you've removed the module from the server and cleared your cache, there's no <model> node for the <awautorelated> group. That's why Magento is looking for this class in Mage/Awautorelated instead of AW/Awautorelated.
Based on everything you've said, my guess is you have an XML file somewhere, likely in the layout, that still contains an attribute something like this
<sometag ... module="awautorelated" ...>
These module attributes are used to specify a translation helper for "inner nodes". Your Magento system loads the XML file, parses it, sees the module="awautorelated", and then attempts to instantiate a awautorelated helper to translate the nodes. Since you've remove that module files, it can't instantiate the helper and yells at you. Try a case insensitive grep (or ack)
grep -i -r 'awautorelated'
and make sure you search the entire Magento source tree. Not just app/code, but app/design as well.
Did you remove
AW_All.xml
AW_Productrelater.xml
from /app/etc directory
Yes, there is the table core_config_data, but I don't expect removing the module entry from their will be realted to this problem, but you can certainly remove the entry now the module has been removed.
Are you using memcached for caching? you could remove that. I'm not 100% sure restarting apache clears the APC cache either ...
I am working on a project where I create Two Application hosted in same site.
My structure is given below…
SITE
SYSTEM
APPLICATION
font_end
back_end
Now my question is,is it possible to access model of one application from another application.
As example, I have a model named ‘User_model’ in font_end application. Is it possible to use this model from back_end application.
Thanks.
Yes, it is possible, but there is a but. It doesn't matter where your files are in an absolute sense, but it is not necessarily the easiest thing in the world to accomplish.
Your best bet is to use symlinks if you can and link them into a sub-directory of your models directory. This would be simple and clean.
Barring that, you should extend Loader and overwrite the &model method to look in the secondary directory (perhaps reassign $path to the alternate application's model folder if $path == 'frontend').
If that also isn't an option, loading is done through APPPATH.'models/'.$path . '/' .$model.EXT. This means you can access the model by the relative path to APPPATH.'models/'. Don't do that if you can possibly avoid it, however. It is non-obvious and an invitation to errors.
I tried your last version (error prone I know) and got this result:
Unable to locate the model you have specified: ext.
I used this load code to access the frontend model from my backend:
$this->load->model('APPPATH.'/models/frontend/'Frontend_Model'.'EXT');
apppath and ext constants should be used like variables, but if I put it this way my notepad ++ highlighting goes wrong:
$this->load->model(APPPATH.'/models/hp/'Homepage_Model'.EXT)
admin/application/model/accounts_model.php
application/controller/home.php
Put this code in home.php to use model of admin applicaton
$this->load->model('../../../Unicorn/application/models/accounts_model');
I am working on a new module of existing live project. It is a website developed in PHP Zend Framework. New module is on admin side. It runs properly on my localhost/virtualhost.
When I uploaded it online with correct directory path it is found that one file is not found.
It is called like
www.example.com/admin/controllerName/actionName
All the actions works except one action that doesn't display anything and returns exception error mentioning that page or file not found.
What could be the issue? I have checked folders. If one action for the same controller works than why doesn't other. Both have their .phtml files in View section.
Help would be appreciated.
Would I be right if I guessed your local development environment was Windows?
It's probably a filename case sensitivity issue.
Assuming your request looks like
www.example.com/admin/fusionmaps/newpage
I'm not sure how you've setup your modules but if it's reasonably standard, you should have something like this (note the upper and lowercase characters)
application/modules/admin/controllers/FusionmapsController.php
The controller classname should be Admin_FusionmapsController with action public function newpageAction()
The view script should be at
application/modules/admin/views/scripts/fusionmaps/newpage.phtml
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.