Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assumption Mage::app()->getFrontController() is set #85

Open
ajbonner opened this issue Jul 21, 2015 · 5 comments
Open

Assumption Mage::app()->getFrontController() is set #85

ajbonner opened this issue Jul 21, 2015 · 5 comments

Comments

@ajbonner
Copy link

I run a lot of unit tests which do not cause the frontcontroller to be inited/dispatched. These tests break when certain events require design & layout be loaded.

https://github.com/zendesk/magento_extension/blob/master/src/app/code/community/Zendesk/Zendesk/Model/Observer.php#L23

The above referenced code runs when layouts are loaded and it looks to the front controller to determine an active handle/route path.

This assumes that Mage_Core_Model_App::run() is called, which is only necessary if you are dispatching an http request. Shell scripts, cron jobs, unit tests for example, may have some need to load layout but not run a full request->response cycle.

I think the easiest solution here would be simply to do an if check on the frontController being an instance of Mage_Core_Controller_Varien_Front before trying to access the getActionName var.

@ajbonner ajbonner changed the title Assumption frontController is set Assumption Mage::app()->getFrontController() is set Jul 21, 2015
@jwswj
Copy link
Contributor

jwswj commented Aug 7, 2015

Hey @ajbonner - we've never had experience with this kind of setup before. Your solution sounds plausible, would be great if you could submit it as a pull request.

@dave-swift
Copy link
Contributor

We have this issue, too. This is causing API requests to return a 500 error which is obviously pretty annoying. The requests are using the light API call method via /api.php.

After digging into it a little, I am disappointed to see that this observer is set up to listen to core_block_abstract_to_html_after. That means your code is called after every block in the admin is rendered just to add a new block on one particular page. I would suggest changing it to listen to something like controller_action_predispatch_adminhtml_dashboard_index instead since that's the only page you are looking for anyway.

It would be even better if you got rid of the observer completely and did it through the layout XML files, but that could be a little more complicated (depending on the situation).

dave-swift added a commit to thegrommet/magento_extension that referenced this issue Mar 7, 2016
@antoinekociuba
Copy link

antoinekociuba commented May 9, 2016

Hi all,

I confirm that I have the same problem mentioned above, when the cron is running :

Fatal error: Call to a member function getFullActionName() on a non-object in .../app/code/community/Zendesk/Zendesk/Model/Observer.php on line 23

And because it is thrown when cron is running, I got an error email every 5 minutes in my inbox :p.

Thank you in advance for considering this issue.

(BTW, I'm using latest module version (2.1.4))

@akkermanronald
Copy link

Hi all,

We have this issue when adding tracking # through the api. We will test the PR proposed by Dave.

@gertmedia24
Copy link

gertmedia24 commented Feb 26, 2018

Hi, any plans to review this PR and hopefully merge in? We're having similar issues with
PHP message: PHP Fatal error: Uncaught Error: Call to a member function getFullActionName() on null:

https://magento.stackexchange.com/questions/215068/two-exact-same-email-template-blocks-one-triggers-event-other-doesnt

https://magento.stackexchange.com/questions/215078/observer-method-not-being-triggered

joseconsador added a commit that referenced this issue Apr 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants