Fatal error : Cannot use [] for reading using smarty template - php

I am building a ticket support application, and the problem I am having since this weekend, is that when I head to the information page, I land onto the following error:
https://i.imgur.com/EzbxWe2.png
I looked this error up, and it seems to have to do with an array notation commonly seen as $arr = [$key][]
I have scanned my code at the lines of the error, and I cannot seem to trace why my page no longer shows. Underneath my Smarty template and the backend code running behind it:
Smarty Template: CallScreen.tpl
https://hastebin.com/pagubejesa.bash
CallScreen.php running on the background:
https://hastebin.com/ivezukahut.xml


RESOLVED
Error was that the local cache file was not updated, resulting in the error.

Related

Wordpress Customize not working - load-scripts.php errors

When I try to customize my Wordpress theme, I get a blank screen. I disabled plugins and the error was still there - it's the theme, I tried a different theme and the issue was gone.
I ran the JS console and got these errors, but I don't know what they mean:
load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-draggable,underscore,wp-a11y,wp-util,jquery&load[]=-ui-sortable,jquery-ui-droppable,backbone,wp-backbone,jquery-ui-tabs,shortcode,utils,media-models,moxiejs,plupload,wp-plupload&ver=4.9.8:58 Uncaught TypeError: Cannot read property 'replace' of undefined
at Function.m.template (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-draggable,underscore,wp-a11y,wp-util,jquery&load[]=-ui-sortable,jquery-ui-droppable,backbone,wp-backbone,jquery-ui-tabs,shortcode,utils,media-models,moxiejs,plupload,wp-plupload&ver=4.9.8:58)
at n.template (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-draggable,underscore,wp-a11y,wp-util,jquery&load[]=-ui-sortable,jquery-ui-droppable,backbone,wp-backbone,jquery-ui-tabs,shortcode,utils,media-models,moxiejs,plupload,wp-plupload&ver=4.9.8:61)
at n.render (load-scripts.php?c=1&load[]=jquery-ui-slider,jquery-touch-punch,iris,wp-color-picker,heartbeat,customize-base,customize-controls,customize-widgets,thickbox,&load[]=mce-view,imgareaselect,image-edit,quicktags,wplink,jquery-ui-position,jquery-ui-menu,jquery-ui-autocomplete,media-upload,accordi&load[]=on,customize-nav-menus,customize-models,customize-views,updates&ver=4.9.8:722)
at n.initialize (load-scripts.php?c=1&load[]=jquery-ui-slider,jquery-touch-punch,iris,wp-color-picker,heartbeat,customize-base,customize-controls,customize-widgets,thickbox,&load[]=mce-view,imgareaselect,image-edit,quicktags,wplink,jquery-ui-position,jquery-ui-menu,jquery-ui-autocomplete,media-upload,accordi&load[]=on,customize-nav-menus,customize-models,customize-views,updates&ver=4.9.8:718)
at n.e.View (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-draggable,underscore,wp-a11y,wp-util,jquery&load[]=-ui-sortable,jquery-ui-droppable,backbone,wp-backbone,jquery-ui-tabs,shortcode,utils,media-models,moxiejs,plupload,wp-plupload&ver=4.9.8:84)
at n.constructor (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-draggable,underscore,wp-a11y,wp-util,jquery&load[]=-ui-sortable,jquery-ui-droppable,backbone,wp-backbone,jquery-ui-tabs,shortcode,utils,media-models,moxiejs,plupload,wp-plupload&ver=4.9.8:86)
at new n (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-draggable,underscore,wp-a11y,wp-util,jquery&load[]=-ui-sortable,jquery-ui-droppable,backbone,wp-backbone,jquery-ui-tabs,shortcode,utils,media-models,moxiejs,plupload,wp-plupload&ver=4.9.8:84)
at f.ready (load-scripts.php?c=1&load[]=jquery-ui-slider,jquery-touch-punch,iris,wp-color-picker,heartbeat,customize-base,customize-controls,customize-widgets,thickbox,&load[]=mce-view,imgareaselect,image-edit,quicktags,wplink,jquery-ui-position,jquery-ui-menu,jquery-ui-autocomplete,media-upload,accordi&load[]=on,customize-nav-menus,customize-models,customize-views,updates&ver=4.9.8:31)
at Object.<anonymous> (load-scripts.php?c=1&load[]=jquery-ui-slider,jquery-touch-punch,iris,wp-color-picker,heartbeat,customize-base,customize-controls,customize-widgets,thickbox,&load[]=mce-view,imgareaselect,image-edit,quicktags,wplink,jquery-ui-position,jquery-ui-menu,jquery-ui-autocomplete,media-upload,accordi&load[]=on,customize-nav-menus,customize-models,customize-views,updates&ver=4.9.8:31)
at i (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-draggable,underscore,wp-a11y,wp-util,jquery&load[]=-ui-sortable,jquery-ui-droppable,backbone,wp-backbone,jquery-ui-tabs,shortcode,utils,media-models,moxiejs,plupload,wp-plupload&ver=4.9.8:2)

