Help! I am having the following errors come up at times on pages,
I don't understand what this might mean?
thanks for your help, Paul.
ERROR 8: Trying to access array offset on value of type null
0 Error occurred on line 1571 of file functions_edit.php in function add_simple_tag
1 called from line 1382 of file functions_mediadb.php in function show_media_form
2 called from line 591 of file addmedia.php
ERROR 8: Trying to access array offset on value of type null;
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 474 of file class_gedcomrecord.php in function
_getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 601 of file functions_print_lists.php in
function print_fam_table4 called from line 279 of file famlist.php
ERROR 8: Trying to access array offset on value of type null;
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 474 of file class_gedcomrecord.php in function
_getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 390 of file class_family.php in function getAllNames
4 called from line 614 of file class_gedcomrecord.php in function
getSortName
5 called from line 565 of file class_gedcomrecord.php in function Compare
6 called from in function usort
7 called from line 580 of file functions_db.php in function get_famlist_fams
8 called from line 278 of file famlist.php
ERROR 8: Trying to access array offset on value of type null;
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 477 of file class_gedcomrecord.php in function
_getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 390 of file class_family.php in function getAllNames
4 called from line 606 of file class_gedcomrecord.php in function
getFullName
5 called from line 176 of file family_ctrl.php in function init
6 called from line 34 of file family.php
ERROR 8: Trying to access array offset on value of type null;
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 477 of file class_gedcomrecord.php in function
_getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 499 of file class_gedcomrecord.php in function
getPrimaryName
4 called from line 1603 of file class_person.php in function
getPrimaryParentsNames
5 called from line 205 of file functions_print_lists.php in function
print_indi_table
6 called from line 279 of file indilist.php
None of those line numbers make sense. You appear to be trying to use an outdated version of PhpGedView.
Please upgrade your PhpGedView installation to the latest-and-greatest 4.3.1 that you can download as an SVN snapshot by clicking on the "SVN" link at the top of this page.
BEFORE YOU UPGRADE: Please run your old PhpGedView and access the Manage GEDCOMs page. Click on the "Export" link to export your database to a GEDCOM file. You don't need to download the resulting GEDCOM.
TO UPGRADE: Simply unzip the SVN snapshot to a temporary directory on your local PC and then copy the result to your server, over-writing all files and directories. Using your FTP client, set the permissions on your server to 777 for the following: (a) file /config.php ; (b) directory /media and all its contents ; (c) directory /index and all its contents. When your new PhpGedView is working properly, you can set the permissions on the /config.php file to 444 (read-only).
You'll end up with some orphan files that won't do any harm other than wasting a little space on the server.
CONTINUING THE UPGRADE: Launch PhpGedView and IMMEDIATELY access the Manage GEDCOMs page and re-import the GEDCOM file that you created during the Export, above. Let PhpGedView erase all database contents during the Import. This last step will ensure that the database tables are properly populated from the previously exported GEDCOM and that the database indexes are properly built.
Last edit: Gerry Kroll 2021-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Gerry, Thank you for your reply, however, I am using the latest PhpGedView 4.3.1.
as you can see here. https://www.stephenshistory.com.au/
I do think that my hosting provider upgraded the version php to PHP Version 7.4.20 recently.
Maybe that is causing the errors?
I am also seeing these errors showing in the "On This Day" section today BEFORE log-in, but, not AFTER log-in.
ERROR 8: Trying to access array offset on value of type null
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 477 of file class_gedcomrecord.php in function _getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 499 of file class_gedcomrecord.php in function getPrimaryName
4 called from line 1594 of file class_person.php in function getPrimaryParentsNames
5 called from line 1716 of file functions_print_lists.php in function print_events_table
6 called from line 102 of file todays_events.php in function print_todays_events
7 called from line 1 of file index.php(432) : eval()'d code in function eval
8 called from line 432 of file index.php
ERROR 8: Trying to access array offset on value of type null
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 477 of file class_gedcomrecord.php in function _getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 499 of file class_gedcomrecord.php in function getPrimaryName
4 called from line 1603 of file class_person.php in function getPrimaryParentsNames
5 called from line 1716 of file functions_print_lists.php in function print_events_table
6 called from line 102 of file todays_events.php in function print_todays_events
7 called from line 1 of file index.php(432) : eval()'d code in function eval
8 called from line 432 of file index.php
Any ideas?
Thanks
Paul.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Isn't it fixed in the 7268 revision from the 7 Jan 2021?
Try to update PGV from SVN to the current version as it seams you have not up-to-date version, although not so old as Gerry suggested. :)
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The line numbers don't make sense because they point to code that is completely different in the current SVN version. There have been LOTS and LOTS of changes in the last 8 months or so.
Back in January, the problem was traced to Family records where either the Husband or the Wife was missing.
@Paul: Just because you previously updated your installation from the SVN, doesn't mean that the SVN code hasn't changed since you last downloaded an SVN snapshot.
To help with diagnosing problems of this nature, the current SVN version displays the SVN revision number you're running at the top of the Admin page. This information comes from the changelog.txt file. As long as everyone who makes changes to the SVN keeps this information updated, that should work perfectly. Right now, I'm the only one who posts anything to the SVN repository.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So the version shown on the Welcome page is not the full version in use info,
"This GEDCOM was created using PhpGedView 4.3.1 on 29 October 2020" is shown.
I have looked in the Admin page but it still only shows 4.3.1, no SVN info at all.
I will have a go at upgrading to the latest SVN and see how it is after that.
Thankyou @ThomasZ & Gerry for your help.
Cheers
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Gerry,
I have done the re-upload but now my webhost is blocking access to ...includes/session.php
They are saying it is infected with malware.
can you please email me a clean copy of the session.php file?
Thanks
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Gerry,
I have done the re-upload but now my webhost is blocking access to ...includes/session.php
They are saying it is infected with malware.
can you please email me a clean copy of the session.php file?
Thanks
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just downloaded an SVN snapshot. The /includes/session.php file in the downloaded snapshot is identical to the one I e-mailed you, except that the line endings of the snapshot are Unix (LF only) and the one I e-mailed you has DOS line endings (CR-LF).
The different line endings shouldn't matter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Gerry,
The web host still thinks the file is suspect but has agreed to allow access again.
They have said the following
Hello Paul,
I reported the case to our system administrators and we will update you here as soon as we have more information. In the meantime, I removed the limit on the site and it is now accessible.
Thank you for your patience in the meantime!
Best Regards,
Emanuil Kostadinov
Technical Support Team
In this process they had me "clean" the site which involved deleting all the files & re-uploading them.
I did do a phpgedview export and copied the file to a different directory before this all happened & I also moved my media directory and it's contents to a directory that was not getting deleted.
I have now moved the phpgeview export file back to the index folder and the media folder back to where it was before.
I am now having a problem when I access the URL I only get the following errors.
ERROR 256: DB connection error in PGV_DB::createInstance(): SQLSTATE[HY000][1045] Access denied for user 'root'@'localhost' (using password: YES)
Fatal error: DB connection error in PGV_DB::createInstance(): SQLSTATE[HY000][1045] Access denied for user 'root'@'localhost' (using password: YES) in /home/customer/www/stephenshistory.com.au/public_html/includes/classes/class_pgv_db.php on line 405
I'm not sure what I've done wrong or how to fix it?
Cheers
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Paul,
did you have database with root account and your web host have allowed this? Really??
If not or you are unsure then probably you have changed the config.php file in the index directory. Root is the default db user. Probably you had the different user for the db.
Tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The /config.php file contains invalid database credentials.
If you have a backup copy of the old installation, copy the /config.php file to the new installation.
If you don't have a backup copy, delete any existing /config.php file, and copy /config.dist, re-naming the copy to /config.php. Be sure to give this new copy 777 permissions. Launch PhpGedView and go through the configuration steps. Once the correct database credentials have been entered, you should be good to go. B e sure to set the permissions on /config.php to 444 when you're done.
You must get your hosting provider to reveal WHAT "malware" they're detecting, and what malware signature they found. There is no "malware" in session.php, so we must track down the false positive. (Unless, of course, your copy of session.php actually IS infected.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Gerry,
That did the trick. All working fine again now.
Hooray :) Woohoo :)
Web host still has not replied with any more info.
I have zipped the session php file and emailed it to you just now.
Thanks again.
Cheers
Paul https://www.stephenshistory.com.au
now showing on admin page is PhpGedView 4.3.1 SVN 7306
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I compared the session.php file that Paul sent me with what's supposed to be in the SVN repository. They're identical, except for line endings (which shouldn't matter).
Paul's version is using Unix line endings (LF only), and my own copy uses DOS line endings (CR-LF). Unix line endings are supposed to be used in the SVN, because that's what the SVN properties of each file say.
It will be interesting to see what Paul's hosting provider has to say/reveal. I say they're full of it.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Gerry,
A final update to the case!
The hosting provider has now said the following.
Hello Paul,
Just a quick update on the case.
Upon further review, I see that the limit on the website has already been removed and my colleague has reported this file as a false positive. That said, you can consider this case closed as our administrators will review the file and remove it from the malware scanner.
Best Regards,
Stoyan E.
Technical Support
Annoying for us all!
Thank you for your help with this.
Cheers
Paul.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the update, although that's not the response I had hoped for from your hosting company.
Rather than just saying, "Ooops, our bad," they should have provided details on which of their malware scanners yielded a false positive and why that scanner thought PhpGedView's latest iteration of the session.php script was infected.
It sounds as if this malware scanner is home-grown, and it just has a list of "suspect" script names.
I sincerely hope that nobody else will report this malware positive, because then we have a REAL problem that needs to be investigated by yours truly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Gerry, here is their latest reply.
Again not helpful.
Jul 11, 2021 11:13 PM
Hello Paul,
Our System Administrators have not had the chance to review the file in details yet. The mdet scanner flagged it as bad with signature "php_self_delete_1". Keep in mind the scanner uses our own definitions. Since the limit has been removed, there is no reason to keep the case open. Our System Administrators will update the scanner's definitions so this does not occur again as we have found no actual threat from the file.
Best Regards,
Georgi Sm.
Senior Technical Support
Thanks for your help
Cheers
Paul.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sometimes the scanner returns false positives, as is the case here. Indeed there's nothing to worry about and we will update our scanner's parameters, so it doesn't detect that type of code as malicious in the future.
Should you need further assistance on our end, don't hesitate to contact us at any time by submitting a new support request in the appropriate category.
Best Regards,
Georgi Milkov
Senior Technical Support Team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Help! I am having the following errors come up at times on pages,
I don't understand what this might mean?
thanks for your help, Paul.
ERROR 8: Trying to access array offset on value of type null
0 Error occurred on line 1571 of file functions_edit.php in function
add_simple_tag
1 called from line 1382 of file functions_mediadb.php in function
show_media_form
2 called from line 591 of file addmedia.php
ERROR 8: Trying to access array offset on value of type null;
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 474 of file class_gedcomrecord.php in function
_getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 601 of file functions_print_lists.php in
function print_fam_table4 called from line 279 of file famlist.php
ERROR 8: Trying to access array offset on value of type null;
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 474 of file class_gedcomrecord.php in function
_getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 390 of file class_family.php in function getAllNames
4 called from line 614 of file class_gedcomrecord.php in function
getSortName
5 called from line 565 of file class_gedcomrecord.php in function Compare
6 called from in function usort
7 called from line 580 of file functions_db.php in function get_famlist_fams
8 called from line 278 of file famlist.php
ERROR 8: Trying to access array offset on value of type null;
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 477 of file class_gedcomrecord.php in function
_getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 390 of file class_family.php in function getAllNames
4 called from line 606 of file class_gedcomrecord.php in function
getFullName
5 called from line 176 of file family_ctrl.php in function init
6 called from line 34 of file family.php
ERROR 8: Trying to access array offset on value of type null;
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 477 of file class_gedcomrecord.php in function
_getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 499 of file class_gedcomrecord.php in function
getPrimaryName
4 called from line 1603 of file class_person.php in function
getPrimaryParentsNames
5 called from line 205 of file functions_print_lists.php in function
print_indi_table
6 called from line 279 of file indilist.php
None of those line numbers make sense. You appear to be trying to use an outdated version of PhpGedView.
Please upgrade your PhpGedView installation to the latest-and-greatest 4.3.1 that you can download as an SVN snapshot by clicking on the "SVN" link at the top of this page.
BEFORE YOU UPGRADE: Please run your old PhpGedView and access the Manage GEDCOMs page. Click on the "Export" link to export your database to a GEDCOM file. You don't need to download the resulting GEDCOM.
TO UPGRADE: Simply unzip the SVN snapshot to a temporary directory on your local PC and then copy the result to your server, over-writing all files and directories. Using your FTP client, set the permissions on your server to 777 for the following: (a) file /config.php ; (b) directory /media and all its contents ; (c) directory /index and all its contents. When your new PhpGedView is working properly, you can set the permissions on the /config.php file to 444 (read-only).
You'll end up with some orphan files that won't do any harm other than wasting a little space on the server.
CONTINUING THE UPGRADE: Launch PhpGedView and IMMEDIATELY access the Manage GEDCOMs page and re-import the GEDCOM file that you created during the Export, above. Let PhpGedView erase all database contents during the Import. This last step will ensure that the database tables are properly populated from the previously exported GEDCOM and that the database indexes are properly built.
Last edit: Gerry Kroll 2021-07-07
Hi Gerry, Thank you for your reply, however, I am using the latest PhpGedView 4.3.1.
as you can see here. https://www.stephenshistory.com.au/
I do think that my hosting provider upgraded the version php to PHP Version 7.4.20 recently.
Maybe that is causing the errors?
I am also seeing these errors showing in the "On This Day" section today BEFORE log-in, but, not AFTER log-in.
ERROR 8: Trying to access array offset on value of type null
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 477 of file class_gedcomrecord.php in function _getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 499 of file class_gedcomrecord.php in function getPrimaryName
4 called from line 1594 of file class_person.php in function getPrimaryParentsNames
5 called from line 1716 of file functions_print_lists.php in function print_events_table
6 called from line 102 of file todays_events.php in function print_todays_events
7 called from line 1 of file index.php(432) : eval()'d code in function eval
8 called from line 432 of file index.php
ERROR 8: Trying to access array offset on value of type null
0 Error occurred on line 1649 of file class_person.php in function _addName
1 called from line 477 of file class_gedcomrecord.php in function _getAllNames
2 called from line 1834 of file class_person.php in function getAllNames
3 called from line 499 of file class_gedcomrecord.php in function getPrimaryName
4 called from line 1603 of file class_person.php in function getPrimaryParentsNames
5 called from line 1716 of file functions_print_lists.php in function print_events_table
6 called from line 102 of file todays_events.php in function print_todays_events
7 called from line 1 of file index.php(432) : eval()'d code in function eval
8 called from line 432 of file index.php
Any ideas?
Thanks
Paul.
Isn't it fixed in the 7268 revision from the 7 Jan 2021?
Try to update PGV from SVN to the current version as it seams you have not up-to-date version, although not so old as Gerry suggested. :)
thank you
@Thomasz: Thank you! You are absolutely correct.
The line numbers don't make sense because they point to code that is completely different in the current SVN version. There have been LOTS and LOTS of changes in the last 8 months or so.
Back in January, the problem was traced to Family records where either the Husband or the Wife was missing.
@Paul: Just because you previously updated your installation from the SVN, doesn't mean that the SVN code hasn't changed since you last downloaded an SVN snapshot.
To help with diagnosing problems of this nature, the current SVN version displays the SVN revision number you're running at the top of the Admin page. This information comes from the changelog.txt file. As long as everyone who makes changes to the SVN keeps this information updated, that should work perfectly. Right now, I'm the only one who posts anything to the SVN repository.
So the version shown on the Welcome page is not the full version in use info,
"This GEDCOM was created using PhpGedView 4.3.1 on 29 October 2020" is shown.
I have looked in the Admin page but it still only shows 4.3.1, no SVN info at all.
I will have a go at upgrading to the latest SVN and see how it is after that.
Thankyou @ThomasZ & Gerry for your help.
Cheers
Paul
Hi Gerry,
I have done the re-upload but now my webhost is blocking access to ...includes/session.php
They are saying it is infected with malware.
can you please email me a clean copy of the session.php file?
Thanks
Paul
Hi Gerry,
I have done the re-upload but now my webhost is blocking access to ...includes/session.php
They are saying it is infected with malware.
can you please email me a clean copy of the session.php file?
Thanks
Paul
They're full of shit.
Please e-mail me a copy of YOUR session.php file. E-mail me directly at
gkroll (at) keldine (dot) ca.
However, I am posting the session.php file that is in the SVN repository, just in case your download was faulty.
I just downloaded an SVN snapshot. The /includes/session.php file in the downloaded snapshot is identical to the one I e-mailed you, except that the line endings of the snapshot are Unix (LF only) and the one I e-mailed you has DOS line endings (CR-LF).
The different line endings shouldn't matter.
Hi Gerry, Once I get home later I will email you a copy of the session.php that I was using.
Thank you for your help
Cheers
Paul
Hi Gerry,
The web host still thinks the file is suspect but has agreed to allow access again.
They have said the following
Hello Paul,
I reported the case to our system administrators and we will update you here as soon as we have more information. In the meantime, I removed the limit on the site and it is now accessible.
Thank you for your patience in the meantime!
Best Regards,
Emanuil Kostadinov
Technical Support Team
In this process they had me "clean" the site which involved deleting all the files & re-uploading them.
I did do a phpgedview export and copied the file to a different directory before this all happened & I also moved my media directory and it's contents to a directory that was not getting deleted.
I have now moved the phpgeview export file back to the index folder and the media folder back to where it was before.
I am now having a problem when I access the URL I only get the following errors.
ERROR 256: DB connection error in PGV_DB::createInstance(): SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost' (using password: YES)
Fatal error: DB connection error in PGV_DB::createInstance(): SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost' (using password: YES) in /home/customer/www/stephenshistory.com.au/public_html/includes/classes/class_pgv_db.php on line 405
I'm not sure what I've done wrong or how to fix it?
Cheers
Paul
Hi Paul,
did you have database with root account and your web host have allowed this? Really??
If not or you are unsure then probably you have changed the config.php file in the index directory. Root is the default db user. Probably you had the different user for the db.
Tom
Thanks Tom, no the error is identified by Gerry.
Cheers.
Paul
The /config.php file contains invalid database credentials.
If you have a backup copy of the old installation, copy the /config.php file to the new installation.
If you don't have a backup copy, delete any existing /config.php file, and copy /config.dist, re-naming the copy to /config.php. Be sure to give this new copy 777 permissions. Launch PhpGedView and go through the configuration steps. Once the correct database credentials have been entered, you should be good to go. B e sure to set the permissions on /config.php to 444 when you're done.
You must get your hosting provider to reveal WHAT "malware" they're detecting, and what malware signature they found. There is no "malware" in session.php, so we must track down the false positive. (Unless, of course, your copy of session.php actually IS infected.)
Thanks Gerry,
That did the trick. All working fine again now.
Hooray :) Woohoo :)
Web host still has not replied with any more info.
I have zipped the session php file and emailed it to you just now.
Thanks again.
Cheers
Paul
https://www.stephenshistory.com.au
now showing on admin page is PhpGedView 4.3.1 SVN 7306
I compared the session.php file that Paul sent me with what's supposed to be in the SVN repository. They're identical, except for line endings (which shouldn't matter).
Paul's version is using Unix line endings (LF only), and my own copy uses DOS line endings (CR-LF). Unix line endings are supposed to be used in the SVN, because that's what the SVN properties of each file say.
It will be interesting to see what Paul's hosting provider has to say/reveal. I say they're full of it.
Hi Gerry,
A final update to the case!
The hosting provider has now said the following.
Hello Paul,
Just a quick update on the case.
Upon further review, I see that the limit on the website has already been removed and my colleague has reported this file as a false positive. That said, you can consider this case closed as our administrators will review the file and remove it from the malware scanner.
Best Regards,
Stoyan E.
Technical Support
Annoying for us all!
Thank you for your help with this.
Cheers
Paul.
Thanks for the update, although that's not the response I had hoped for from your hosting company.
Rather than just saying, "Ooops, our bad," they should have provided details on which of their malware scanners yielded a false positive and why that scanner thought PhpGedView's latest iteration of the session.php script was infected.
It sounds as if this malware scanner is home-grown, and it just has a list of "suspect" script names.
I sincerely hope that nobody else will report this malware positive, because then we have a REAL problem that needs to be investigated by yours truly.
Hi Gerry,
I'll ask them again.
Cheers
Paul
Hi Gerry, here is their latest reply.
Again not helpful.
Jul 11, 2021 11:13 PM
Hello Paul,
Our System Administrators have not had the chance to review the file in details yet. The mdet scanner flagged it as bad with signature "php_self_delete_1". Keep in mind the scanner uses our own definitions. Since the limit has been removed, there is no reason to keep the case open. Our System Administrators will update the scanner's definitions so this does not occur again as we have found no actual threat from the file.
Best Regards,
Georgi Sm.
Senior Technical Support
Thanks for your help
Cheers
Paul.
one final update
Thank you for the update, Paul.
Sometimes the scanner returns false positives, as is the case here. Indeed there's nothing to worry about and we will update our scanner's parameters, so it doesn't detect that type of code as malicious in the future.
Should you need further assistance on our end, don't hesitate to contact us at any time by submitting a new support request in the appropriate category.
Best Regards,
Georgi Milkov
Senior Technical Support Team