How do I find out which code section an error occurs in, if the site done on Joomla gives me a White Screen of Death?
I even know which module fails, and under what condition (it is a slideshow module, and it fails when one of the items to display are of video type), but I would like to check what place in the code it fails in, in the hope of perhaps correcting the problem myself (I am not the original developer, and I am not fluent in PHP yet).
You need to enable error reporting in your environment. It is disabled by default due to security concerns. I think the easiest way would be to put the following lines of code in the beginning of your joomla installation's index.php file:
ini_set('display_errors','On');
error_reporting(E_ALL);
After you are done debugging do not forget to remove or comment out those two lines.
Related
Joomla 3.x
The following code is not working
unset($doc->_styleSheets[JURI::root(true).'/media/mod_languages/css/template.css']);
thank you
The code is correct and I tested it, it's working fine.
Possibly you are running it in a plugin event after the head is rendered, or you have cached the page and the code is not really running.
In either case, try to put it at the component level, clear cache, and it should work
Update
to identify the component: turn SEF off, and look at the URL it shows as option=com_componentname;
to identify the module, simply rename the modules folder, and update the site; if it works, it's a module.
For plugins, rename the plugins/system and plugins/content first, then drill down until you spot it.
Alternatively, but much slower, you can turn modules and plugins on and off from the backend, until you find the culprit.
A variation which I've used with success in the past:
unset($doc->_styleSheets[$this->baseurl.'/media/mod_languages/css/template.css']);
Update
Here's an alternate method using a module override which should work for you.
if it doesn't already exist, create a new directory titled html in your template's folder, ie: /templates/your-template/html/
inside this, create an new mod_languages folder, ie /templates/your-template/html/mod_languages/
copy the file from joomla-site-root/modules/mod_languages/tmp/default.php to the folder above, ie /templates/your-template/html/mod_languages/default.php
open this file with a text editor and around line 12 look for the line where JHtml is loading the mod_languages CSS, and comment it out.
// JHtml::_('stylesheet', 'mod_languages/template.css', array(), true);
That's it, hopefully, this will do the trick for you.
Overriding Joomla core output using this method is safe and you won't loose your work with future Joomla updates.
More info about Joomla overrides:
https://docs.joomla.org/How_to_override_the_output_from_the_Joomla!_core
Good luck!
I'm running the current JCK as the default editor on Joomla 3.2 with PHPCode 2.5 and I have the JCK option to convert HTML entities turned off as well as the option to force simple '&' turned on.
In this configuration I can create and edit articles and custom HTML modules containing PHP just fine... the syntax highlighting, etc., all works as expected. I can switch back and forth between WYSIWYG editing mode and SOURCE editing mode and everything remains as I edited it.
However, whenever I save the article/module the '<' and '>' characters in the PHP code have all been converted to their corresponding '<' and '>' HTML entities and the PHP code won't run when loaded on the site (for the obvious reasons).
I have searched high and low and can't figure out what setting I'm missing, or what extension I need, to be able to fix this so I can execute custom PHP in my articles/modules.
I presume the same would be true of javascript since it, too, uses these symbols in the source.
Anyone?
EDIT: For the record, I was able to switch to the RokPad editor and save the PHP that way without it breaking. However, I know I should be able to do this directly inside JCK. I used to be able to do this in Joomla 1.6, I just can't seem to make it work in Joomla 3.
Try this,
Check this extension this may help or another methods you can check
How to include html or php codes into joomla article
Hope its helps..
I am new to xdebug using with magento. When I place break point at first line, it breaks at index.php and continues fine. But when I want to test the login function or menu navigation , I am placing the breaking points at "class Mage_Page_Block_Html_Topmenu extends Mage_Core_Block_Template", But it didnt stops here and continues. So exactly where I have to keep break points?? Do I need to place points in .phtml files? I am not sure where I have to place. So can anyone help me on debugging with magento.
I am sorry for this answer if you simply just want to use xdebug!
You won´t have much success with xdebug, because from my point of view its to slow to work with. I would recommend to use
Mage::log($var) or Mage::logException($var)
and just do a
tail -f on var/log/system.log or tail -f on var/log/exception.log.
On Varien_Object classes you can use something like Mage::log($product->debug()) to give reduced log output. As you might know the position in code where you want to debug this is maybe best practice.
Please make sure you have debug output enabled in Magento.
I have an ecommerce site built on OpenCart (1.5.0 i believe), which after inserting tracking code from Alexa.com and a block of code for redirecting to another site went entirely blank. Initially it worked, so I felt it was safe to save over my backups. But after refreshing the pages it was blank, and the 'view source' option in all my browsers (firefox, chrome, safari) revealed that there was no code reaching them. I then began to follow a series of debugging steps:
As my text editor was still open I undid all changes and reuploaded with no changes
I scanned the documents to be sure there were no issues in the text, with no discoveries
I ran it through W3C validation, with 2 warnings which are 1- no character encoding and 2- unable to determine parse mode.
contacted host for a server side restore though their earliest backup was a day after the problem began (it took 3 days of arguing to get them to initiate a restore)
In regards to these validation warnings, I am not sure what encoding should be used for OpenCart, ASCII or UTF-8 (which the validator resorted to) or what, in addition I am not sure if the template used with OpenCart would conflict with it if I were to declare encoding. In addition, I find it hard to believe that such a widely distributed product would have something this simple causing such a huge mistake because then all users would have this issue.
In regards to parse mode, the index page does declare parse mode (in the included header file).
In addition to all this, the validator is also claiming that it is not receiving code at all, which disables any chance of determining problems through that route.
The header and footer were both edited for these additions but are relatively long to include in this. The code used to edit were, for alexa <!-- tracking code here --> inserted into the head section of the header file, and the code for the footer was:
<span style="display:inline-block;width:160px;height:30px;text-align:center;border:#000 1px dotted;font-family:Arial,Helvetica,sans-serif;font-size:11px;background-color:#FFFFFF;"><strong style="display:block;padding:0px;margin:0px;">Reputation Management</strong>Submit Express</span>
If anymore code is needed to help then please let me know, I am not looking for someone to fix my problem but to give me relevant tips to help figure it out myself or if they do provide a fix to educate me as how they managed it so I may be able to use the same debugging method. Thanks!
EDIT: The issue, as discovered thanks to Jay, is "PHP Notice: Undefined index: HTTP_HOST in **/public_html/graphic-shack.com/index.php on line 40" and a google search has not revealed any effective results. This, to my untrained mind is jibberish, clarification would be greatly appreciated as line 40 is in fact a blank line, where as the text around it I can not post for some reason but will be viewable at http://graphic-shack.com/example.html
Open Cart uses UTF-8 throughout, so its definitely best to use that which your theme should set for the browser in the
The first thing I would ask is have you got error reporting set up (NOT OPEN CARTS ONE) that logs php errors?
If not, then you need to do something like
php_flag log_errors on
php_value error_log /path/to/custom/error.log
in your .htaccess file, so that you can log all your php errors to a file. this will need to be somewhere you can get the file, so change the path accordingly so you can view it.
Once you have that, you'll have a good base for working out the problem. I find it hard to believe that opencart has stopped because you added code. The most likely cause is a file missing, blanked or half written accidentally when saving or you've got some extra php code somewhere you shouldn't
== TEST.PHP CONTENT ==
<?php
echo '<pre>' . print_r($_SERVER, true) . '</pre>';
?>
This is a stretch but hopefully someone has an idea of what's going on here.
I was working on adding a feature to an extension (Amasty Product Grid Editor) to add the in stock status to the grid and allow in-line editing.
I ultimately got this working, but in the process something odd happened. I now have a problem with a completely unrelated extension (AheadWorks Facebook Integrator).
If the FB extension is enabled, I get almost no output in the browser on any page in the frontend or backend EXCEPT on the product grid in the admin.
On every other page it renders some of the header but bails after it tries to instantiate an instance of the FB Integrator helper class.
It throws this error:
Fatal error: Class 'AW_FBIntegrator_Helper_Data' not found in /var/www/vps_local_5/app/Mage.php on line 520
However, this file is there and all permissions are correct. The only thing I can figure is that in my failed attempts to get the feature added to the product grid I screwed up the database or something, but I have no idea what would cause it to think that a class file isn't there when it really IS.
The site works fine otherwise if I disable the FB extension. If I disable or even revert my changes to the Product Grid extension it still doesn't work, so it's not a conflict either.
I am leaning towards database only because after I got the changes to the Product Grid extension working correctly on my local dev server I copied those files to our remote dev server and it works great with no issues or conflicts with the FB extension.
So I have to believe that it was something in my iterations that broke something but I'm at a loss as to what.
Any ideas?
Try returning the compilation process (Magento Compiler) -- only if you have it currently enabled.
Magento loads from /includes/src/ instead of app/code/local or app/code/community when the compiler is enabled.