PHP 8.1.1 deprecations - Take 5
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
#2960 PHP 8.1.1 deprecations - Take 5
Sorry, I was a bit late replying to 8.1.1V4 - I was still away.
Now I'm home, I've tried to recreate the corrections on my home machine server, as I don't want to do a clean SVN, as I have some edits from my map modifications. Hopefully that doesn't complicate things.
Parse error: syntax error, unexpected token "!=" in \includes\classes\class_reportbase.php(2865) : eval()'d code on line 1
This line looks like it is actually eval'ing a numeric expression, so on line 2860 I modified your edit, and changed $value = '' to $value = 0
Then I got:
Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in \includes\classes\class_reportbase.php on line 495
and another few:
Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in \includes\classes\class_gedcomrecord.php on line 157
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in \includes\functions\functions_export.php on line 235
Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in \includes\functions\functions_print.php on line 1658
Deprecated: htmlentities(): Passing null to parameter #1 ($string) of type string is deprecated in \login.php on line 208
Try the attached.
I'm not so sure about your (or my) fix to class_reportbase.php, at line 2860. The code isn't actually trying to evaluate a numeric expression here. I think it's more correct to check for NULL and replace the questionable string with one that will evaluate to empty.
We'll see.
To properly track down this error, it would be helpful to know which report is causing the error, and where in the report the error is actually occurring.
Last edit: Gerry Kroll 2022-01-14
Gary, Gerry,
the message suggests that the $condition contains '!=' with nothing left or right to it. It would be interesting what was in the $attrs["condition"]; array just before the error has been triggered.
please also attach the following patch with
- some typos corrected,
- added some missing global definition
- escaped XML special characters in documenting comments (only in class_reportbase.php)
@Tomasz - you're right about 'nothing'. I had assumed that it was comparing two values, and previously it was doing something like eval($foo != null) and changing null to '' made it eval($foo != ), which is why I changed it to 0 instead. I'm certainly not an experienced php programmer, but at least the errors went away, and it went on to generate what looked like a correct report.
I'll try to do some debugging and get some details
Last edit: GaryT 2022-01-14
Gary:
Yes, I figured the problem with class_reportbase.php was an empty condition to the right of the "!=". That's why the check for NULL was changed to replace that NULL value with a pair of apostrophes inside a pair of quotes, which essentially changed the NULL to an empty string so we end up with
eval($foo!='')Tomasz:
Thank you. I will incorporate your updates into the next version of FixPGV5.zip .
Gerry: sorry, yes. That's exactly what I just worked out just now too. Thanks.
FWIW that code seems to be used in many reports - the first 3 I tried at least.
I should have recorded my test conditions! But most of those seem to have worked, thanks.
Address labels seem to be fixed.
Close relatives report - pdf:
ERROR 2: Undefined array key "showSourcesPresent"
0 Error occurred on line 1 of file class_reportbase.php(2865) : eval()'d code in function eval
1 called from line 2865 of file class_reportbase.php in function PGVRifSHandler
2 called from line 1476 of file class_reportbase.php in function startElement
3 called from in function xml_parse
4 called from line 411 of file reportengine.php
Changes report, pdf:
Fatal error: Uncaught PDOException: SQLSTATE[42P10]: Invalid column reference: 7 ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list LINE 1: ...'CHAN' AND filter2.d_julianday1>=2459564 ORDER BY filter1.d_... ^ in \includes\classes\class_pgv_db.php:852 Stack trace: #0 \includes\classes\class_pgv_db.php(852): PDOStatement->execute() #1 \includes\classes\class_pgv_db.php(867): PGV_DBStatement->__call('execute', Array) #2 \includes\functions\functions_db.php(1106): PGV_DBStatement->__call('fetchAll', Array) #3 \includes\classes\class_reportbase.php(3361): search_indis_custom(Array, Array, Array) #4 \includes\classes\class_reportbase.php(1476): PGVRListSHandler(Array) #5 [internal function]: startElement(Object(XMLParser), 'PGVRList', Array) #6 \reportengine.php(411): xml_parse(Object(XMLParser), 'th">\n\t\t\t\t\t\t<PGV...', true) #7 {main} thrown in \includes\classes\class_pgv_db.php on line 852
Those two seem to be the same with either php 8.0 and 8.1. They are running on my home machine. I'm also running postgres, if that's relevant in the second case.
Last edit: GaryT 2022-01-14
Try the attached. This ZIP file includes Tomasz' patches.
The update to the GoogleMaps default configuration is inconsequential -- it's just a typo correction. This one can be ignored.
Tomasz' changes to class_reportbase.php MAY have cured the SQL error. (No guarantees!)
PHP is strange now. It seems that missed global declaration is not actually an error. The interpreter finds correctly the proper variable. But php goes to become stricter more and more, so I'm afraid that in the near future this error will be the real error.
I tried to hunt such errors in the whole project but after run the inspection in PhpStorm (enabling only this one error) I gave up. 1571 errors and 1411 warnings (var declared but e.g. in conditional expression).
I will return to the subject but not all at once.
Parse error: syntax error, unexpected variable "$ascii_langs", expecting "," or ";" in V:\phpGedView\includes\classes\class_reportbase.php on line 45
Looks like a missing semicolon on the line above. I added one, and that fixed the error.
I'm still getting the PDOException
If it helps, I think the offending query is:
SELECT DISTINCT 'INDI' AS type, i_id AS xref, i_file AS ged_id, i_gedcom AS gedrec, i_isdead, i_sex FROM pgv_individuals JOIN pgv_dates AS filter1 ON (filter1.d_file=i_file AND filter1.d_gid=i_id) JOIN pgv_dates AS filter2 ON (filter2.d_file=i_file AND filter2.d_gid=i_id) WHERE i_file=1 AND filter1.d_fact='CHAN' AND filter1.d_julianday2<=2459595 AND filter2.d_fact='CHAN' AND filter2.d_julianday1>=2459565 ORDER BY filter1.d_julianday1
Last edit: GaryT 2022-01-15
Gary:
Thank you for the correction to class_reportbase.php . It will appear in the next iteration of FixPGV5.zip. I'm going to remove the change to the Googlemap default config from this ZIP file. However, this change WILL appear in the next SVN update.
Tomasz:
HELP!!!! I don't understand the PDO error that Gary reports. It's complaining about the ORDER BY that is generated at line 3363 of the latest version of class_reportbase.php .
The SQL statement shown in Gary's latest post is clear enough, so what is PDO complaining about??? Is that filter1.d_julianday1 supposed to be mentioned in the ON clause of the JOIN pgv_dates AS filter1 ??
HELP!!
Tomasz, Gary:
Given that PHP is becoming more and more strict (NOT a good sign for the language!!), perhaps we should stop updating PhpGedView after the PHP 8.1.1 fixes.
When I was a member of the COBOL language committe, we STRICTLY avoided changing the language so that old programs would no longer compile or work properly. The ONLY exception to this was the removal of the ALTER statement. Stupid reason for that: "ALTER makes program debugging much harder." Pure BS, of course: Just make DISPLAY display the current ALTER state.
I will look at this SQL error on evening but I'm afraid it may (or not) be data or DB specific. I have mariaDB at home and postgreSQL at work so I'll try to check both.
Still not SQL error but:
the line 2862 of class_reportbase.php should be:
if (empty($value)) $value = "''"; // PHP 8.1.1 doesn't like NULL
because str_replace converts empty string into nothing and $condition becomes (!='')
That is why I also replaced is_null with empty.
Tomasz:
The
empty($value)test will return TRUE when $value is the number zero or when $value is a string of length 1 containing the number zero. It will also return TRUE when $value is NULL, or FALSE or is an empty array.This means that the
if (empty($value))test will not work under all circumstances.Therefore, the correct line 2862 is still:
if (is_null($value)) $value = "''"; // PHP 8.1.1 doesn't like NULLbut with
"''", not just''(the string containing two apostrophes, not the empty string)Last edit: Tomasz Babczyński 2022-01-16
I just noticed a couple of minor comment typos in class_reportbase.php:
254 /aproxiamte/approximate/
256 /Stationary/Stationery/
708 /alignement/alignment/
715 /carachter/character/
Would it be easier if I learnt to generate a patch file?
In terms of the PDOException, I did a bit of googling on the error, and it seems it may be postgresql specific. e.g. https://github.com/querydsl/querydsl/issues/2443 - they just suggest "it can be resolved by adding the order by expression to the select clause". Or would that create other issues downstream?
The SQL mentioned by @GaryT is parsed and run correctly in mysql (mariaDB) but in postgreSQL generates
ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select listAdding
filter1.d_julianday1to the list of columns solves the issue at the database level but I have no idea where in code to correct it (maybe ab. 3262 line in reportbase) and more, what the side effects will appearTomasz:
Thank you. I can find the appropriate place in the code.
For what it's worth, my VERY old "test" system doesn't complain.
Gary:
Absolutely NOT!!! I don't "do" patches and all patches that are sent to me have to be manually translated to the correct code changes. This translation process is painful.
I'll fix the typos you have uncovered.
Stay tuned.
Gerry,
really??? Are you patching the code manually? Indeed, it is painful.
If you don't want commits, pull requests (if SVN allows them) nor patch files,
so how to give you changes? One line, some lines but in many files?
I suppose you don't want my current 828 lines long patch with missing globals and some typos corrections?
Tomasz:
Yup. I find it MUCH easier to keep track of what has changed in the code when I apply the corrections manually. This is especially true when several people work on the same script file.
Remember that I started programming over 60 years ago, when such tools didn't exist and everything was on punched cards.
I have already "translated" the patch file you posted earlier, and applied those patches. The revised FixPGV5.zip file contains everything you posted, and should be applied to your "test" system to replace the files already there.
New bugs should be reported against the files as they exist in the most recent iteration of the zip file.
Eh, what to say you with my only 40 years programming practise ;) I used punched cards but for fortran, not cobol. In fact I've never seen program in cobol although I know some cobol programmers.
So which form of reporting corrections do you prefer? zip with corrected files?
Yeah, those were the days. Started with actual machine language, where I had to do everything myself. Then, Assembler, then Fortran, then Cobol, etc. Learned Univac 1108 Assembler by writing a Fortran program to do whatever, and then inspecting and taking apart the resultant object code. Learned Univac Assembler to the extent that I was able to make a number of corrections to the Fortran compiler's optimizer. The Cobol compiler was a lot simpler. Univac was grateful, as was my employer.
The stories I could tell!, but enough bragging; nobody is listening anyway.
Regarding your question on how to submit fixes and corrections: Either a ZIP file with the complete .php file, or just a list of the changed lines (with line number, please). You will observe that I'm using the ZIP method to pass the corrections to Gary and to the rest of the world.
Gary:
Try the "new and improved" FixPGV5.zip . I hope this fixes the problem.
class_reportbase.php and functions_db.php were changed.
Basically, the columns mentioned in the ORDER BY clause now also appear in the SELECT list. This shouldn't cause problems in databases that aren't postgreSQL.
Tomasz:
Please let me know what happens. Thanks for your help.