Thanks for keeping PhpGedView alive

[Neil Sponagle]

I want both to thank Gerry Kroll (and others?) for continuing to support PhpGedView and, as well, to document how easy it was to upgrade to the latest version.

The reason for the upgrade was that I wanted switch from an ancient version of the XAMPP server software, running PHP 5.3.1, to the latest version of XAMPP, running PHP 7.3.4. The whole process may have taken a half hour, from start to finish.

The steps were:

Before stopping the old server:

1. Export the GEDCOM, using the old version of PhpGedView
2. Export the PhpGedView database table, using HeidiSQL

Switch to the new server:

1. Download a snapshot of the latest SVN version of PhpGedView from https://sourceforge.net/p/phpgedview/svn/HEAD/tree/trunk/phpGedView/
2. Unzip the new PhpGedView into the new server
3. Copy the old config.php and the old index directory the new PhpGedView
4. Import the old PhpGedView database table into the new server
5. Start the new PhpGedView
6. Import the old GEDCOM file into new PhpGedView (even though it looked as if this step was unnecessary)

So far everything seems to be working perfectly, and the new server is much faster than the old.

Once again, thanks for keeping PhpGedView alive.

[Gerry Kroll]

Neil:
You're welcome.

It's interesting that you're running PHP 7.3.4 . I have not been able to test using that version -- I'm on PHP 7.0.33, and others are other versions. I also have PHP 5.3.10 available, so everything MUST run on PHP 7 as well as that ancient version of PHP. So far, so good.

If you run into any problems, please let me know, so that I can try to solve them (with your help, of course).

There's a major update coming soon. I'm currently working on updating the TCPDF package to the last stable release 6.2.26 (it works OK), and also chasing a bunch of bugs in the Reports. The XML reports are WEIRD and not easy to debug.

[John Kaminski]

Thanks Neil for telling me how to update my old 4.3 version.
Gerry, I see that the r7239 version is more than double the size of my 4.3 version . (75 MB in the phpGedView directory compared to 15MB in my old version) Much of this is in the TCPDF directory and the googlemap directory. Are those directories required or can I omit them?

[oppiet30]

There is a difference between the PhpGedView-all.zip and the PhpGedView.Basic.zip

[John Kaminski]

Oppiet30, could you enlighten me as to where I find the basic version . Neil's link above did not specify which version it was, just that it was r7239 which fixes many of the PHP7 issues I was having. (my old v4.3 generated tens of MB of errors every month). Knowing where the basic.aip version resides would be for next time since Gerry helped me delete unnecessary modules and folders this time around.

[Gerry Kroll]

There are no "all" and "basic" ZIP files for version 4.3.1. Oppiet30 was talking about version 4.3.0, which SHOULD NOT BE USED.

4.3.1 has not been put on the PhpGedView download site -- it's still a work in progress. You need to download an SVN snapshot, and that correponds to what you'd find in the "all" file.

[John Kaminski]

Thanks, that clarifies things.

[Gerry Kroll]

You can delete any of the modules you don't want to use. Just delete the /modules/xxx directories for those unwanted modules. I find these modules to be useful, and they are the only ones I keep on my own system.

• GEDFact_assistant
• JWplayer
• lightbox
• slideshow

You can delete the TCPDF directory if you don't want to support the creation of PDF reports. I suggest you have a good look at the font files, and delete the ones you are not going to use. The XML files for creating PDF reports reference these fonts:

• courier
• dejavusans
• dejavusanscondensed
• dejavuserif
• dejavuserifcondensed
• dejavusansmono
• freesans
• freeserif
• freemono
• helvetica
• times

You can further reduce the size of your installation by deleting files for languages that your site won't support. The only absolutely REQUIRED files are the xxx.en.php ones. English is the fall-back when the other language files are incomplete.

[John Kaminski]

Thank you Gerry. I did as you suggested and I can now run my website without 50 MB of errors every month as well as being able to edit the configuration again. Neil, I did not move my files to a new server, just updated the software. Thus, I did not have to do anything with the database. All I did was upload what Gerry suggested, and copied over the old config.php and the old index directory. Everything seem s to work perfectly now.
Gerry, thank you so much for keeping PhpGedView alive. John from Ontario, Canada

[Gerry Kroll]

Ontario is a big province. I should know, I live there too.

I would recommend that you export the database to a GEDCOM file (no need to download), and then import the GEDCOM file you just created. Let PhpGedView replace the database contents. If there are any media on your site, you should NOT keep media links during the re-import. This will ensure that the database indexes are properly built.

The media links option is intended for incoming GEDCOM files that don't have any media references (such as those created by old versions of Family Tree Maker), while the original database (the one being replaced) DID have media links in it. This works best when the program that creates the GEDCOM (FTM, for example) keeps the same ID numbers every time you export that program's database to a GEDCOM. Unfortunately, my copy of Family Tree Maker isn't smart enough to do that, so after a re-import I still have to fix the media links in my PhpGedView installation. This is where the GEDFact_assistant module is truly useful.