I didn't change any code, all of a sudden when I visited one of the webpages, I see
Warning: session_start() [function.session-start]: open(..)Failed: File too large .. index.php on line 2.
Another error is:
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent`
Line1 : <?php
Line2 : session_start ();
Questions:
what is the reason for error that tells File too large? what file is large?
why all-of a sudden there is an error without any file modification being done?
why it is throwing 'headers already sent', when there is nothing defined before session_start, not even a space ?
How to fix this issue?
1. what is the reason for error that tells File too large? what file is large?
This seems to be the hosting provider issue, as the original file was never modified, and the webpage has been tried from multiple browsers even after clearing the cache.
When you do session_save_path("../_session1001"); that is mentioned below, you can see that your session is written to that path, so may be that this file was becoming too large in your shared memory,and now that I explicitly mentioned a physical space to write the session files to, this error is no more.
4. How to fix this issue?
Create a directory named say '_session1001' and give chmod 755 so your webserver (app) can write to it.
Add this line before session_start
session_save_path("../_session1001");
Ensure you protect the directory via .htaccess file.
ie:
<?php
session_save_path("../_session1001");
session_start();
Read more here : http://php.net/session_save_path
Note:
Debian does not use the default garbage collector for sessions. Instead, it sets session.gc_probability to zero and it runs a cron job to clean up old session data in the default directory.
As a result, if your site sets a custom location with session_save_path() you also need to set a value for session.gc_probability,
e.g.:
<?php
session_save_path('/home/example.com/sessions');
ini_set('session.gc_probability', 1);
?>
Otherwise, old files in '/home/example.com/sessions' will never get removed!
Related
I have 3 environments for PHP.
Local
Staging
Live
The issue is that when I calling session in sub directory after session_start() that gives error that headers are already sent & kills existing session. And If I do not start session then it gives error for Undefined variable _SESSION.
Session is working only in ROOT directory. but not work in Subdirectory.
This only occurs on Live Environment. This same code is working on Local & Staging but not on Live.
I don't know but this may be PHP configuration issue. Please guide me.
Add session_start() at the beginning of your main page.
Please ensure that if you are including some other file, session_start() is not defined there else error will display.
The first line of php should be session_start(). If you include/add php page which contain session_start() into another page, it will show error "header already sent".
Add session_start() at the beginning of your page main page.
I recently switched over from PHP 5.3 to 5.4 and now my sessions are not saving correctly. I am getting errors saying that the location of the session folder does not exist but when I check my phpinfo(), it is the correct location. Also, I am unfortunately using godaddy for my hosting so I cannot access my php.ini file. I have stated session_start() on every page, I tried setting the save path to something else and that got rid of the errors but after that the sessions still were not saving.
Here is one of the errors.
Warning: session_start(): open(D:\Temp\php\session\sess_c6p2sphcn5m00g4ev48vfmj3h4, O_RDWR) failed: No such file or directory (2) in D:\Hosting\12059488\html\log.php on line 4
I don't have an answer for this problem yet, but here is what I have learned so far:
In Godaddy shared hosting, you do not have access to "D:\Temp\php\session", which is the default location where PHP will try to use to store its session data.
You can create a folder in root of your own directory (e.g. tmp), give write access to web server and make it unreadable from web (using File Manager), then in your PHP code before "session_start();" add something like this:
session_save_path("D:\Hosting\12059488\html\tmp");
Even this may file if you are using the new "Web Hosting" plans (in contrast to "Classic" plans) as Godaddy says these new plans do not support sessions and shared files.
I'm running a WordPress installation on XAMPP. Some files are using sessions, and I notice that any file that has session_start() will load endlessly. I always placed session_start() at the very top of the php files that are using sessions, but it still loads forever. What's up?
Does the page actually load or does it just take a long time? If it never loads, maybe check the logs for errors to write to disk. The session_start() function required apache to write a bit of data. Could it be a permissions issue?
Just search the below line in your php.ini file located at c:\xampp\php\php.ini to fix the issue. Change the value to 1 from 0.
use_only_cookies=1
Recently I moved a website to a new server. The website was working perfectly on the shared server, but I've encountered a host of permission issues and other problems since relocating to EC2. I have changed the ownership of the /var/www/html folder to apache to allow altering altering of settings on the back end of WordPress. Strangely enough, I am able to create new posts, but when I attempt to update an existing page or create a new one, I receive a blank page. [http://example.com/wp-admin/post/php] Originally I thought it was yet another permission based issue, but after researching that doesn't appear to be the case.
Steps I've taken thus far:
1) Changed ownership of the directory to apache
2) Disabled all my plugins
3) Added : php_flag output_buffering on to .htaccess (Although I wasn't sure if it mattered where in the .htaccess file I should put that command)
From the research I've done it appears that white space after the ?> could be the cause. Anyone know how I could tell which file would have this white space? Several of my files actually do not even have the PHP close tag. One additional note, my previous server was version 5.2.17 to 5.3.20. Any other ideas?
After checking the error logs I discovered that I was missing the mbstring PHP library, which has a function that was called by one of my theme files. Once added I was able to create and alter pages on the backend of WordPress without issue.
To all the folks who get this kind of error of page not displaying must check option.
turn on error reporting if you have commented the lines in your wp-config.php
#ini_set('display_errors','Off');
and than check for error.
if it has the error like this
PHP Warning: Cannot modify header information - headers already sent by (output started at /[server info]/wp-config.php:77)
than check your wp-config.php for extra space at top and bottom of the page.remove extra line spaces even. and than re-upload the wp-config.php.
Most of time this will solve your problem.
Happy Coding!!!!
I had a similar problem and by removing extra spaces before the "< ?php" fixed the issue. Although apparently it was a different theme functions file that was causing the issue. Make sure you look at the php file referenced in the php warning. In this example, it's 'wp-config', but it could be really anything.
PHP Warning: Cannot modify header information - headers already sent by (output started at /[server info]/wp-config.php:77)
Good luck!
Basically this issue happens because you have edited the file directly on cpanel editor or other simple text editor. Just create a new .php file and paste your post.php code in that file. Now save this file and replace this new one with old post.php.
I am using the Kohana 3 framework, and am using the native session driver.
For some reason, occasionally the sessions fail to write to their file.
Warning: session_start() [function.session-start]: open(/tmp/sess_*****, O_RDWR) failed: Permission denied (13) in /home/site/public_html/system/classes/kohana/session/native.php on line 27
I am pretty sure Kohana has its own in built error handler, but it is not triggered with this error (i.e. it shows up like a normal PHP error, not the Kohana error).
(source: alexanderdickson.com)
Anyone that has ever used Kohana will notice this seems to have bypassed Kohana's error handling (perhaps set with set_error_handler()).
Is there anyway to stop this error from appearing without switching from the native session (i.e. file based) driver?
Should I just give good practice the boot and prepend an # error suppressor to session_start() in the core code of Kohana? Should I relax the error_reporting()?
Thanks
You call ini_set('session.save_path', APPPATH.'sessions') (replace APPPATH.'sessions' with the directory you want) in bootstrap.php to force sessions to be written to application/sessions. This will increase the security of using native sessions and should solve your issue.
It's up to php's session.save_path directive, you can override it to some writable folder in php.ini, or you can try this in your .htaccess;
php_value session.save_path '/path/to/folder/you/can/write'
Edit: just so I don't forget, put your custom session folder level below the htdocs/public_html/whatever.
Although, all this is a little overkill since you can ask your server admin politely to check what's the problem with permissions.
This means your php interpreter has no write permissions in /tmp.
Ask your server administrator to fix that - it's unrelated to your app.
In case there are collisions with session files from different php processes (running under different users): Giving them different session temp dirs would help.
For example, you could move them away from /tmp to /path/to/homedir/phptmp and use a structure like that:
/path/to/homedir/
/path/to/homedir/htdocs
/path/to/homedir/phptmp
/path/to/homedir/logs