[Kerry Choy]

This was previously reported as 1534495 but (I think)
should have been posted as a 4.1 bug.

I get the problem running in 4.0.l stable. I've
observed that I can set up a FAQ list which appears to
be hardened to the database (check the table and the
rows are present). After doing stuff, the whole FAQ
list dissappears. #1534495 and perhaps #1487594 seem to
refer to this.

The problem seems to be that the setBlocks function in
administration.php would hose all the rows related to
the userid that it's being invoked for. Since the
FAQ's are are kept in the same username as the default
for the GEDCOM, something like "Reset to Default
Blocks" will wipe the FAQ's. I assume there are other
circumstances in which setBlocks will be called.

Other defects suggest a separate table for FAQ's.
Another solution might be to assign a different, static
value for userid in the pgv_blocks table. Two
architectural questions:
1. Would you want different FAQ's for different GEDCOM
files?
2. Is this good design practice anyway?

Logged In: YES
user_id=979969

Made a patch. See 1553362

Logged In: YES
user_id=1061833

Thanks for someone else noticing this most aggravating bug.
We've been complaining about this unexpected action since
Roland created this feature in response to our RFE.

Just last week our 4.02 site's FAQ was hosed again, with all
the FAQ line in the MySQL DB simply being removed. We have
taken to doing a SQL backup periodically on the Blocks
table, so we simply dropped it and restored to the BU, but
this is annoying.
-Stephen

• assigned_to: nobody --> yalnifj

[Anonymous]

Logged In: YES
user_id=1254634
Originator: NO

I've just been working on the same problem with a user in the Help forum. I'll advise him to implement the patch - but whats the status of a proper fix?

Logged In: YES
user_id=1061833
Originator: NO

FAQ is disappearing again! Any modification of the Welcome page and Portal layouts (blocks) seems to be a trigger. MySQL simply deletes the entries for the FAQs

• milestone: --> v3.3.8

• status: open --> pending

This code has been rewritten since the bug was reported, and I can't reproduce it.

Can we close it?

Yes. Close thanks.

• status: pending --> open