Mediawiki custom tag Stops page parsing - php

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!

Related

php exit(); function warning in codacy

while using Codacy to analyze my PHP code I found a number of errors caused by the exit(); function. here's one function,
public function saveCssForm(){
$data = $_POST;
if(!$data){
// is a direct acess
$this->index();exit();
}
// update the data
$this->csssettingmodel->updateCSS($data);
// save the notifications
$this->notify_update($data['site_id'],$data['lang_key']);
// set the success message
$this->session->set_flashdata('edit_item', 'edited');
// redirect to the view page
$baseUrl = $this->config->item('base_url');
redirect($baseUrl.'index.php/cssSettings/view/'.$this->session->userdata("languageabbr"));
}
public function index()
{
// Denay Direct Access
echo "<hr><h1><center>NO DIRECT ACCESS</h1> </center>";
echo "<center>You are not permitted to access this page </center>";
}
and the codacy result shows this...
any alternatives or suggestions to avoid this would be helpful.
Codacy is not displaying errors, in the sense of problems you need to fix; it is analysing the quality of your code, and suggesting that the exit appearing in this position is not a good practice, so you might want to fix it.
Firstly, application frameworks are often designed to have a single point of entry, process some logic, and then return a result to the entry point which will output and clean up. Exiting from different points in the code makes it harder to predict the flow, because whole sections of the code may look reachable but actually come after the program has exited.
Secondly, such code might be used for debugging, to interrupt the flow of execution at a particular point to display some intermediate data or simulate a particular failure. In this case, it appearing in the analysed code would suggest that you had left the debugging code in accidentally.

$_POST method and isset method and !empty method not working

Before anyone tells me to look at other similar posts, I already have and I cannot find any solution to my problem.
I am building a questionnaire for a project, and I am using php 5.6, xampp, phpmyadmin, Phpstorm 2017.1.2 and of course the usual languages html css javacript.
In order to write less code, I used the masterpage method to build my website for the questionnaire.
I therefore have a do-test.php where I put my questionnaire alone and an index.php where I have the main skeleton of the page.
I have my questionnaire form with various fieldsets and their inputs. Lastly I have a input type=submit button that I click and the form is supposed to be submitted. However my $_POST method is not working at all.
The following code does all the work. Unfortunately for reasons yet unknown to me, when the if statement runs, it doesn't even look at the isset or !empty method.
Using an IDE debugger
Debugging the do-test.php without the master-page.: My xdebug (installed in phpstorm), jumps directly from the breakpoint in if statement to the bottom of the page. I tried using an else with a message that "submit is not set" and it shows it before and after submitting the form.
if(isset($_POST['Submit']) && !empty($_POST['Submit'])) {
$results = new Results();
$results->ProcessRequest();
if ($results->isSuccessful()) {
echo "<script type='text/javascript'>
alert('Your data is sent to the server');
</script>";
} else {
echo "<script type='text/javascript'>
alert('Something went wrong.');
</script>";
}
}
My http raw post data is visible but the post array is empty.
Debuggin the do-test.php with the master-page: Gets me 502 bad gateway error
Debug using localhost
Using this code snippet here I tried to see what is going on.
Submitting the form from the master-page or the simple do-test page, gives me the following result:
which means that my post array has all the right variables. All that remains is for the method to be executed and for the data to pass into the db.
My post_max_size and variables_order (advise taken from here) are correct.
magic_quotes_gpc (from this post) are off in php.ini.
Could it be the http modules that interfere with POST as told by GeorgeMillo
here??? If so how do I tamper with those?
Could there be something wrong with my version of phpstorm or the php version?
Any suggestion is welcome. Thank you in advance.
I may have written one thing wrong so I gave the wrong impression. I wrote "when the if statement runs", when in fact, the debugger runs and tries to execute the if statement but it doesnt. Sorry for my bad explanation.
The member "Alive or Die" gave me the simple solution of using
if(count($_POST)>0)
and it works!! So I will stick with that.
Thanks to everyone for your fast comments and for pointing out the obvious when one cannot see it!!

PHP Error handler triggers when using die in outputbuffer context

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).

Need for exit in the controller function in magento

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.

Magento's Mage::log() causes white screen

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');

Categories