I am reading the No frills magento layout book written by Alan Storm. I have come across the following code:
public function handleAction()
{
$this ->loadLayout();
$handles = Mage::getSingleton('core/layout')->getUpdate()->getHandles();
var_dump($handles);
exit;
}
What is the need of that exit in this code ? That code works perfectly without that exit.
It stops the rest of the code from executing, looking at that script it seems like the purpose of it is to debug something. Having the rest of your page render won't make that debugging any easier since CSS styles will be applied that could make the var_dump() less readable.
Also there could be a redirect involved or such which could cause your var_dump() to disappear immediately, using exit you prevent the redirect from happening.
Bottom line, it's just not needed to have the rest of the code render.
Related
It's specifically i'm developing a plugin but stuck to edit the front end html. Is there any filter or function of wordpress to edit the html of a page?
Basically, WordPress is not built in a way to allow you that. It just goes on pushing its output whenever it wants, and when any of your filters is executed it is either before any output happened (so you have nothing to modify) or after (so it is already gone away to the browser).
There is an option which you could try: using output buffering. You can start your own output buffer on init, catch it on shutdown, and use this last opportunity to modify the output.
The general outline is as follows:
add_action('init', 'ob_start');
add_action('shutdown', function () {
$html = ob_get_clean();
$hmtl = morbvel_modify_html($html);
echo $html;
});
AFAIR, WordPress already has an action on shutdown which cleans all output buffers. It is up to you to check its source code to see what priority to assign to your shutdown hook to make it work.
PS. As a WordPress user myself I wouldn't like a plugin to do something like this - I'll be afraid that your code spoils something in my awesome html output I have carefully crafted. But you may turn out as lucky as to find your faithful customers.
im developing my PHP framework and at the moment im stuck with a strange behaviour in my error-dispatching page.
The page itself is beautiful, it catches and lists all error using a custom error-handler registered with "set_error_handler()" and can print the line, file, invoked variables and such. It even triggers multiple errors perfectly (except for fatal or syntax-errors which causes the script to hold) but still the dispatches the fatal or even syntax error in this case and even shows me, even when its a null-pointer in a template where the error is located which is beautiful and works awesome.
This system works "using set_error_handler"! The entire output (rendering html /php templates) is realised using "ob_start" and "ob_get_clean" - outputbuffer context.
Next I check if the error-handler catched any errors (will be written in an array in the error-handler's class) and if there are errors and error-display is enabled (developer mode = on) the error-dispatcher page will be displayed instead of the page's content.
However since I implemented that I have one strange behaviour which I do not want:
Whenever I use die() inside of outputbuffer context ((ob_start() ... ob_get_clean()) ) The registered error-handler method is called with an empty error-list displayed and even error_get_last() is empty, but still he triggers that damn function.
This is very disturbing as you cant use die to hold the script to test the output of certain variables which is disturbing in development and seems to be an unusual behaviour to me.
I think posting my entire code is making the thing a little bit too complicated for you to understand thatswhy I leave a little draft explaining the situation, its basically same as it looks in my classes:
//index.php
$errorList = array();
function myErrorHandler($errorType, $errorString, $errorFile, $errorLine, array $errorContext) {
global $errorList;
$errorList[] = $errorString;
}
set_error_handler("myErrorHandler");
//Here my classses and entire rest of framework is loaded...()
//Initialise output
$output = "";
//This method parses templates, it remotely close works like that...
function includeTemplate($templatePath) {
global $output;
ob_start("myErrorHandler");
include($templatePath);
$output .= ob_get_clean(); //Attach to output
}
//This method is called at the very end, it flushes the output, wether by displaying error-dispatcher or page content to be shown.
function flush() {
global $output;
if(count($errorList) > 0) {
echo implode("<br />", $errorList);
} else {
echo $output;
}
}
//Template file: registerTemplate.php
<div class="container">
<Some template output here, doesnt matter if an error occured...>
<?php die($var); ?> //<- Error rised -> Entering "myErrorHandler()" -> but why????
</div>
-> This die() above would rise an error because registerTemplate.php was somewhen parsed using includeTemplate("reigsterTemplate"); which is as located within an ob_start() context. It does not matter if an error occured before or not or even if I just place die("!"); without any invoked variable, it will riase an error.
If I put the die() before or after the include_template context, in upper scope it works as usual and the error_handler does not trigger, as it should work.
Can anyone tell me why this is happening? Thanks alot!
(Important: again this code is not realistic I know its just a draft from how the things look like very barely, dont bother with that giving me hints that this is a bad way to do things. The entire thing is perfectly object oriented and very well structured. I just made this little draft to make you guys understand in what order the methods are called and how my problem comes up because posting my code would waste me and you alot of time as it would be too huge and complex here).
To put my question into context, I'm working on an entirely static website where 'post' pages are created by myself manually - there's no CMS behind it. Each page will require a <pre> <code> block to display code as text in a styled block. This could be very few - several which is why I'm trying to do this for ease.
Here's what I've done -
function outputCode($code) {
return "<pre class='preBlock'><code class='codeBlock'>".htmlentities($code)."</code></pre>";
}
The code works as expected and produces an expected outcome when it's able to grab code. My idea is to somehow wrap the code for the code block with this function and echo it out for the effect, fewer lines and better readability.
As I'm literally just creating pages as they're needed, is there even a way to create the needed code blocks with such function to avoid having to manually repeat all the code for each code block? Cheers!
EDIT:
I was previously using this function and it was working great as I was pulling code from .txt documents in a directory and storing the code for code blocks in a variable with file_get_contents(). However, now, I'm trying to get the function to work by manually inputting the code into the function.
Well. Wrapping the function input in ' ' completely slipped my mind! It works just fine now!
If I understand correctly, you want to re-use your outputCode function in several different PHP files, corresponding to posts. If yes, you could put this 1 function in its own file, called outputcode.php for example, and then do
include "outputcode.php";
in every post/PHP file that needs to re-use this function. This will pull in the code, from the one common/shared file, for use in each post/PHP file that needs it. Or maybe I'm misreading your last paragraph :(
When using Magentos log facility Mage::log() it sometimes causes a white screen. No error messages are outputted either to the screen or any of the log files (var/log/system.log, var/log/exception.log )
This seems to happen only when I'm trying to log a very large object. for example when I'm trying this
Mage::log(Mage::helper('catalog/category')->getStoreCategories());
inside a block controller it causes a white screen.
the same happens when I'm trying to log the current product in app/design/frontend/enterprise/default/template/catalog/product/view/media.phtml
using
Mage::log($_product);
Usually Mage::log() works fine and writes everything to the system.log file.
I was wondering if this has happened to anybody else or if anybody has an idea about why this is happening?
Mage::log works a lot like print_r, private and protected values are printed too which includes extensive resource details. You can avoid these by using the purpose made Varien_Object::debug method.
Mage::log($_product->debug());
debug is also preferred because it detects recursion which not all versions of PHP do.
I guess it happens to everyone.
Try not to log large objects.
In case you need I would advice you to use die.
for example like this
$object = ...;
die($object);
or
die('pre html tag'.print_r($object,true).'pre html tag');
I created a few mediawiki custom tags, using the guide found here
http://www.mediawiki.org/wiki/Manual:Tag_extensions
I will post my code below, but the problem is after it hits the first custom tag in the page, it calls it, and prints the response, but does not get anything that comes after it in the wikitext. It seems it just stops parsing the page.
Any Ideas?
if ( defined( 'MW_SUPPORTS_PARSERFIRSTCALLINIT' ) ) {
$wgHooks['ParserFirstCallInit'][] = 'tagregister';
} else { // Otherwise do things the old fashioned way
$wgExtensionFunctions[] = 'tagregister';
}
function tagregister(){
global $wgParser;
$wgParser->setHook('tag1','tag1func');
$wgParser->setHook('tag2','tag2func');
return true;
}
function tag1func($input,$params)
{
return "It called me";
}
function tag2func($input,$params)
{
return "It called me -- 2";
}
Update: #George Mauer -- I have seen that as well, but this does not stop the page from rendering, just the Mediawiki engine from parsing the rest of the wikitext. Its as if hitting the custom function is signaling mediawiki that processing is done. I am in the process of diving into the rabbit hole but was hoping someone else has seen this behavior.
Never used Mediawiki but that sort of problem in my experience is indicative of a PHP error that occurred but was suppressed either with the # operator or because PHP error output to screen is turned off.
I hate to resort to this debugging method but when absolutely and utterly frustrated in PHP I will just start putting echo statements every few lines (always with a marker so I remember to remove them later), to figure out exactly where the error is coming from. Eventually, you'll get to the bottom of the rabbit hole and figure out exactly what the problematic line of code is.
Silly me.
Had to close the tags.
Instead of<tag1> I had to change it to <tag1 /> or <tag1></tag1>
Now all works!