Prerequisites: Running on Ubuntu. Using Apache. Yii version is printing 1.1.2.
My question:
I'm helping a friend out with a web app where his application developer abruptly quit. The problem is, I'm somewhat green with PHP and COMPLETELY green with Yii. I'm having a difficult time setting up a test server using the existing code. What's happening is the index.php code calls a CWebApplication-derived class, but the run() method never returns, and all I get is a blank page (this obviously doesn't happen in production). I'm trying to understand how to identify what's happening, and where the execution is just dying.
First, let me say that I ran http:///yii/requirements/index.php, and the requirements checker claimed I had the minimum requirements to run.
Second, my index.php looks like this:
ini_set('display_errors',1);
// change the following paths if necessary
$yii=dirname(__FILE__).'/yii/framework/yii.php';
$config=dirname(__FILE__).'/protected/config/main.php';
$gapi = dirname(__FILE__) . '/protected/vendors/Google/autoload.php';
// remove the following lines when in production mode
defined('YII_DEBUG') or define('YII_DEBUG',true);
// specify how many levels of call stack should be shown in each log message
defined('YII_TRACE_LEVEL') or define('YII_TRACE_LEVEL',3);
require_once($gapi);
require_once($yii);
/*
* Manage URL Uppercase or lowercase
*/
$manage_url_path = dirname(__FILE__) . '/protected/components/ManageUrl.php';
require_once( $manage_url_path );
$create_web_application = new ManageUrl($config);
$create_web_application->run();
When $create_web_application->run() executes, it never returns (printing after it prints nothing), and I get just a blank page.
This class (ManageUrl) overrides createController, but so far it feels like execution never makes it to this function. Placing any print() statements in there shows nothing. $Yii::log() also shows nothing. There's nothing in the application.log under /runtime. Apache's error logs are showing nothing too. It's as if code execution is just going into a black hole.
One final thing to note: I've got mod_rewrite enabled on the server. I followed this outdated howto on DigitalOcean to get things started (https://www.digitalocean.com/community/tutorials/how-to-install-and-setup-yii-php-framework-on-ubuntu-12-04).
Can you advise me on how to figure out what's going on with this application and why I just get a blank page? I need to figure out where the code execution is going and subsequently dying.
Related
I am using mobDebug. If run a lua script from command line everything works.
But when I run them from openresty the Idea doesn't stop. It only writes "Connected/ Disconnected"
Configs:
location / {
access_by_lua_block {
local client = require("client")
}
client.lua:
local mobdebug = require("mobdebug");
mobdebug.start()
local lfs = require("lfs")
print("Folder: "..lfs.currentdir())
modebug debug_hook is not invoked for needed lines, set_breakpoints don't invoked.
Idea Debug Logs, but nothing occures:
Idea catch debug from terminal client.lua; But it miss it from running nginx.
THIS IS NOT AN ANSWER. It's just that I am experiencing basically the same problem, and comment space is too small to fit all the relevant observations I would like to share:
I was actually able to stop immediately after mobdebug.start() in code running in nginx, and to step-debug - but only in code called directly from init_by_lua_block. This code of course executes once during the server startup or config reload.
I was never able to stop in worker code (e.g. rewrite_by_lua_*). mobdebug.coro() didn't help, and mobdebug.on() threw about "attempt to yield across C-call boundary"
I was only ever able to stop one time, on next statement after mobdebug.start(); once I hit |> (Resume program), it won't stop on any further breakpoints.
Using mobdebug.loop() is not a correct way to do this, as it's used for live coding, which is not going to work as expected with this setup. mobdebug.start() should be used instead.
Please see an example of how this debugging can be setup with ZeroBrane Studio here: http://notebook.kulchenko.com/zerobrane/debugging-openresty-nginx-lua-scripts-with-zerobrane-studio. All the details to how paths to mobdebug and required modules are configured should still be applicable to your environment.
I get the following error within Magento CE 1.6.1.0
Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cookie - headers already sent by (output started at /home/dev/env/var/www/user/dev/wdcastaging/lib/Zend/Controller/Response/Abstract.php:586) in /home/dev/env/var/www/user/dev/wdcastaging/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 119
when accessing /api/soap/?wsdl
Apparently, a session_start() is being attempted after the entire contents of the WSDL file have already been output, resulting in the error.
Why is magento attempting to start a session after outputting all the datums? I'm glad you asked. So it looks like controller_front_send_response_after is being hooked by Mage_Persistent in order to call synchronizePersistentInfo(), which in turn ends up getting that session_start() to fire.
The interesting thing is that this wasn't always happening, initially the WSDL loaded just fine for me, initially I racked my brains to try and see what customization may have been made to our install to cause this, but the tracing I've done seems to indicate that this is all happening entirely inside of core.
We have also experienced a tiny bit of (completely unrelated) strangeness with Mage_Persistent which makes me a little more willing to throw my hands up at this point and SO it.
I've done a bit of searching on SO and have found some questions related to the whole "headers already sent" thing in general, but not this specific case.
Any thoughts?
Oh, and the temporary workaround I have in place is simply disabling Mage_Persistent via the persistent/options/enable config data. I also did a little bit of digging as to whether it might be possible to observe an event in order to disable this module only for the WSDL controller (since that seems to be the only one having problems), but it looks like that module relies exclusively on this config flag to determine it's enabled status.
UPDATE: Bug has been reported: http://www.magentocommerce.com/bug-tracking/issue?issue=13370
I'd report this is a bug to the Magento team. The Magento API controllers all route through standard Magento action controller objects, and all these objects inherit from the Mage_Api_Controller_Action class. This class has a preDispatch method
class Mage_Api_Controller_Action extends Mage_Core_Controller_Front_Action
{
public function preDispatch()
{
$this->getLayout()->setArea('adminhtml');
Mage::app()->setCurrentStore('admin');
$this->setFlag('', self::FLAG_NO_START_SESSION, 1); // Do not start standart session
parent::preDispatch();
return $this;
}
//...
}
which includes setting a flag to ensure normal session handling doesn't start for API methods.
$this->setFlag('', self::FLAG_NO_START_SESSION, 1);
So, it sounds like there's code in synchronizePersistentInf that assumes the existence of a session object, and when it uses it the session is initialized, resulting in the error you've seen. Normally, this isn't a problem as every other controller has initialized a session at this point, but the API controllers explicitly turns it off.
As far as fixes go, your best bet (and probably the quick answer you'll get from Magento support) will be to disable the persistant cart feature for the default configuration setting, but then enable it for specific stores that need it. This will let carts
Coming up with a fix on your own is going to be uncharted territory, and I can't think of a way to do it that isn't terribly hacky/unstable. The most straight forward way would be a class rewrite on the synchronizePersistentInf that calls it's parent method unless you've detected this is an API request.
This answer is not meant to replace the existing answer. But I wanted to drop some code in here in case someone runs into this issue, and comments don't really allow for code formatting.
I went with a simple local code pool override of Mage_Persistent_Model_Observer_Session to exit out of the function for any URL routes that are within /api/*
Not expecting this fix to need to be very long-lived or upgrade-friendly, b/c I'm expecting them to fix this in the next release or so.
public function synchronizePersistentInfo(Varien_Event_Observer $observer)
{
...
if ($request->getRouteName() == 'api') {
return;
}
...
}
I had to move a website on a bluehost server, that is in the Joomla Platform 1.7. I did alot of reasearch on Joomla.org and google and still haven't resloved the issue.
I recieve the following error: Infinite loop detected in JError. I went threw the configuration file and made sure that database and user match up with my new database parameters match up and I am still recieving this issue. Thank you. Urgent response will be very helpful. Currently working on this and this is not a good start. :(
I have ran into the same issue moving my Joomla site from one server to another. What I learned is the following;
Make sure you look at the parameters in configuration.php. Double check if the following variables in your configuration.php file is correct. (Double Check) You did mention that you already have done so. In that case I am 98% sure that you have an issue dealing with file Attributes with configuration.php. Change the Attributes of configuration.php from 444 to 666.
To get detailed information about the error, open the error.php file located in /libraries/joomla/error/ on your server.
In the following code:
public static function throwError(&$exception)
{
static $thrown = false;
// If thrown is hit again, we've come back to JError in the middle of
throwing
another JError, so die!
if ($thrown) {
// echo debug_print_backtrace();
jexit(JText::_('JLIB_ERROR_INFINITE_LOOP'));
}
change the line // echo debug_print_backtrace();
to the following:
**print"<pre>";
echo debug_print_backtrace();
print"</pre>";**
Remember- When you change the parameters in configuration.php to you new database make sure you that configuration.php file attribute is set to 666, Otherwise when you go to save the file it will not change. Try this first.. Good luck.
When selenium tries to open popup window I'm getting JS error permission denied in file
file:///C:/DOCUME~1//LOCALS~1/Temp/customProfileDir8708f7f69e14482ba857f4b2e74775c1/core/RemoteRunner.hta
So this break script execution, could you assist? I saw a related topic at MSDN and openqa but didn't find resolution that could help me.
I've just encountered this error. In the end it was because I was running IE in 'Offline' mode. Open the File menu and make sure that "Work Offline" does not have a tick next to it.
I've just updated a section about that in the Selenium docs. The website build is not working right now, so if you go to the site you will find the old version.
I'll paste the raw text here, I think your case is the second: JS trying to access sections that are still not loaded, so your solution would be a waitForPopUp command:
Why am I getting a permission denied
error?
The most common reason for this error
is that your session is attempting to
violate the same-origin policy by
crossing domain boundaries (e.g.,
accesses a page from http://domain1
and then accesses a page from
http://domain2) or switching protocols
(moving from http://domainX to
https://domainX). For this to be
solved, try using the Heightened
Privileges Browsers if you're working
with the Proxy Injection browsers.
This is covered in some detail in the
tutorial. Make sure you read the
sections about The Same Origin Policy
and Proxy Injection carefully.
If the previous situation was not your
case, it can also occur when
JavaScript attempts to look at
objects which are not yet available
(before the page has completely
loaded), or tries to look at objects
which are no longer available (after
the page has started to be unloaded).
This is most typically encountered
with AJAX pages which are working with
sections of a page or subframes that
load and/or reload independently of
the larger page. For this type of
problem, it is common that the error
is intermittent. Often it is
impossible to reproduce the problem
with a debugger because the trouble
stems from race conditions which are
not reproducible when the debugger's
overhead is added to the system. Try
first adding a static pause to make
sure this is the situation and then
moving on to the waitFor kind of
commands.
I have a program that checks if a file is present every 3 seconds, using webrequest and webresponse. If that file is present it does something if not, ect, that part works fine. I have a web page that controls the program by creating the file with a message and other variables as entered into the page, and then creates it and shoots it over to the folder that the program is checking. There is also a "stop" button that deletes that file.
This works well except that after one message is launched and then deleted, when it is launched the second time with a different message the program still sees the old message. I watch the file be deleted in IIS, so that is not the issue.
I've thought about meta tags to prevent caching, but would having the file be dynamically named solve this issue also? How would I make the program be able to check for a file where only the first part of the filename is known? I've found solutions for checking directories on local machines, but that won't work here.
Any ideas welcome, thanks.
I'm not that used to IIS, but in Apache you can create a .htaccess and set/modify HTTP-Headers.
With 'Cache-Control' you can tell a proxy/browser not to cache a file.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
A solution like this may work in IIS too if it is really a cache problem.
(To test this, open using your preffered browser with caching turned off
A simple hack is to add something unique to the url each time
http://www.yourdomain.com/yourpage.aspx?random=123489797
Adding a random number to the URL forces it to be fresh. Even if you don't use the querystring param, IIS doesnt know that, so executes the page again anyways.