What does "Cancel" on reports really do?
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
I am running 4.3.0 and when I go into any reports I notice that you can "Download report" or "Cancel". However the "Cancel" option doesn't seem to do anything. It wasn't clear if it should be taking me back to my previous action (aka back button), or to my personal portal page. What does "Cancel" on reports really do, or perhaps it should be removed?
You should be running PhpGedView version 4.3.1, that you can download as an SVN snapshot. Click on the "SVN" link at the top of this page.
"Cancel" doesn't do much. This option just lets you change any of the selected options.
It won't be removed, since it doesn't do any harm. "If it ain't broke, don't fix it."
Is this the latest version (4.3.1) phpgedview-svn-r7361-trunk.zip?
Last edit: Ricky Shykes 2023-02-25
Thanks Gerry. I agree with your logic.
I have upgraded to 4.3.1 r 7304 as you suggested, but now my new user emails come out with:
A prospective user registered himself with PhpGedView at #PGV_SERVER_NAME##PGV_SCRIPT_PATH#.
I just confirmed in 4.3.0 is was filling in the server name and script path correctly. Did the move from 4.3.0 to this new version require updates to the database tables or is it something else as all I did was I just overwrote all my old phpgedview files with the new snapshot only and flushed my browser cache?
Last edit: Douglas Terry 2021-06-28
Those values are calculated/determined in includes/session.php
PGV_SERVER_NAME is determined around line 269 of /includes/session.php, and PGV_SCRIPT_PATH a few lines later.
If these values are empty, you have a mis-configured server or your server is not setting the $_SERVER super variable properly, possibly for "security" reasons.
You ARE running PhpGedView through a URL entered into your browser, instead of at the command line??
Correct I am only running PhpGedView through a URL (same way between 4.3.0 & 4.3.1). Note however that as this is a new user registering for the first time it kicks off these emails to the administrator and the end user, so I am not sure there is a valid "session" at that time. How can I check if I have a misconfigured server? I have a valid path in the config.php file for "$SERVER_URL", which is where I might expect it to pick up the server and path info. Just as an info, in 4.3.0 lang.en file the mail01_subject variable used the #SERVER_NAME#, rather than the 4.3.1 #PGV_SERVER_NAME#.
Some more info to help with the topic:
Running on Synology NAS
Running nix as the Web server
Running php 7.0
Database running as MariaDB 10
Last edit: Douglas Terry 2021-06-28
If you have upgraded by just copying the new files to over-write the old, you'll have a few orphan files that won't do any harm -- they just take up space.
After upgrading, it's wise to access the Manage GEDCOMs page and re-import the existing GEDCOM file to replace the existing database contents and re-build the indexes. If you have previously configured PhpGedView to NOT synchronize the database and the GEDCOM when you make on-line changes, you'll need to export the existing database to a GEDCOM before re-importing that GEDCOM. The not-synchronize option is there to improve performance when you're doing a lot of on-line edits and your database is HUGE (more than about 10,000 persons).
This export-then-import works because the GEDCOM data is text information in the database, and the Export only looks at that text, and not any other fields. Usually, the Export is done while the old PhpGedView version is still able to run (before the upgrade), but that's not always possible, particularly when your friendly ISP has upgraded PHP so that the old version of PhpGedView can't run any longer.
PhpGedView version 4.3.1 is able to run on any version of PHP from 5.3 right through to 8.1. Version 4.3.0 won't work with anything newer than 7.0, but even with 7.0 you run into that famous problem with conflicting support for BMP files.
You're right -- This is a bug.
I'll fix the program as soon as I can. Stay tuned.
I followed your advice and exported and then reimported. I then windiff'd the two tree data files and only difference is headers indicating versions, but if it rebuilds the database all the better. I then logged out as admin and created a new dummy user and same result that the email immediately came to the administrator with bad #PGV_SERVER_NAME##PGV_SCRIPT_PATH# issue again.
Note I just saw your email come in refering to this as bug, but thought this info above is still useful for you.
The attached ZIP file contains replacements for three files.
This should correct the problem.
Unzip the attached file, and copy the result to your PhpGedView install directory.
Confirmed, these fix the issue. Thanks for the speedy correction and the support of this wonderful program.