Activity for Gerry Kroll
-
Gerry Kroll posted a comment on ticket #2979
Please check the public_html directory where PhpGedView is installed. Sometimes the "new and improved" PHP records errors that it encounters in a text file that you may find in the PhpGedView root directory. The name of this file varies, but usually contains "error".
-
Reordering of children fails
-
Please try the attached file edit_quickupdate.php. I don't think this will resolve your problem, but it's the version I am currently working on. Please don't bother with all that debug stuff you posted. Just reproduce a screen shot of the result of your test (if it fails). I'm interested in the actual error messages, including the line numbers. Please confirm: Does the family in question have both a Father and a Mother?
-
Nope. No plans, unless somebody other than me volunteers.
-
If the Family Search works when you're logged in as admin, then you're trying to find living people. By default, details about living people are not shown to anonymous (not logged in) users.
-
What version of PhpGedView are you using? You should be using the most recent version that you can download by following the "SVN" link at the top of this page. When you have installed the most recent version, you need to: 1. Log in with Admin rights and click on the "Manage GEDCOMs" link in the top menu of the page 2. Export the database to a GEDCOM file. You don't need to download that file. 3. Import the GEDCOM file you have just exported. Let the program replace the existing database contents....
-
You're using the WRONG version of PhpGedView. Install the latest-and-greatest version that you have downloaded from the SVN repository. Follow the "SVN" link at the top of this page. The have been lots of posts (and replies). No need to say it all again.
-
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Hello, David: I don't understand how this works either, so I can't help. Sorry, I only support the stuff I can understand. There hasn't been any recent work done on Google Maps. The most recent updates were done on July 17, 2022; I don't know what they were supposed to resolve. Before that, updates occurred in 2019 and 2016; again, no information. I wish Google would stop "fixing" things so that the old stuff, which used to work,...
-
Fix: Media firewall logs "implicit float to integer conversion loss of precision" when watermarking is active
-
Change: Minor corrections to several language files
-
I disagree that the fault is with PhpGedView. The GEDCOM checker is to be viewed as providing information only. PhpGedView is actually very lenient when it comes to non-conformance. It's your responsibility to ensure that you fill in the various fields in accordance with the GEDCOM "standard". There's no way the program can possibly do all that for you. The PAGE reference is supposed to point to the page in the Source document. Other fields in the SOUR record should enable you to find the source...
-
You should look at Tamura Jones' site, in the "standards" section, where you can find a link to download an annotated edition of the GEDCOM 5.5.1 specification. https://www.tamurajones.net/standards.xhtml This document provides LOTS of information, and is searchable. Mr. Jones is very knowledgable, and has authored numerous very informative articles on genealogy.
-
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> David: The error is that the PAGE reference doesn't conform to the GEDCOM standard. The text properly belongs in a NOTE. If you're happy with the citation as you have quoted it, ignore the "error". Regards, Gerry Kroll e-mail: gkroll@keldine.ca Phone: +1 613 836-3970 Mobile: +1 613 558-3990 On 2024-02-07 15:54, David Ledger wrote: <meta http-equiv="content-type" content="text/html; charset=UTF-8"> Doing a GEDCOM check for 'errors'...
-
The error is pointing at the PAGE line, which doesn't conform to the GEDCOM standard. It's too long, and is not allowed to be extended by means of a CONC line. The text you have quoted properly belongs in a NOTE.
-
Fix unexpected error in class_person.php (caused by error in old version of PHP manual)
-
Temp fix for unexpected error in class_person.php line 1804
-
Change: Appearance of names of persons and families when the Family name and the Given name are both unknown
-
Fix: Stray "?" terminating some auto-generated Login requests causes "You are not welcome here" error
-
Thank you, David. The problem here was that the stupid program tacked a question-mark to the tail end of an automatically generated reference to login.php. This doesn't happen often, so I just haven't bothered to fix this bug.
-
The "you are not welcome here" message was caused by a malformed Login request. This usually happens when the user who is attempting to log in is already logged in. The error can also happen when the prospective user's previous session expired and the user is attempting to resume working with the program after that session expired. When you are trying to log in, it's best to always close the browser completely before attempting a new login. That way, you are assured that the browser's session is...
-
The version of PhpGedView that you should have downloaded from the SVN repository is compatible with all versions of PHP from 5.6 right through to 8.1 . It should work with versions higher than 8.1, but I have not tested it, and users with those versions haven't reported any problems. The error you are reporting with functions.php at line 726 indicates that you are NOT using the most recent version from the SVN. When installing the SVN version, DO NOT pick-and-choose the various scripts you are installing....
-
Did you install the latest-and-greatest PhpGedView that you downloaded from the SVN repository? Click on "SVN" in the ribbon at the top of this page, and then click on "download snapshot". You need to describe to us excatly what steps you followed to install PhpGedView and "add a GED". Generally, you have to have the GED file present on your local computer, and then you upload and import the GED file into an existing database. The "upload and import" procedure is part of the GEDCOM configuration...
-
[4.3.1] $DBUSER == 'root' --> site_unavailable
-
Thank you for bringing this to our attention. This oversight will be corrected soon, probably by improving the error message.
-
You have already discovered that PhpGedView is not designed to do this. There's also zero chance that this will ever be implemented. I suggest that you set up a schedule to log in as admin and import the updated GEDCOM file. Weekly updates are probably too frequent. Perhaps you should be looking for something other than PhpGedView? I can't advise you in this regard.
-
If PhpGedView is already running, you don't need to establish the database tables or configure anything. There are no plans to implement anything having to do with "unattended" Admn functions. There are too many security considerations, and it's not something that many people would want or need. Exactly WHAT is it you're trying to achieve? What problems does this feature eliminate?
-
Can't be done. You need to log in with Admin rights in order to import a GEDCOM into the database. The database MUST exist, but PhpGedView will establish the necessary tables AFTER you have configured everything.
-
Fix: Automatic New user confirmation messages sent using wrong "from" address
-
Fix: Error in index.php and index_edit.php when MultiMedia disabled
-
Fix: Malformed URLs in zoom-in/out controls of timeline
-
nope. It ain't broke, so don't fix it.
-
This topic has been discussed at lest 20 times in the last year. You need to replace your PhpGedView installation with the version you can downoad from the SVN repository. Instructions on how to do this have also been posted lots of times. No need to repeat.
-
Fix: Various PHP 8 compatibility issues in Webservice and SOAP
-
Fix: More problems with the CSS parser
-
Fix: More problems with the CSS parser
-
Fix: Incorrect use of curly braces in CSS parser (introduced in previous SVN update)
-
Potential error in stylesheet themes/standard/style.css
-
Fixed in SVN 7362. The problem was that the CSS parser expected to see the contents of the CSS file, and NOT the name/location of the file. Also, all of the CSS files had errors. There were some lines in these CSS files that did not have a closing semi-colon on the last line before the closing right-parenthesis } . This made the CSS parser throw errors. Poor program logic here, but I won't bother the developer of the CSS parser with this.
-
Fix: "Potential error in stylesheet" message while viewing Statistics charts on Individual and Family lists
-
Tomasz: Thank you. I never expected that the error could originate from within PhpGedView itself. Arghh. The error points to the $css variable being not-empty. This is of, course, true since that $css variable contains the name of the CSS file being examined, and not its contents. I'll have to work through the logic, but I think the code is trying to reduce the CSS file so that only invalid entries are left. If, after reduction, we have stuff left over, we have an error. Since I know that there shouldn't...
-
It seems as though Google has "improved" the Charts system by deprecating the old Charts APIs that PhGedView is using. Now, we have to use the "Visualization" APIs. The new method of creating graphical charts is not at all compatible with the old. The new method may be more flexible, with many more features, but it's going to be a LOT of work and head-scratching to implement the new way of creating charts in PhpGedView. I don't look forward to doing this. Don't hold your breath, folks.
-
Tomasz: The strange thing is, when you fire up the Statistics plots from the main menu of any page (you don't have to be logged in), you don't see this error message on any of the many charts produced by the Google API. It's ONLY the histogram charts on the Individual and Family list pages. I think we're trying to resolve a bug in the Google histogram chart program. I checked the CSS of each theme, using the https://jigsaw.w3.org/css-validator/ CSS validator. The Cloudy theme's CSS file produces...
-
Potential error in stylesheet themes/standard/style.css
-
Confirmed. Happens on my site too, using Cloudy theme. The error message comes from Google, and is not very helpful. Not too sure what's making Google complain. I'll correct the very minor "observations" reported by various CSS validation programs. Let's see what happens.
-
The "Cannot modify header information" warning is the result of the system having printed some sort of error before trying to run the actual PhpGedView program. When you upgraded PhpGedView, did you leave the database intact, or did you start a new database? It sounds as if we're just not looking in the right place for that GEDCOM file. This file should have a .ged extension. I think we are wasting a lot of time here. I'll take over. With any luck, the problem will be easy to repair. Please e-mail...
-
You have a database collation conflict, where the site configuration says to use the database for UTF-8 collation, but the database hasn't been configured with a character set that natively supports the UTF-8 character set that is used by PhpGedView. You need to adjust the configuration of your site to not use the database for UTF-8 collation. Proceed thus: use your FTP client to make sure that the file /config.php has 777 permissions, log in with your Admin credentials, launch the Admin page by...
-
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Rick: That readme file hasn't been touched in almost two decades. I just can't be bothered. I'm all alone in the PhpGedView "developer" arena. Long story. When upgrading, it's VERY important that you let PhpGedView replace the existing database contents with whatever GEDCOM file you are able to Export from the existing database. If you neglect this IMPORTANT step, the database won't work properly. If you run into any problems whose...
-
Yes. Upgrade instructions can be found in numerous posts in the Help forum.
-
Please READ the discussions on upgrading your PhpGedView installation to the most recent version. You'll find lots of advice on how to do this. The discussion just a couple of topics below this one should work even if it doesn't exactly match your circumstances. The Help forum also has MANY discussions on the upgrade routine. If you're in doubt about what needs to be done, just ask.
-
Fix: Date range input does not work when both dates are of the form DD MMM YYYY
-
Fix: E-mail about GEDCOM changes sent in session language instead of accepting user's language
-
Add: Advice on file upload size limit
-
Fix: Missing diacritics in most Polish language files
-
Good news. Thank you for letting us know. Since the latest-and-greatest worked for you, I won't try to investigate the original cause of your problem.
-
Yes, that is correct.
-
You should upgrade your PhpGedView installation to the most recent version available for downloading as an SVN snapshot. Instructions on how to do this have been posted around here numerous times. I can do this for you, if you wish. e-mail me directly at gkroll (at) keldine (dot) ca if you wish to proceed in this direction.
-
Fix: Welcome blocks should show both Server time and Client time when they differ
-
Fix: Undefined variable $onload in /themes/cloudy/footer.php (canajun2eh)
-
Change: Additional language variables in facts.pl.php (tbabczynski)
-
Delete: In all themes, unused file print_header.php (canajuneh)
-
Yes, there were several other places in the program where the user name was used where the userid was expected. There probably are more of them. Your correction will be in the next SVN update.
-
Uncatched PDO (pgsql) exception trying send mail to user
-
php8 null access prohibited
-
Thank you. Very few people (myself included) use the googlemap module, so it's no surprise that there are errors in it. The attached placecheck.zip is placecheck.php with your correction applied. It will be in the next SVN update.
-
hourglass diagram formatting in Polish
-
Thank you. The attached ZIP file contains your fixes. Please try it and let me know if it's OK to post this to the SVN repository.
-
"Business Vista" and "4.1.3" ... My goodness, that's OLD!! The best way to handle this is to upgrade your PhpGedView installation on the "Vista" machine first, and then when the time comes, you just copy the whole PhpGedView installation to the new server. The PhpGedView installation can be copied directly using FTP and the database tables will need to be exported using some tool such as PhpMyAdmin and then imported into a previously set up database on the new server. The database credentials that...
-
Markus: Did upgrading your PhpGedView installation correct your problem?
-
Uncatched PDO exception trying edit gedcom privacy file
-
Fixed in SVN 7353
-
Fix: Incorrect calls to function userGedcomAdmin() in edit_privacy.php and printlog.php
-
Tomasz: You are absolutely correct. Please try the attached, and let me know whether this fixes both of your problems.
-
It looks as if the pgv_user_gedcom_setting database table on the second server (the postgresql version) is not populated correctly. I can't begin to speculate how this happened. It's most unlikely that the fault is in PhpGedView. I suggest that you use phpMyAdmin to inspect the pgv_gedcom and pgv_user_gedcom_setting tables on the "not working" server. The contents of the gedcom_id columns should be integers.
-
You need to upgrade your PhpGedView installation to the most recent version available from the SVN repository. You can download this version by following this link: https://sourceforge.net/p/phpgedview/svn/HEAD/tree/trunk/phpGedView and clicking on the "Download snapshot" button. If you need instructions on how to upgrade your installation, please ask here.
-
Fix: Incorrect use of #PGV_SCRIPT_NAME# in several language files. Should be #PGV_SCRIPT_PATH#.
-
The OP sent me a copy of his GEDCOM, which I was able to import into my "test" system, still running PHP 5.3 as well as into my "working" system, running PHP 7.4. No problems were encountered, and the error could not be reproduced. I suspect that the problem is a corrupt database or a corrupt index. In either case, an export-and-import should correct the problem because this action will blow away a possibly corrupt database table and then recreate the required tables and indexes.
-
Uncaught PDOException ... Illegal mix of collations
-
Call to a member function CalendarURL() on null
-
Fixed in SVN 7351
-
Research assistant (2 of 2) a non-numeric value encountered
-
Fixed in SVN 7351
-
Research assistant (1 of 2) convert_to_call() on null
-
Fixed in SVN 7351
-
Fix: PHP 7.4 incompatibilities in ra_functions.php when dates are missing
-
David: You are correct. The trailing right-paren was missing in both IF statements. I need to be MUCH more diligent in submitting corrections, even if I don't use the feature. The attached corrects this all-too-frequent oversight.
-
Research assistant (2 of 2) a non-numeric value encountered
-
The attachment to bug 2974 should fix this one too. <rant> Don't you just LOVE those "improvements" the PHP folks made to the language? They BROKE a lot of things in their eagerness to "modernize" the language. Obviously NEVER worked as real programmers or in a corporate support organization with real programmers. I would have been FIRED if I ever let that happen when I was working for a living. </rant>
-
Research assistant (1 of 2) convert_to_call() on null
-
Are you REALLY using the Research Assistant module, or are you just playing around? I don't advise using the Research Assistant. It hasn't been properly verified and your results may vary. I'm not about to embark on a comprehensive bug chasing exercise, since this module is useless to me. Anyhow: Try the attached. Unzip and copy the resultant functions_ra.php file to the /modules/research_assistant directory.
-
This appears to be a problem with one of the columns in your database. I can't reproduce this on my system, where all column definitions are consistent. You can try exporting your database to a GEDCOM, and then importing that just-exported GEDCOM, letting PhpGedView erase all existing database contents during the Import. BE SURE TO DO A DATABASE BACKUP BEFORE YOU START.
-
It's not fixed until the correction has made it into the SVN repository. I'll look after that.
-
Call to a member function CalendarURL() on null
-
add the following after line 1191 in /includes/classes/class_date.php : if (!is_null($this->date1)) Please let me know whether this works for you.
-
tpdf error
-
Sometimes errors that make no sense can be eliminated by clearing the browser's cache.
-
Which report exhibits this problem? On my system (PHP 7.4.29) I don't see this, no matter whether I'm logged in or not. However, I only tried the Birth Date & Place and Ahnentafel reports, and only in English.
-
timeline_ctrl 123 syntax error
-
Fixed once and for all in SVN 7350.
-
Fix: PHP 7.4 incompatibility in timeline_ctrl.php when undated events exist
-
timeline_ctrl 123 syntax error
1 >