Joomla! Discussion Forums

Overview

This thread introduces some basic tips about configuring PHP and Apache to give useful information about Joomla bugs.  Most installations of Apache and PHP will not, by default, give this information, but this can easily be changed.  Why enable reporting?  Because this information will indicate where PHP found a problem and helps us resolve the cause of the problem.

Your Current Settings

You may have error logging already.  To check using Joomla!1.5 , in the administrator application select Help -> System Info.  On the submenu, select PHP Information and search for error_log, error_reporting, and display_errors .  Both the local and global settings are show, but it is the local settings that matter when working with Joomla.  You should also note the Configuration File (php.ini) Path for future reference.

How to Change the Settings

As with anything there are many ways to enable PHP reporting of errors and warnings, and the tips below represent the way that I like to work.  Suggestions are welcomed.

Using Apache's 2.0 virtual hosting I have several sites on my local system, each with their own log files.  With these settings, all PHP errors are both displayed and logged to a file.  The php_flag and php_value directives can also be placed in an .htaccess file if the webserver permits the overriding of options.



One can also enable these settings in the php.ini file.



If you are working on your own computer ( localhost ), then changing the Apache or PHP configurations may be as simple as opening the configuration file, making the changes, saving, and restarting the webserver.  Otherwise, you may or may not be able to make these changes depending on your hosting service, and you may want to contact their support team for advice.  You may still be able to enable error reporting using an .htaccess file.

Watching the Log File

The log file can easily be watched using a utility called tail which comes natively with most *nix distributions, including Linux and Mac OS X.  Windows users will need to install this utility ( cygwin or unxutils ).  When used, the PHP log file will look something like this:



This information is incredibly useful to developers because it indicates exactly where PHP detected a problem.  Not all problems will result with additional entries in the log file ( poor code logic, JavaScript/Browser issues ), but most will.

Resources

PHP Configuration References:
http://www.php.net/manual/en/configuration.changes.php
http://www.php.net/manual/en/ini.php#ini.list
http://www.php.net/error_reporting
http://www.php.net/manual/en/ref.errorfunc.php

Apache Configuration References:
http://forum.joomla.org/index.php?topic=79277.0
http://httpd.apache.org/docs/2.0/mod/co ... owoverride

Utility References:
http://www.cygwin.com/
http://unxutils.sourceforge.net/

Final Thoughts

Again, this is merely an introduction and suggestions are welcomed.

Happy Debugging,

tcp

Note to moderators: Please feel free to edit this post with additional suggestions or links.

--edit March 28th - links to cygwin and unxutils

cygwin is your friend in case of running some windish environment to get tools like tail. AFAIR at sourceforge one can find binaries only at mingw or similar packages.

Native win32 port of "tail" and many others:
http://unxutils.sourceforge.net/

An addition to make testing more comfortable while having multiple incarnations of Joomla! running on standalone machines or same server in LAN and behind a router being capable to support services like dyndns:

Most easy way to introduce name of a server in LAN is to use a local DNS. For small LANs and standalone machines this might be to much. "hosts" file is of help very much than.

Example hosts file to make one or more virtual hosts accessable with names:


In Apache's configuration of virtual hosts:


To make it accesable via dyndns and the like add a ServerAlias for each virtual host which should be accessable via internet. At this service provider one needs an entry for each hostname which should be connectable.

hth.

Note that you can have more than one ServerAlias per virtual host.

Hi,

in order for php_value and php_flag to work as intended (VirtualHost, .htaccess) PHP must run as the server module. The CGI version, which is used by the majority of ISPs, won't notice any of this.
Editing PHP.INI is usually prohibited in a shared environment, so it's not an option for many ppl.

However, any of PHP's error_* settings can also be set at runtime via script using ini_set() -- provided this function wasn't disabled (some ISPs believe this is a dangerous function and disable it in the configuration).

- display_errors
- display_startup_errors (only works in script if used in a "prepend_script")
- error_append_string
- error_log
- error_prepend_string
- error_reporting

Any php setting declared as PHP_INI_ALL may be changed in script: Appendix G. php.ini directives, see table H.2 at the end, and runtime settings

CirTap

It would be nice to include a guide on how to report a Joomla error. I guess there must be a structured way to do so. I want to report an 1.5 bug I just ran into but can't seam to figure out how. Maybe it's already solved so is there a repository somewhere to search?

Ron

right over there: http://forum.joomla.org/index.php/board,179.0.html
there are a bunch of stickies explaining how and where.

CirTap

Hi CirTab,

You are pointing me to a subforum of 'Archived Boards - All boards closed'. Not a place where you would expect a bug report forum... Also 'Quality and Testing - Locked and Archived' sounds as if you cannot post there. A sticky note on this forum points to the Joomla! Developerforge to submit bugs but one has to be a registered developer to do so!

As a beginning Joomla-er (and as an experienced developer) I really think that bug reporting should be made much more accessible!  The 'Quality and Testing - Locked and Archived' has only around 30 subjects posted in 6 months. With so few bugreports it will take ages to reach a stable version. Maybe (hopefully) I'm overlooking something...

Ron

Hi,

when I posted the link the forums were still open
It just happend that some Working Groups were closed. Although bug reports have been posted in that forum they were usually moved to the appropriate WG forum (dev, translatiion, docs, whatever). It has been merily an entry point rather than the archive of anything that went wrong in the last two years.
don't worry, there have been more bug reports than you'd want to know about, so yes: you are overlooking something

I'm not sure if one (still) needs an account at JoomlaCode to add an item to the bug tracker -- which is the primary place to report bugs anyway http://joomlacode.org/gf/project/joomla/tracker/
You may find all the "many bugs" you were looking for, not sure though if it will "take ages" until they're fixed.

Have fun,
CirTap

Thanks Cirtap,

Yes, one has to register before submitting. Still think this is way to difficult to find for average users and most users won't take the time to register etc. I do think an easy to find simple bug reporter should be available, moderated by someone who can do the structured bug reporting in the bug tracker (and prevent the same bugs being tracked).

Ron

well, why not use this very forum then?
there's a "bug tracker template" available as a sticky. copy that text into a new post and add your findings.

CirTap

it should be emphasized in this thread that it's GOOD SECURITY PRACTICE to take steps to make your error logs non-obvious and restricted or to just cut off all error reporting except when you need it.

While there are various reasons to disable logging, security is not one of them.

Protect your logs from access by any but those that need to read them.

Check your logs daily. (You probably want to have a few automated test emailed to you, like length of log files, Geocode of the computers that have accessed your webserver, 404 errors (url and total number), 500 errors (url and total number of times.) plus anything that is relevant to your site.

Security is partially reactive, and if you don't have logs, you are reacting without information.

This is not about ACCESS logs, it is about ERROR logs, specifically PHP error logs, which are a rich source of information for crackers.

I would say the maximum preventative security measure with error logs is to shut down all error logging completely in situations where those logs are not going to be used or monitored. If you need that information, use them. If you don't need it, producing it and leaving it on the server makes it available for 1) nobody (which is pointless), or 2) someone who shouldn't see it (which is bad for you).

At a minimum, knock down the verbosity of the reporting, use unconventional folder/filenames for the logs, and lock down their permissions.

Aside from PHP error logs, Joomla and its extensions can also generate error log files. Same suggestions on those:
http://docs.joomla.org/Security_Checkli ... _and_files