I came across a fat-free framework where indexes are accessed without checking if there's data present or not.
few e.g.
e.g.1
$sObj = new Site($db); // this returns null?
$site = $sObj->getById($sessionSiteId)[0];
e.g.2
$ppObject = new Page($db);
$pheader = $ppObject->getByCodeandsiteid($siteid,'Header');
F3::set('headercode',$pheader[0]['description']);
so these are just few cases. Most of the practice done is to just access the index.
This throws error in my env. php 8.1 and fat-free 3.8.1.
But running this same code on my colleague's env. : php 5.6.40 and fat-free 3.5.1` this doesn't throw error but simply gives null value.
I also checked with some random unassigned variable on his env. and to my surprise, this also seem to simply give null instead of error.
Is this expected behavior on previous versions?
Also checked in phpinfo() that error_reporting value for both is 22527.
Related
this is how it displays the error
I tried changing the PHP version to 7.3 still not working
This the line of code that's giving that error
As the error is saying the problem comes from the fact that you try to use a null value as an array, from what I see this code is problematic:
$appitem->stage->sresource['stage_id']
Could be a typo maybe that you have sresource instead of resource and that is the reason why $appitem->stage->sresource is null?
Today I am faced with a bizarre situation. I have been searching for a definition but unfortunately, I couldn't find any.
In my PHP code, I am inserting a row into a database table. When I try to insert a duplicate primary key as part of debugging a recent issue, I can see the duplicate primary key exception in the mysqli object as expected.
However, mysqli->$errno, mysqli->$error, mysqli->error_list are immediately being reset to empty which I cannot comprehend why.
This is part of the code that I am experiencing the issue with.
$retry = 5;
do {
$mysqli_result = mysqli_query($conn, $sql);
if (mysqli_errno($conn) == 1213) { /** Here I can observe the expected errno, error, error_list **/
sleep(1); $retry--;
} else
$retry = 0;
} while ($retry);
/** Here - errno, error, error_list are reset to empty */
Update
I have also noticed that along with the change that I mentioned the mysqli->$stat is also changing. Or is it like when the stat is queried everything else is reset?
Some additional info
This is an old project made using PHP 5.6 [95% compatible with up to PHP 7.2]. So I am using 7.2 in my local environment. Don't advise me to upgrade the whole project please, I know its already dead. I am just maintaining the project
The variable $conn is global
I am using vscode and compatible Xdebug extension for watching the variables
I am observing this behaviour when there is a slight delay in stepping over the current statement.
I'm sorry to say this but it looks like the problem is that you are using an unsupported PHP version. The broken mysqli::$stat property was removed in PHP 7.4. The solution is to upgrade your PHP version.
When triggering any MySQLi function the error and error properties are reset. You have to check it immediately after calling each function.
For example:
$mysqli->stat();
if($mysqli->error) {
// ...
However, I would strongly recommend to forget about ever using error and errno properties. Just enable automatic MySQLi error reporting and stop checking for errors manually.
When using xDebug the properties will never be shown to you correctly due to this MySQLi bug.
I know you can't afford it now, but please always consider using PDO rather than MySQLi. PDO is much better and easier.
I am trying to understand if it's correct for PHP to throw an undefined offset error when using isset() function.
The data comes from an eloquent collection.
$interest->vehicles
The problem happens when the collection is empty.
Below code tested on 3 different setups (Mac+Mamp PRO, Windows+Xampp, Mac+Mamp), throws an undefined offset in first two setups but not in mine which is the third one (Mac+Mamp)
All tested scenarios are done with PHP 7 and display errors On.
isset($interest->vehicles[0]['make'])
I understand why the error may be happening to the other setups as the offset i try to isset doesn't exist, but the thing i don't understand is why i don't see the error on my setup when using isset.
I also tried to reinstall Mamp on my maching, upgraded to Sierra OS, restarted my laptop, changed php.ini settings to always display all errors .
ErrorException in Collection.php line 1043:
Undefined offset: 0 (View: /Users/efood-leo/Sites/cardealer/resources/views/panel/interest/form.blade.php) (View: /Users/efood-leo/Sites/cardealer/resources/views/panel/interest/form.blade.php)
This is the error i am talking about, and happens only if i try to retrieve
$interest->vehicles[0]['make']
When the vehicles[0] does not exist.
if i do :
isset($interest->vehicles[0]['make'])
Then there is no error in my setup, and 2 other devs report the error still happens with isset.
Try this code.
Isset() function is returning true somehow so without isset it works
$interest = (object)['vehicles' => []];
echo $interest->vehicles[0]['make'];
Read more on isset():
http://php.net/manual/en/function.isset.php
I am getting a warning after PHP update
Warning: Creating default object from empty value in /modules/mod_feed/helper.php on line 42
I had faced this issue before and at that time I have used $v=new stdclass();. But the issue was not in a Joomla site. Now the same issue with a joomla site. My code link is here
What I should change in this file? Any thoughts?
You also need
$feed->image = new stdclass;
before line 42. This is an E_STRICT level warning. These are designed to alert you to code smells (like auto-creating arrays / objects).
I'm new to PHP so I apologize if this is a simple problem...
I am moving a PHP site from one server to another. The new server is IIS 7.0, PHP 5.2.1, with short open tag turned "On", and I don't know how the original server was set-up (I was just given the code).
The following is the very first section of code on one of the pages:
<?
ob_start();
session_start();
if($_GET['confirm'] == 13 || $_GET['confirm'] == 14 || $_GET['confirm'] == 15 || $_GET['confirm'] == 16)
{
include("test/query/test_query.php");
}
?>
When this page executes, the following error is always shown:
PHP Notice: Undefined index: confirm in [file location].php on line 6
Also, users access this page by being redirected from the home page (which is a standard HTML page). The full URL when properly navigated to is the following:
http://www.[site].com/test.php#login
... I understand why the error is thrown. What I don't understand is how this code could ever work as it does on the original server. Could I be missing a configuration setting?
*This same issue happens in dozens of locations all over the site. This is just one specific occurrence of the issue.
The new server has error_reporting set to E_ALL. What you're seeing is a notice, not an error. Try:
error_reporting(E_ALL ^ E_NOTICE)
With error reporting set to E_ALL, accessing a member of an array which is not set generates an error. If you don't wish to lower your error reporting level, before checking $_GET['var'], change your code to:
if(isset($_GET['confirm']) && ($_GET['confirm'] == 13 || $_GET['confirm'] == 14 || $_GET['confirm'] == 15 || $_GET['confirm'] == 16)) {
by adding the call to isset() before you actually access $_GET['confirm'], you will verify that you're not accessing an array member which is not set. ($_GET['confirm'] will only be set if the URL ends in ?confirm=... or ?something...&confirm=...)
I suggest to optimize the code for reading:
if (isset($_GET['confirm']) && ($_GET['confirm'] >= 13 && $_GET['confirm'] <= 16))
And I totally agree with Josh's proposal.
Since there is no index $_GET['confirm'], PHP throws a notice that you are looking at an undefined index. The notice is being displayed because the new server has the E_NOTICE flag set in error_reporting somewhere, either in php.ini or in some config file or bootstrap that is run on pageloads.
From the php manual, E_NOTICE: "Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script."
You can either try turning off the notices if you aren't worried about them, or use them to track down places where there may be problems.
For the code you posted, an easy fix would be to change the conditional to
if(isset($_GET['confirm']) && <list of OR conditions>)
That way PHP bails out of evaluating the conditional if there is no 'confirm' index.
isset() is a useful function. It returns "true" if the variable exists and "false" if not. Usually, people use it in conjunction with a superglobal like $_GET or $_POST to determine whether you're being sent from another page on the site - this allows you to create different actions based on where your user is coming from and what data is tagging along. It also prevents errors in trying to use variables you haven't yet defined, like the OP is getting. So instead of needing to write two different .php files and worrying about sending your user to the wrong one, you can do it all in one page.
Jay,
I'd be careful about your usage of some of these calls. <?php is more likely to work than <? . I've heard session_start() should be the very first thing set to the browser or it can cause header issues. And yes, you need to have a variable declared before you use it - if you're not typing in [file].php?confirm=[some number] as your URL, your page will break unless you amend it to allow for breaks.
That's because confirm query string variable does not seem to be set, you can check it like:
ini_set('display_errors', true);
error_reporting(E_ALL);
var_dump($_GET['confirm']);