I have just done a fresh install of the latest stable PyroCMS version on my web server. I now can hardly use the site due to PHP errors pertaining to session data. "Cannot modify header data."
Why would the CMS run without error on MAMP but not on the live server?
I had the same problem. Looks like PyroCMS is having trouble with php 5.4 which is what MAMP is using by default. Try switching your php version to 5.3.
Thread with same issue
Both the server must be having different configurations with regards to displaying of errors.
Either place error_report('E_ALL'); at the initial page (most probably index.php) or find out how you can disable displaying errors in your CMS (there must be some configurations).
Or trying putting off the display_errors directive in your php.ini file.
You should have PHP set up so that you spot errors on your local machine before they make it to production. It seems like you currently have this the wrong way around!
To fix it, your dev install of MAMP should have error_reporting set to E_ALL in php.ini and display_errors set to 'on'. Your production webserver should have display_errors set to 'off' at the very least (check that they are sent to the log files instead - you don't want to lose them) and you may also wish to reduce error_reporting to E_ERROR.
Setting it to E_ERROR will keep the logs on the production server clean so that you can spot big problems when they happen. You may especially want to do this if you are using a library or CMS that produces PHP notices or warnings, which you can't do anything about. Alternatively, you may wish to keep everything going to the logs with E_ALL and systematically sort out all the stuff that shows up, however, you will need to be using code that you can modify without making it awkward to upgrade. This can be very useful because sometimes the environment on the production server differs from your local one and things can genuinely break for reasons you don't expect.
Incidentally, the 'cannot modify header data' error suggests that this is not a stable version of PyroCMS, whatever it says on the tin!
Thanks for the help guys. I eventually found the problem which was to do with sessions. I had session.autostart=on on the live server. Turning this off fixed the problem.
Related
I am at an impasse, I am trying to turn on error reporting, which until recently was on.
This is a Development environment, completely separated from the Live Environment, The Set up is as follows.
Windows XP Home,
Apache 2.2,
MySQL 5.0 and PHP 5.2.6
It will run php no problem (Did a phpinfo to ensure that, even shows the mysql db connecting and both the local and master values for display_errors and display_startup_errors are showing as ON)
double checked the PHP.ini file and everything is on and the reporting level is set to E_ALL & E_STRICT
I even tried each of the two individually and rebooted inbetween each attempt.
I even tried setting error_reporting(-1) all to try and figure out where the php script is breaking..
I have looked at all the articles here about the display_errors either wont turn off or on and all point back at the PHP.ini file being the place to be for this. Given I have double checked the entire file for a possible reassignment of values, and there is none.
Is it possible the setting for error reporting is somewhere else as well?
This was resolved by looking beyond the usual scenarios and doing a scan of the affected drives, The Systems were firewalled and every security step was taken beforehand, Thankfully it was just the development environment and not the actual production server.
When all else seems to fail, check for viruses and malware in the end I do believe it was the babylon rootkit that was corrupting everything.
Thanks to Gordon, Lea and Sam_io for pointing out stuff that I did take but others may not think of, it was their pointing to the common causes that made me take the unusual steps of uninstalling the php and apache, neither were responsible for data in anyway so made it really easy to restore.
I actually solved this problem eventually, but it took so long that I thought I would post the question I was going to post a few hours ago so others that might happen to run into it would not find themselves in the same boat of wasting 5 hours trying to solve a simple problem.
I was trying to get a version of Zend running under an installation of lighttpd with a scaled down php and Zend core framework running through fastcgi but the problem was that any time I confronted an error, it was not reporting in the browser and was not showing up in any of the log files. (the actual platform was android which added to the confusion, but the problem turned out to be a lighttpd/zend configuration issue non-specific to the platform)
Since I wasn't sure at which layer the logging was failing, I tried everything from modifying the error/logging settings in the lighttpd.conf, fastcgi values in both the lighttpd and php configuration files and setting various logging parameters in php.ini but none of them produced any error messages in the logs even though the zend page in question was saying 'Application Error' and little else.
What I ended up discovering was that all of the examples I had run across of setting up the lighttpd.conf showed good examples on how to set up the fastcgi, how to set the server parameters, how to configure php, etc. and even how to translate typical apache .htaccess files used for Zend including rewrite rules into something similar in the lighttpd.conf
What none of them did make obvious was the setting of any required Zend environment variables.
Under a default zend site configuration such as you might find on the Zend help pages, they generally set up some kind of bootstrap.php along with a corresponding application.ini file. In the examples I saw most often and therefore the ones I followed, they included the ability to configure multiple application environments such as production, testing, development, etc. This was controlled on the server in question by setting the environment variable APPLICATION_ENV to include the environment.
In my particular set up, the 'production' environment in the example I used was the default and turned 'off' all php, exception and other error logging for the production environment to avoid users seeing ugly errors in a production setting. Since this ran after Zend started, it over-rides anything previously configured in lighttp.conf or php.ini.
Even though this has been common in most of the exmaples I've seen on configuring a zend server, none of the examples I saw for lighttpd showed setting this variable and since I was focused on the 'layers' involved, it slipped my mind.
So setting the environment in the lighttpd.conf to include development environment made my errors visible again:
setenv.add-environment("APPLICATION_ENV"=>'development')
Now I have a functional zend LAMP server implementation running on my cell phone using bitweb for android! Thanks Andi!
I'm trying to run a PHP application full of depracted ereg calls. I got the wampserver extension to switch from PHP 5.3.10 to 5.2.11, where that function is still valid, but when I try to start my services Apache won't start. I'm using Apache 2.2.11, PHP 5.2.11, and MySQL 5.5.20 on Windows 7 x64. The index.php page I'm trying to load comes up when I use PHP 5.3.10, albeit with a lot of errors about my ereg functions.
I get that I can go through all my PHP files and update the code to modern usage, but shouldn't I be able to use wampserver's PHP version extensions, since they're offered?
I've tried copying .dll's from /wamp/bin/php/php5.2.11/ directly into /wamp/bin/ but it looks like the installer for the 5.2.11 extension had taken care of that already. It also seems to have updated php.ini during install.
The Apache error log shows zero activity when I try to start wamp services. Not even notices.
I'm pretty new to Apache and PHP so I'm not sure what relevant info I could paste from php.ini or httpd.conf but if there's anything in either of those that you think would be helpful to work toward a solution, let me know and I'll paste it.
The ereg function was "depreciated" as of PHP 5.3... Depreciated does not mean it was removed, all it means is that every time it's used, a "notice" (not error) message will be logged (and in some cases displayed on screen). That is, it's still valid in PHP 5.3. And I don't believe it was removed in PHP 5.4 if memory is correct. I think it will only be removed in PHP 6.
All you have to do is configure your php.ini settings to not log or display the E_DEPRECATED notice.
Here are the php.ini lines from my WampDeveloper Pro set up, just find the same directives in WampServer and adjust...
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT
display_errors = On
The first line will use all levels, and then remove the notices, depreciated, and strict-coding levels.
That last line you might or might-not want to be On or Off depending on if this is a dev system or a production system (security reasons).
You can also just leave it all as-is, and not log repeat messages ... that way you still know what's going via the logs, but they are not filled up with the same message over and over:
ignore_repeated_errors = On
But whatever you do, don't use PHP 5.2, it's full of bugs, performance, compatibility, and security problems.
I'm in a non-ideal situation where I have to debug a website a live website running PHP5.4 on a LAMP stack.
After enabling XDebug in php.ini and setting display_errors to true, I get nicely formatter HTML output for bugs.
However, I'd like to be the only person to be able to see these bugs.
I understand there is some sort of extension for IDEs that allow you do that, but I'm a bit confused about the whole thing.
I looked into xdebug.remote_host but couldn't get it to work.
Is there a way to make errors show up only to requests coming from my IP address?
Thanks!
The main thing you want to do has nothing to with XDebug... turn display_errors off. It sounds counter-intuitive but what display_errors actually does is configure whether or not the errors should be sent to STDOUT or STDERR from PHP.
If you turn off display_errors, you can then configure PHP to log them instead. Then, just SSH into your box and tail that log file while you track down the problem.
I'm playing with a PHP weblog application using a shared hosting service, as a part of my PHP learning process. The service provider has a typical LAMP environment with remote ssh access.
Vim has been my best friend in exploring the PHP code. However, I found it sometimes hard to trace stuff in the code in case of error. For example, sometimes I visit a page and I got a blank response with no error messages whatsoever. How should I go about debugging this? Any tools that will be helpful?
My experience has been mainly in C/C++, Perl and some CGI programming. So PHP is a very refreshing experience with me :-)
In case it matters, the application I'm playing with is Lyceum, and I don't have much choice on the LAMP environment itself.
EDIT: Free software tools preferred :-)
I assume your hosting provider configured their PHP installation with display_errors turned off, which is a good thing. That's why you're seeing blank pages. So the most practical solution at the moment would be to have an .htaccess file which turns it on:
php_flag display_errors on
You'd also need error_reporting to an appropriate value:
php_flag error_reporting "E_ALL | E_STRICT"
Anyway, remember to turn this off before letting users access your web site.
For advance debugging I'd recommend Xdebug installed on the server with Eclipse PDT or NetBeans IDE with PHP support as your editor. They both are good clients for debugging, but I really doubt any provider would install Xdebug on their live servers. So you're pretty much left with logging functions if you don't have a development environment.
Getting access to your own local development environment (via XAMPP, for Example) would let you install XDebug.
PhpEd would let you debug it, but also Eclipse's PDT Environment.
Error Tracing and logging via editing php's ini config file is a good way as well, specially if you can manage it to log information. Also, consider adding trace statements and using FirePHP, for example.
Personally, I would recommend jEdit rather than vim. The SFTP plugin allows you to edit (well, load and save) the PHP documents directly on the server and the PHPParser plugin will give you some error recognition.
Also, if you get a blank page with no error messages, chances are hight that those messages are just hidden from you. Make sure that error reporting is enabled, either in your config or in your code like this:
// Report all PHP errors
error_reporting(E_ALL);
If error reporting is enabled and you still don't see any messages, either enable logging or enable output to the browser.
If you get a blank page, it's probably because of a fatal error, with display_errors turned off. By default, PHP will log errors to Apaches error-log, but you can also configure it to log errors to a separate log.
For debugging, you may also want to look into Xdebug. This extension can do a lot of things, including interactive debugging. You'll need a client to use the debugger, but there is a plugin for vim that does this.
Try NuSphere PhpED