Since today in all my apps this error started to show:
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/fb/index.php:5) in /home/fb/facebook.php on line 37
What changes ware made by Facebook today and how can I fix this?
You should remove any code above session_start().
Generaly this function sould be executed before any output. (For example HTML code)
Another posibility it that the file encoding is not correct.
Check for spaces and etc. before session_start().
// whitespace, any mark up or include that displays something <HERE>
// it will give you that error
<?php
session_start();
Related
If I try to log benchmark->elapsed_time() in post_system hook, it just logs {elapsed_time} as if I called it from a controller.
CodeIgniter documentation says:
"post_system Called after the final rendered page is sent to the browser, at the end of system execution after the finalized data is sent to the browser."
It also says you are supposed to echo the elapsed_time() in a view to show it to the user, but... how is it possible that elapsed_time() is still being calculated after sending the finalized data to the browser?
I feel being lied to.
People keep saying I should use my own marks and get the difference, but that's not the same as using this...
Turns out the documentation also says:
"If the first parameter is empty this function instead returns the {elapsed_time} pseudo-variable. This permits the full system execution time to be shown in a template. The output class will swap the real value for this variable."
I went to the Output class and found the 2 marks it is using: total_execution_time_start and total_execution_time_end and I can use those in the post_system hook.
I'm starting from the minimal derby application created by derby new first-project. Thereby, the body of the produced html is written in a single line. How can I switch that behavior off to get a pretty printed html to be able to track down bugs like Uncaught SyntaxError: Unexpected token <?
If your problem is indeed single-line html, then your answer is x-no-minify: http://derbyjs.com/#whitespace_and_html_conformance.
However, I think your problem is just that the derby starter-project generator, and the examples, are way out of date. Use the derby-boilerplate project
In the last 2 weeks or so, I've suddenly started getting reports of users getting an error in our application saying "Expected response code 200, got 400. Unable to convert document." This is code that has been in place for years without any issue. We are using Zend Framework (GData) in conjunction with Google Docs (AuthSub).
We are logging the issue to a text file when it happens. When it gets logged, the user often tries multiple times (sometimes separated by a few seconds, other times separated by longer times) and it continues to fail. The code in question just creates a new Google document in the user's account and gives it a title (no body content).
Originally, I used this code:
// Create new document
$data = new Zend_Gdata_Docs_DocumentListEntry();
$data->setCategory(
array(new Zend_Gdata_App_Extension_Category(
"http://schemas.google.com/docs/2007#document",
"http://schemas.google.com/g/2005#kind"
)));
$data->setTitle(new Zend_Gdata_App_Extension_Title($title, null));
// Add document to your list
$test = $sharedocs->insertDocument($data, Zend_Gdata_Docs::DOCUMENTS_LIST_FEED_URI);
To experiment and see if there was an issue with that particular function, I tried creating a blank word doc and changing the code to:
$test = $sharedocs->uploadFile('/mypath/empty.doc', $title, null, Zend_Gdata_Docs::DOCUMENTS_LIST_FEED_URI);
However, I'm still seeing the "Unable to convert document" errors. They are relatively infrequent, and I am not able to reproduce the issue on my own computers here. The $title variable does not contain anything unusual (special characters, etc.).
This code was all working fine before -- is there a known issue with the Google Docs API right now? What else can I try?
NOTE: Please see my follow-up comments below, where I have identified the reproducible scenario in which this error occurs.
I had exactly the same problem, but I noticed that I could use the api to save a presentation if not a document... so, it is a terrible hack, but I try to save the document (works if the account has already been accessed)... if that fails, I save and delete a presentation and retry to save the document, which then works. Horrible, horrible, horrible hack
Hello and thanks for your time!
While trying to implement the Form Wizard I ran into a couple of problems.
Using xdebug showed up that all submitted data is lost, what means:
$this->data, $_POST and $params['data'] / ['form'] are all empty.
It seems that cake is doing some kind of redirect / dispatching and the actions are called twice. When I set a breakpoint in the beforeFilter() method, I can see all data filled in properly.
There were some suggestions in other discussions that this could be caused by invalid links in the layout, but using an empty layout didnt change anything.
I also removed the Auth Component, the RequestHandler, Helpers to see if theres something happening... nothing.
Problem is, Im quite new to Cake and have no further ideas where to look.
Currently Im getting this Warning:
Warning (512): Step validation: daten is not a valid step. [ROOT/plugins/wizard/controllers/components/wizard.php, line 271]
Code | Context
return $this->controller->autoRender ? $this->controller->render($this->_currentStep) : true;
} else {
trigger_error(sprintf(__('Step validation: %s is not a valid step.', true), $step), E_USER_WARNING);
$step = "daten"
WizardComponent::process() - ROOT/plugins/wizard/controllers/components/wizard.php, line 271
SignupsController::wizard() - ROOT/plugins/bookings/controllers/signups_controller.php, line 18
Dispatcher::_invoke() - CORE/cake/dispatcher.php, line 204
Dispatcher::dispatch() - CORE/cake/dispatcher.php, line 171
[main] - ROOT/webroot/index.php, line 83
Dont think that helps much, cause the $step array is also lost.
Any idea deeply appreciated! :)
The issue is that the session has expired and the information is lost that the system keeps tracking progress and data with. Set your session to be longer in the security preferences in the core config. This still doesn't stop the error though. To fixed that replace:
trigger_error(sprintf(__('Step validation: %s is not a valid step.', true), $step), E_USER_WARNING);
to:
$this->reset();
This will send the user back to the first part of the form wizard. You will have lost all the user data but that happened by the session expiring in the first place or if someone tries to jump to a form which hasn't been accessed yet by using the form, it will also reset. This could be a good security measure or just plain annoying.
Anyway, that is my solution, there could be better ones.
I have been programming with NSXMLParser for quite a while and lately, I came out with this error. The strangiest thing is that it only happens in debug mode. Once I load the App in Simulator and run it from Simulator (without Xcode involved), it runs fine.
The code is very straight foward, it is a simple XML parsing whose contents were loaded from the web in a separated thread.
Does anybody have alredy encoutered that error??
Thanks in advance.
EDIT:
In time I realized that this error occur when you have a bad formated XML Document. In my case, I was extracting some of the contents of an HTML Page and parsing the resulting string, but this string was not allways well formed. A little modification an voilá...
Ensure that your documents are well formed when parsing or you may have the same mistake...
PS: The parser error method did not catch this error.
In time I realized that this error occur when you have a bad formated XML Document. In my case, I was extracting some of the contents of an HTML Page and parsing the resulting string, but this string was not allways well formed. A little modification an voilá...
Ensure that your documents are well formed when parsing or you may have the same mistake... PS: The parser error method did not catch this error.