#2865 Content of additional Advanced HTML blocks may be lost.

v4.2.4
closed-fixed
None
5
2011-03-23
2011-03-13
ggpauly
No

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.

Discussion

  • Gerry Kroll

    Gerry Kroll - 2011-03-13

    I'm pretty sure that the content duplication is not intentional. Any new Advanced HTML block should be initialized to the default text.

     
  • ggpauly

    ggpauly - 2011-03-14

    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.

     
  • Gerry Kroll

    Gerry Kroll - 2011-03-14

    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.

     
  • ggpauly

    ggpauly - 2011-03-14

    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.

     
  • Gerry Kroll

    Gerry Kroll - 2011-03-23
    • assigned_to: nobody --> canajun2eh
    • status: open --> closed-fixed
     
  • Gerry Kroll

    Gerry Kroll - 2011-03-23

    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"

     
  • Gerry Kroll

    Gerry Kroll - 2011-03-23

    "index_edit.php" and "includes/authentication.php" for 4.2.4

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks