I do have my own Controller in Magento, that has been done by following the guidelines here:
http://alanstorm.com/magento_admin_controllers
My controller extends Mage_Adminhtml_Controller_Action and inside there is a method:
public function myAction() {
sleep(1000);
die('I am done');
}
When this method is running I cannot load any other Magento Admin pages. They will load eventually right after the method above is complete.
Also Frontend works fine, running the very same action from the Frontend controller does not cause Magento to hang like this.
Any solutions to keep my method in Admin and while this method is running, rest of the admin should stay usable?
Longest time this process runs is about 4-5 hours and it imports products. Yes I do have cron also set up, but I would like to give the user the ability to init processes at will also.
This is a feature.
The workaround is to use two browsers, e.g. Firefox + Chrome, Firefox + Opera and so on.
It is better to work two-browser on these tasks as you don't want a crash in your other tabs to interrupt your import.
I know that is not an in-depth programming answer, sometimes the lateral solution works though.
Have to answer this myself:
Solution is mega simple:
call this right before the long process (make sure that you have done manipulating the session data before calling this method, otherwise errors may occur)
session_write_close();
And voila, you can run multiple processes at the same time!
Related
I upgraded my application from CI2 to CI3 (CI v3.1.9 and PHP7). Now I have performance issue with the new concurrency system in the session (see doc).
Some of the actions in the application are very long (because of calling an external APIs that can takes several minutes to respond for example) and I don't want those actions to lock the session. As recommended, I would use session_write_close() function in the controller before doing the very long action.
The problem is that I want to display a message to user after redirecting at the end of this action. Right now, I am using session->set_flashdata() before the redirection, but because I closed the session earlier, it is not working.
Does anyone have recommendations on how to achieve that?
If I am starting the session again with session_start() it is working, but I have no idea if this is best practice to use PHP session like that with Codeigniter.
There is no problem with starting the session again using session_start(). The CodeIgniter "Session" class is still loaded and the instance is still valid. So all the "special" stuff that CI does to make sessions work is good to go.
I tested and then used this scheme in a project some time back and didn't experience any problems. Haven't had any blow-back from the client of a still operating site either. YMMV.
BTW, in the __construct() function of the CI_Session class a call to session_start() is made in order to start up PHP's session extension. So making that call is clearly not a "bad" practice. :)
In my app when the app is resumed from a sleep, I'd like to
reload the page - or ideally, just update specific UI elements.
How can this be done?
Preferably in a platform independent way.
You want to hook into the onResume method in the application module which exposes the event when an app resumes from the background.
https://docs.nativescript.org/api-reference/modules/application.html#onresume
So in your app.js (the entry point of your application), import the module and add the onResume event handler and it can run everytime the app resumes. Now reloading a page will require a little more work. You'd have to use the frame module and find out the current page and do your work, but I'm guessing it can be done with a little effort using the approach mentioned.
UPDATE: based off your comment, you need the reloadPage() method from the ui/frame module. https://docs.nativescript.org/api-reference/modules/_ui_frame_.html#reloadpage
The correct method is reloadPage() in the Frame module (as contributed by #Brad) but the problem is that it's NOT an exposed api.
No problem - just copy/paste it and it works.
The problem is that it basically does a navigateTo() to the currentPage and that effects the navigation history. You have 2 choices - setting clearHistory to true and you lose all history (don't want that) or set clearHistory to false which creates a a duplicate of the current-page (don't want that either). There's also a backstackVisible option but that doesn't help in this scenario.
#Brad tells me that there's api that allows access to the navigation stack - haven't looked into it.
For my app - the user will be at the root page most of the time, so I decided to reload the page only if on the root page and then set clearHistory to true and that works for me.
I just upgraded my app from CakePHP 1.3 to 2.3. The upgrade console is far from perfect, but after a day of debugging, I've solved most of the issues. There's just one left, and it's a big one: Sessions.
In my app I am not using any of the fancy $this->Session or CakeSession::read login, I've always relied on PHP Superglobal $_SESSION. In 1.3, that worked fine.
Enter CakePHP 2.3: Sessions seem to work only at some places in my functions, and for unknown reasons, they are sometimes empty. One example: in line 1 of a function in a controller, $_SESSION['key'] gives me an empty array, in line 10 it will give me a nicely populated array, and in my view it's empty again. Extremely frustrating. I've been able to solve this by calling session_start() when it doesn't work, but I don't want to go down that road.
The documentation states:
Usage of the $_SESSION is generally avoided in CakePHP, and instead usage of the Session classes is preferred.
I'm a bit surprised: Cake runs on PHP, so I would expect PHP superglobals to work.
I'm considering switching to CakeSession::read and CakeSession::write, but that's a laborious task: I'm using Sessions throughout my app.
Before switching, I'd like to know:
Is there a way to make the normal PHP $_SESSION superglobal work in Cakephp 2.3.7?
If not: is CakeSession::read and CakeSession::write the right alternative?
Some extra info:
I am calling the Session component in my AppController
I am calling the Session helper in my AppController
In general, you could access $_SESSION itself, but then you would need to assert session start and other things manually, as well - which CakePHP can and should take care of itself.
So why bother when you got a nice wrapper access to it?
I dont really see why this needs to be a question here. There are usually bigger fish to fry.
Believe me when I say that everyone uses the clean and neat component/helper/CakeSession access.
Also a nice site effect: You cannot trigger any "undefined index" warnings with the wrapper methods. They would simply return null if this key has not been set yet.
I am calling the Session component in my AppController
I am calling the Session helper in my AppController
No, helpers are for the view layer.
I took over an implementation of Magento Enterprise.
There is a URL that looks something like this:
mydomain.com/our-solutions
It's got a dynamic part to it; under the CMS tab in the Admin I don't see anything that matches that URL.
In the extended local files, I don't see anything in the config for it but it seems to know to load up a particular template.
I need to be able to modify the controller for this particular page. Any advice would be great.
Thanks.
The quick and dirty way would be to temporarily add some debugging code to the following file
# File app/code/core/Mage/Core/Controller/Front/Action.php
public function preDispatch()
{
//log out the class name
Mage::Log( get_class($this) );
//or just dump it if you don't know how logging works
var_dump(get_class($this));
$this->getLayout()->setArea($this->_currentArea);
parent::preDispatch();
return $this;
}
This will let you discover which class file is the controller for the request, and you can code trace from there.
Also (shameless plug time) I build and sell a commercial product that will (among other things) allow you to (among other things) instantly zero in on which controller, block, model, or collection was used for a particular request. There's a demo page you can checkout, and while it's clearly self-serving of me to mention it, I also truly believe it's the best way for a developer to work with Magento.
So on one of our recent launches we had a lot of events that we were observer such as controller_action_predispatch. Once the site went live we started noticing that our observers were never getting called for those. After a little investigation one of our developers found this block of code in Mage_Core_Model_App around line 292
if ($this->_cache->processRequest()) {
$this->getResponse()->sendResponse();
} else {
$this->_initModules();
$this->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS);
if ($this->_config->isLocalConfigLoaded()) {
$this->_initCurrentStore($scopeCode, $scopeType);
$this->_initRequest();
Mage_Core_Model_Resource_Setup::applyAllDataUpdates();
}
$this->getFrontController()->dispatch();
}
As you can see if $this->_cache->processRequest() that is true which it is when full page cache is enabled you never get to the dispatch. The developer did find http_response_send_before which gets call either way but it seems to me like this is a bug or you should never ever use those controller dispatch events for anything if you have full page caching enabled. Any thoughts?
Given the nature of the full page caching, I'd call this "works as intended". While it can be a little strange not to have some events firing, they had to pick a line and this one makes sense to me, especially since the controller is never really dispatched.
You should use those controller dispatch events for anything that affects the page (as it still needs to be generated), but if you are using it for tracking and such, no it would not be appropriate.
See here if you want to learn how Caching works with Magento Enterprise
http://magentophp.blogspot.com/2011/02/magento-enterprise-full-page-caching.html
The only reliable event to listen for with and without Full Page Cache enabled is http_response_send_before.
controller_front_send_response_before
This event will be fired irrespective of FPC enabled