I am thinking along the lines of replicating a web hosts PHP setup environment for offline local development. The idea is to parse the output of phpinfo() and write any setup values it contains into a local php.ini. I would imagine everything ism included in phpinfo and that certain things would only be specific to the environment it is running on (paths).
You will probably get more usable results from ini_get_all()
http://us.php.net/manual/en/function.ini-get-all.php
You could then traverse the associated array to reconstruct an ini file without the hassle of interpreting the output of phpinfo()
It's quite likely to just be a stock install. Even then, I'd still want to make the local development environment subtly different to the live php.ini, to ensure that it showed all errors that were being produced (as opposed to hiding, or just logging them on the live site).
Related
I have been asked to move a PHP application to another environment. I set up PHP installation, and moved 2 PHP applications and. got that working.
But one application I moved is not working... it just renders a blank screen.
When I say Localhost/ApplicationName, it lists the application folders and PHP files in it. When I click on it, the browser goes blank.
Can somebody point out a step-by step trouble shooting ways to test this?
there are a lot of ways a php file can return a blank page
first make sure the file did work on the previous environment, if it didn't then it's a different issue entirely
do the following in order of what you suspect to be most probable:
you can go into the php.ini file, and set the error variables to the development defaults, then check if it returns any usable errors
^this is what I use all the time for fatal issues, always set it back to it's original afterwards though
or check the errorlogs, as JimL suggested
if it worked on the previous env then you need to find out what the differences are between both environments.
things like, php.ini setting, IIS vs apache or whatever http server, linux vs windows
check if any of the php pages return anything at all (for example, in firefox, rightclick+inspect element, then use the network tab)
if it's a 500 error, the file probably has an error (and the server is configured to return 500 on an error)
if the file isn't too large, you can go through the file and use common programming sense to see if you can easily spot the error (stuff like links to nonexisting files, etc, shouldn't be too hard even without php experience)
when it links to files, also check if the notation is correct for the windows IIS
feel free to give more information in your OP, or in a comment, if you find out any information, and I'll do my best to help
disclaimer, I have no specific IIS knowledge, I work with apache (both windows and linux)
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'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 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.
i don't know how to say that in technical terms. and i think this is the reason to why i cant get good answer from Google.
i have xampp on my local winxp machine. i use it for developing websites locally then upload these files to my clients shared hosting accounts.
the problem that in 2 years i have always found differences between how xampp works and how the web server work.
some code work locally but dont remotely and the opposite. also flash behave differently on xampp than the remote web server.
is there is a way i can get the server configuration and use it with xampp like get the server php.ini and use it with xampp?
In fact XAMPP may behave different than your production system's web server.
This might be annoying at first, but it is definitely manageable.
Some thoughts:
Run
<?php
echo phpinfo();
?>
on both systems and check different features.
If a feature of PHP is marked as experimental, just drop it.
In case you need to deploy on different production servers, prepare a script called grabProperties.php and add code which checks essential properties you know to be in use. Output the result in some normalized way, so you may use another script to compare results and prepare a nice report.
Certain features activated in XAMPP are not enabled on most web hoster's server - e.g. Flash support. Before using these features, first ensure they are present on your production system.
You are always free to change php.ini. Thus, you may enable or disable modules in such a way, that you dev system mimics your production system's settings.
I wonder, that Flash problems relate to PHP itself. More likely, problems relate to erroneous code.
That said...
I do write PHP for quite some time. Upgraded XAMPP on dev and Apache/PHP/MySQL on production system several times. But not a single application failed to work after the upgrade.
Several times, I moved from dev Windows and production Linux to dev Mac OS X. Even there, everything worked fine immediately.
Needless to note, that not a single line of code needs to be changed between dev and prodution systems.
The essential point to to write high quality code is based on a defensive style.
Check as much input parameters of as much methods as possible (see assert()).
Log all errors to a log-file and visualize it using your admin backend (see set_error_handler()).
Use type-hints as often as possible (see type-hinting)
Set the maximum error level and code in such a way, that not a single warning appears.
Still unsatisfied?
In case you are still unsatisfied with XAMPP, prepare a virtual machine with VirtualBox, install some Linux edition and enable apache, mysql and php.
If your hoster's server is on linux - which is very likely - there should't be a big problem configuring the virtual LAMP server in a similar way.