My php code is in the hostgator server and since I have to write a few scripts I don't have to install the wamp/lamp server.
I did a bit digging and found extensions namely PHP console. I added it and tested once, it showed me the line number of the errror.
But after a few hours when I tested the extension it is not working anymore for the same script and the same error.
I also tried another popular extension called Xdebug helper. But that also seems to be not working.
To test I have removed a semicolon in my working script and the link is : http://arqamahmad.com/music_app/getmusic.php
PS : I am using a shared hostgator server and I have done my research on the .htaccess and php.ini files. Nothing is helpful. The PHP console extension was the best but there seems to be some problem to that.
Answer : I had to add a php.ini file inside public_http making allowing the php debug mode on then only it the extensions work.
For Firefox, there is FirePHP (http://www.firephp.org/) in combination with Firebug. There is a similar extension for Chrome, but I haven’t tested that (https://github.com/itsgoingd/clockwork-chrome).
The general thing is that you need to somehow transfer your error messages from PHP back to the client. If you don’t want to use a browser extension for that, you can also use an approach chosen by many frameworks (e.g. Symfony): add an admin module in your page, where the error messages are displayed (you need to intercept errors on the servers for that, by registering a custom error handler).
Edit: This of course requires PHP to output error messages at all, which depends on (among others) the php.ini settings like error_reporting, which need to be set to a level that the errors you desire for reporting will trigger the error handler functions.
Concerning your remark about Xdebug: to use Xdebug helper, Xdebug (a PHP extension for debugging) needs to be available on the server, which it usually is not on production systems.
Since php is executed on the server side, no browser add-on will help you. You need to add a few lines of code to the php file to show the errors.
Here's a link for you: https://stackoverflow.com/a/21429652/6735510
Related
We are running a private MediaWiki server used at our workspace for internal documentation. We recently installed the VisualEditor extension, along with the prerequisite Parsoid (v0.8.0) service and Stunnel (as our wiki is served through HTTPS). However, we are having the issue where the "Edit" tab for the visual editor will appear when a page is loaded, then suddenly disappear after about half a second.
We double checked that the extension settings in LocalSettings.php were properly set to automatically enable the VisualEditor interface, and make it default.
We first looked at the error logs for MediaWiki, as well as Parsoid, and there is nothing out of the ordinary. We made sure that the wiki API was available, and that Parsoid could reach it, and was working. We have also looked at the debug console in the browser for error messages, which was also silent as to the nature of the issue. We have tried all of the listed troubleshooting steps on both the Parsoid and VisualEditor pages, and all of the checks point to the service running without error.
When we inspected the source for the page, we noticed that the html tag had been assigned the class type "ve-not-available", which made us think that the extension was potentially loading (at least enough to assign this class), but that something was preventing it from working properly. It's just that something has left zero footprint in any logs or files that we can find.
We would like to know where to look next to potentially help diagnose the problem.
If I recall correctly, this issue has something to do with the Visual Editor not recognizing the current skin being compatible. Are you using a custom skin?
If so, try adding the following to your LocalSettings.php;
$wgVisualEditorSupportedSkins = ['MySkin'];
I have installed a version of Cometchat Nulled on my web site. I got this messages in my chatrooms window. Besides, I don't use any CMS, my pages are HTML files.
Image:
As I indicated in the comments, your chat script is outputting a warning because:
there is a problem it wants you to know about
PHP's settings in your installation (specifically display_errors) require it to render the issue on-screen
This warning is telling you that this script is using an old database library. It is possible there is a setting to swap to a newer database library such as PDO - please do look into it. Presently you cannot use PHP7 at all because of this problem, even though your host offers it.
The solution here was to edit this configuration setting in your config.php:
define('DEV_MODE','0'); // Set to 1 only during development
I swapped the 1 to a 0 and this must have reset the display_errors setting for us within the script itself.
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 can't seem to get the Google App Engine to recognize my php.ini custom file as documented here.
I'm getting the error (within the logs of my app) where php_sapi_name() is disabled for security reasons by Google. However, it also states it can re-enabled with google_app_engine.enable_functions.
So my php.ini looks like this:
;enables function disabled by Google
google_app_engine.enable_functions = "php_sapi_name, php_uname"
Yet even after I add and upload the php.ini file, it shows the same error for newer requests. I did also browse my code through the App Engine dashboard to check to see whether the php.ini file was updated, and it was.
Any pointers would be much appreciated.
Depending on how you upload, there is a chance that this creates a new Application version for your specific app.
If it does this, you won't see the change, because the default version won't change, so you're still hitting the old version, even if the console shows you the most recent one.
Going to your console, under "Compute Engine -> App Engine -> Versions" you can see, manage, and change your default version.
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