I keep getting either 500 internal server error or blank page when trying to access a php file in localhost, depending on the file.
I know this might be a recurrent problem but I can't find the solution.
I reinstalled a local website that basically access a mysql database. It worked in this computer before, so I assume the code is OK. I already reinstalled the database also.
Phpinfo.php is working.
I've seen that usually is a permission problem, I already set everything to 755 and the owner of the files is "root".
I don't use a .htaccess file and I've enabled the mod_rewrite which I've seen also can cause this problem.
Any hints?
session_is_registered() was deprecated in php 5.3, and removed in php 5.4. Using session_register(), session_unregister() and session_is_registered() was discouraged for a long time.
Your code should simply use the $_SESSION superglobal, it is persisted between requests and available in scripts after calling session_start().
If you want to know if you session has a given variable, simply do an isset for the array key:
isset($_SESSION["key"])
Related
I was having problems with my PHP website (SuiteCRM) not being able to log users in and I found it was due to not being able to write on the sessions directory.
I am able to fix it by creating the directory /tmp/php_sessions and giving it write permissions for the Apache user www-data. I see the directory get populated with files as users log in.
However, Ubuntu Xenial is deleting my entire tmp directory on reboots, so I have to redo this all over again every time. I decided to move my save_path elsewhere.
After changing things in my php.ini file, and restarting Apache, I can check that they are effective by running this simple script:
<?php
echo ini_get("session.save_path");
phpinfo();
?>
This shows me a double confirmation of the new path, first echoing /var/tmp/php_sessions and then, in the middle of all the phpinfo information, showing the same value as both Local Value and Master value for directive session.save_path.
BUT the directory that php is using is still the first one, /tmp/php_sessions! It seems that my setting is being ignored.
Am I overlooking something? Where could that old setting be buried? Or how can I make the new one effective?
(P.S. - I am not using a redis handler as in another similar SO question)
Ok, I solved my own problem and the general answer is as follows:
There are two more things that can be changing the path and need to be checked,
the PHP code of the application might be changing the ini directive, search the code for ini_set(session.save_path
the PHP code might be using the session_save_path PHP command to override the ini. Search the code for that also (and notice the two underscores _!)
And the specific answer for my case was that SuiteCRM uses session_save_path command to set its path with a value coming from the file config.php found at the web root. That's where I found the old setting, and changing it solved my problem (for good, I hope).
I'm trying to get a file's content into a variable but I don't get anything when I read the file. I used both methods JFile::read() and file_get_contents() but both return the same thing: a blank string, not an error , not any boolean values or anything.
I want to mention that I'm working on a Linux machine (just for 2 days) and recently I changed the permissions for the entire machine to 777 ( I don't know if this affects something or not).
Is the a connection between my OS, permissions and the php's file_get_contents()? or Joomla restricts file reading?
Also I want to mention that my file_get_contents() function was added manually by me in the index.php file , also the file I want to read was manually added in the same folder with index.php.
We had the same problem with one of our clients, it turned out it was a firewall issue. It was very hard to debug this issue. I suggest you check with your networking team.
I am assuming, of course, that you have set the PHP error reporting level to the maximum and that you have checked the error logs.
It seemed the problem was from my system . I messed it up when I changed the permissions so I have to re-install it.
Never change the permissions on a Linux for the entire file system.
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 am having a problem with the session with the web development framework Kohana 3.2 that apparently is a bug that, at most, can be workarounded. It reports SESSION_EXCEPTION [ 1 ]: ERROR READING SESSION DATA.
My Kohana application isn't in the root folder and I wonder if that has something to do with it.
I have tryed several possible solutions but none of them have worked. Here are some of them:
1) using one library (Facebook SDK), session was initialized on it's own, and session handling was done using the $_SESSION variable. So there were two cookies - session (Kohanas session id) and PHPSESSID. *=> There is only one "session" and "PHPSESSID" variables in $_COOKIE*
2) Workaround or solution was setting in php.ini session.auto_start = 0. => I am working in a shared server (iPage) and I am pretty sure I can't edit the php.ini file.
3) some user's session files were trying to get saved to a directory that didn't exist. So he changed the session.save_path to a valid path and that fixed it. => If he was talking about this php native function , I've created a directory and set it calling this function as the session folder. It didn't work as well. However, I got unsure if I did it correctly (the path "/" would be the root, and not where kohana is in, right?)
4) Apparently this bug is reported to kohana here but I wasn't able to act from reading it.
Is somebody out there able to help me? Thanks in advance.
After researching very much about it and upgradion to KOHANA 3.3, I came to the conclusion that this error was caused when the native function session_start() was called in the Kohana_Session_Native class. It was caused because PHP was trying to save the session in an unavaiable directory. Thus, i just changed this path in php.ini and everything was solved. You may also just call the function session_save_path('YOUR_PATH') in the application/bootstrap.php.
in my case, i run "chmod 777 -R /path/to/session" command and the error has disappeared.
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.