It seems like you are not the first one to have this problem. I cannot debug your problem for you (as load-scripts.php is a core file which is obvioiusly loading a lot) but MAYBE your problem is the same as described here: https://iansvoboda.com/code/dealing-load-scripts-php-console-errors-wordpress/
Ultimately the issue came down to extra white-space in the top of a functions.php include.
If your WordPress theme’s functions.php file (or any files
included/required inside of it) has extra white-space before the first
opening PHP tag, WordPress may not function correctly. The exact
issue(s) caused by the white-space vary depending on your setup and in
this case they took the form of a console error.
Therefore: Go ahead - check your theme files.

Pinpoint exact cause of PHP out of memory error ( ...it was var_dump() )

I've been getting the out of memory error occasionally for a few months now on an app that has been in continuous development & has about 20 users so far.
It didn't seem to have any negative repurcussions I could detect, but finally I have found the culprit.
I don't know how but I had a default 404 error view into which strange code had found its way, I'm not sure how I did that. This default 404 error view is called by the framework automatically if one uses findOrFail() and the db does not find a record. When a page was not available in my app (which is as it should be, as some content can be published/unpublished), this error view was triggering.
The weird code was:
<!-- <div><?php var_dump($exception); ?></div> -->
<div class="text">{{$exception->getMessage()}}</div>
Totally weird I know.
Firstly, the html comments, since it is a blade file, do not apply, so the var_dump was being called despite being 'commented out'.
So I replaced it with this:
{{ var_dump($exception) }}
and the out of memory error (and the 500 error in the browser) can be reliably reproduced.
Removing it, and the 404 view renders fine.
Replacing it with {{ dd($exception) }} works fine too - I get a render of the trace.
So, why does the var_dump line cause an out of memory error?
What should I do to investigate this further?
I'm on Laravel 5.3

This most likely happens because the content of the $exception variable is big. When you dump the variable, PHP will attempt to convert it to a string representation. This uses a lot of memory.
I don't see why you would need to output the entire exception object. You most likely just need the message (which you fetch by $exception->getMessage(). The rest is just backtrace and references to related objects and instances.

Expression engine showing garbage content while using PHP

Expressionengine is showing garbage value when I am using php for Json encode its showing this content {!-- ra:0000000019930c5000007efd6bf7e0f5 --}
here is my code :-
<?php
$entries = array();
{exp:channel:entries channel="sport" category="3536|1830|4102" site="default_site" limit="3" track_views="one" dynamic="no" status="open|featured" disable="categories|category_fields|pagination|member_data" terminate="yes"}
$entries[] = array('title' => '{title}');
{/exp:channel:entries}
header('Content-type: application/json');
echo json_encode($entries);
exit;
?>

If you see this kind of garbage value on the page that means the page has an error.
We mostly find this garbage value on PHP-enabled templates. So if we resolve the PHP errors the garbage will go.
Do not modify the ExpressionEngine core files. If you want to see the PHP errors on the page, turn on the debug mode.
If you remove the exit() function, you will get the output as you want.
The exit() function also exits the execution of ExpressionEngine code that's why you are getting the garbage value.

Even simpler - remove the exit().
As this answer explains, these are annotation tags used for debugging (so you can get a stack trace for nested templates I suppose) and they are parsed out late in the process. So if you exit() it doesn't work. Just make sure that the script ends with no unwanted output and you should be good. I had this problem (in EEv5) and this was the fix.

I've just had the same style of error codes appear, when moving an old EE 2.9.3 site to a Dev server and applying a test domain name.
There were some PHP Includes in the templates, which referenced the live site's server path. When I changed these... all fixed.
For example:
include("/home/sites/domainname.co.uk/public_html/swift/swift_required.php");
...changed to...
include("/home/domain/public_html/swift/swift_required.php");

Yeah ! finally I got the answer its so simple here is the solution :-
go to ExpressionEngine\system\EllisLab\ExpressionEngine\Library\Template\Annotation\Runtime.php
on line no. 65 comment the code return '{!-- ra:'.$key.' --}';

PHP Loading Blank Page

I recently moved my website from one server to another. My index.php file uses the smarty template system to load multiple pages based on the URL. However, one specific page is loading blank now.
I don't necessarily need help fixing any coding issue, I need help finding the error.
There's no PHP error that displays and the server doesn't give a 403, 404, 500, or any other error response that I can see. Can anyone offer suggestions on how to find what's causing the error?
Perhaps adding something to the PHP file to display every error or searching the server logs to see what's causing the error to occur. As of right now, I can't necessarily narrow it down to a specific file, much less a specific line. Any suggestions on what I should add or where I should look?
I'm open to adding whatever to the PHP file to trace the error, using command-line/shell to locate log files, using Perl to track down the error, and so on. Anything will be greatly appreciated!
EDIT 1: This is on a Linux/CentOS servers that's running cPanel/WHM.
EDIT 2: After following Tim's advice below, it appears that the error is coming from this line:
$app->map('/panel/ajax', $auth('member'), function () use ($app) {
Here's the line in a bit more context:
$app->flash('restore_panel_filters', '1');
$app->redirect($redirect);
})->via('GET','POST');
$app->map('/panel/ajax', $auth('member'), function () use ($app) {
$req = $app->request();
$user_id = $app->view()->getData('user_id');
Any idea what would be causing this to happen?

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