If a second Advanced HTML block is in use, moving it up or down causes the content of the second block to be overwritten with the content of the first Advanced HTML block. This causes irretrievable loss of data unless a database backup or other copy of the content is available.
This looks like another manifestation of bug 1390934. It looks like javascript in index_edit.php is causing the code that duplicates existing Advanced HTML block content in new Advanced HTML blocks to be run inappropriately.
It might be easier to not duplicate content in new blocks. This feature is probably not expected, so its loss will be seldom missed, and it's easy enough to copy and paste if a duplication is desired. Multiple Advanced HTML blocks is probably a rarely used feature, but the consequences of this bug - data loss - may be severe.
I can follow up with a patch, but I'd like to know if removing the content duplication feature is acceptable.
I don't know if the HTML block or other blocks are also affected by this bug.
I'm pretty sure that the content duplication is not intentional. Any new Advanced HTML block should be initialized to the default text.
The block arrays do not have identifiers for each block, only the type.
This makes it impossible to identify which block is intended when there are multiple blocks of the same type and they are moved around.
It will be possible (I think, and with some effort) to keep the existing blocks, but it will not be possible for a genealogist to switch their order.
What do you think about keeping the block id with the block arrays (main and right)? This will simplify the update code logic.
There's no reason why the sequence number of each block couldn't be stored in the database. I thought it was, but it's been several years since I looked at the code.
If we change this, we have to be sure that existing configurations, that do not have the sequence number, would continue to work. If a new database field is added, the update to the database should be automatic, launched on first use of the updated PGV logic.
Both sequence number and a unique id for each block are stored in the database. I don't think any database structure changes are needed.
It's the Javascript arrays, that are passed on to PHP, that don't have any information except the order of the blocks identified only by their type. We need to pass the block id's to PHP so the blocks can be identified for reordering.
Fixed in SVN, using updates supplied by ggpauly. (Thanks!)
To apply this patch to PGV version 4.2.4, download the attached ZIP file to your local PC, unZip it, and copy the result to the server directory where PhpGedView is installed.
The zip file contains "index_edit.php" and "includes/authentication.php"
"index_edit.php" and "includes/authentication.php" for 4.2.4