Try this small Plugin from Viktor Vogel. This plugin gives the possibility to control the reporting per user group. Big advantage of this is, that you don't need to hack core files.
In order to fix it, open /home/mchardism/public_html/plugins/quickicon/phpversioncheck/phpversioncheck.php, find between the lines #108-132 the php version you use and change the date for eos (add few years, for example).
eos means End of Support and as @sharky said, this error occurs on a combination of outdated PHP and Joomla! versions. By changing eos ...
You'll want to create a custom PHP error handler and have that send you an email.
You can use FILE and FUNCTION and LINE constants to load where the error happened into the email that you alert yourself with.
Take a look at how to do all of that here: https://stackoverflow.com/questions/277224/how-do-i-catch-a-php-fatal-error
You could also override the default layout for system messages.
To do so, copy the following file:
You can also use Joomla's loadRenderer function in the component view.
In the view file, add the following:
$document = JFactory::...
If your original website worked fine, and your localhost copy don't work, it's probable that something went wrong in the restoration process. Either some files are missing, or the database is incorrectly restored.
Here's a couple of things you can try in order to fix your website:
If possible, download the original website again. Use Akeeba Backup to make ...
I've found out that the easiest/faster method to resolve this was to use a script reading apache's logs and send a mail every day with a summary.
FYI : Server's setup has a daily log rotation, run the script through crontab, just before rotation time.
(Plus : I'm french, so there are french words in the mail being sent).
Here's the script : (I know it ...
There is a current extension in the JED that says it allows you to output to specific levels. https://extensions.joomla.org/extensions/extension/miscellaneous/development/easy-error-reporting/
Free to download so even if you don't use it you could have a look under the covers as to how they have achieved it.
As of 3.6.3, the Joomla core templates will give you the stack trace (including any nested Exceptions of the top level object that ultimately gets caught by the error handler) when the site is in debug mode. Of course, such a feature is also dependent on the template supporting it if it has a custom error.php layout.
You can add an .htaccess file into administrator directory with:
php_flag display_errors on
php_value error_reporting <integer>
My most convenient trick I use in this case, is by creating a temporary hack on the framework.php file, inside the
The error reporting for the admin is handled in framework.php ~line 52.
// Set the error_reporting
For me this happened because I had not exported the database properly, that is there were no data just the shell of tables.
So just ensure that insert statements exist in your sql statements
and by the way.. it not good to post your passwords and usernames here
I would start by checking your template error page.
You may want to edit the page located in /templates/YOUR_TEMPLATE/error.php
This file will report all the errors and backtrace to the front end.
Try commenting out this part:
echo htmlspecialchars($this->error->getMessage(), ENT_QUOTES, 'UTF-8');
If you don't have such a file in your template, ...
To support tags in your component, you must add your content type to #__content_types table.
Documentation: Using Tags in an Extension
You have copied the row where:
`type_title` = 'Contact Category' AND `type_alias` = 'com_contact.category'
To create a new row for:
`type_title` = 'Picture Category' AND `type_alias` = 'com_picture.category'
but you ...
Setting the error reporting to the maximum level is a good idea. But if Joomla cached those errors, you need to turn on the debug mode as well. This will reveal more details about the error you encounter.
@Sharky gave a valid point that helped me solve the same problem. However, I would like to provide an alternative to help others who found it difficult to resolve this issue too. Rather than commenting out the line of code and breaking something else by accident,
if you have access to the database via whatever means, you can disable
mod_quickicon by ...
is being routed to (try it in your browser):
The laziest way to address this - is to create an empty error.php file (with no content whatsoever) and place it in your templates/yourtemplate folder (if you have an error.php file, just replace it with that empty file.
I personally think that the error.php file should provide the least amount of information possible - and there is nothing less than an ...
This is a known issue that occurs on a combination of outdated PHP and Joomla! versions. Measures have been taken to avoid this in the future and a fix will be available in 3.9.14.
It is recommended to keep PHP, Joomla!, its extensions and generally any software running on your server up-to-date. If you have no intention of doing that, your only other ...
First of all, if you are going to move the site to another one, I highly recommend you to use Akeeba Backup.
There is a free version and it would make moving your website a lot simpler, while reducing the possibilities of a number of issues/errors compared to when moving your site manually.
At the hand, open your configuration.php and check everything it's ...
Try looking at your server's PHP error log files - they should be reporting the full error message, or can be configured to do so.
In Joomla, you can get addtional info by going to system - global configuration - system and turning on Debug System (the Call Stack should then point you towards the problem module/component), and also set server - error ...
I had a very similar thing happen with a different component after upgrading the server's PHP version from 5.4 -> 5.5.
Essentially, Strict Standards warnings are not errors; they’re messages designed for developers to help troubleshoot their software and such messages don’t need to (and it’s recommended that they shouldn’t) be enabled on a production site....
Just sorted this out.
Two things happened here:
First there was a 500 error produced by Joomla, because of a MySQL query - from a module.
This website had a setting (inherited from previous development) to redirect to a custom Error article page. However this page isn't available anymore, resulting to a new 404 error, which again was trying to redirect to ...
I see two ways to do that, but you need access to server in ssh to perform (linux):
/var/log/apache2/error.log is a good start to know more about this error
usually i use and a command line tool like http://xmlsoft.org/xmllint.html
that allows you to check for mal-formed xml files in whole file structure.
This is probably not the direct clue to your ...
Inside your php.ini file, have a look for the following and make sure the values are set as follows:
Default Value: On
Default Value: E_ALL & ~E_NOTICE
Once any changes are made to the php.ini file, be sure to restart Apache.
If this doesn't work, it could possible be an issue with the XDebug extensions that ...
Based on @FFrewin answer.
You can in fact re-order the scripts how they load, however with a little code hack. An example is shown below for loading MooTools before jQuery. Same method can be applied to any script here.
Just add another if block with the script which is loading before jQuery. You can find the script name from page view source, disable ...