After an install with upgrade, tiki-admin displays the error "invalid database" ad-vitam

• Consistency
• Error
• Regression
• Usability

(Not yet checked for trunk)

After running installer with upgrade we get the message "Invalid database run installer..."

Running installer don't changes anything to database, but the message is still displayed.
It is a consistency "deadlock by soft".

The lonely thing generated by installer is a reset which needs to reset manually the admin account and clear all caches and cookies (see #4066 admin login problem).

!!!Going on 12/06/2011

I need to check the soft.

The message is sent by "installer" $installer instance of class installer in installib
It checks before the validation of patches on db using $installer->recordPatch($patch) for each one.
recordPatch function in installer records the patch into tiki_schema as done with his full date.

The concerned (got by a var_dump) patch is "20110904_shoutbox_def_tweetid_tiki"
is not into the tiki_schema table.
So the test functions, but the tiki-install failed to make this patch on another version OK, as it is defined.

__When it runs now (installer at 8.1 level) it don't tries to make the upgrade. This is the deadlock.
What is done if an old patch is not there !!!

More there is no report at all.__

1. 8.1 Invalid Db After Installer 01
2. 8.1 Invalid Db After Installer 02

? I began to look at, but I don't know this part of the soft.

!!!Going on 12/06/2011

In my opinion, there is no solution with a good reliability while :

• we will not have soft part able to make a comparison of db schema included into the tiki.sql releases, and with get and check the actual schema and report with the actual tiki.sql schema
• When the actual schema at the end of installer is not OK :

run a comparison to find which version is really installed

• Generate a report which can be read by a link into the warning message.
• Further tiki_schema could have two new columns the version which is the first, the latest version of validity. So when old patches are into the list the could be run automatically if they are valid.

The whole problem is that it is impossible to be sure that an old patch as been well done without the treatment that I describe here. This process give the necessary security and reliability.
It needs work but it is not terrible.
The particular case treatment :
In my case it have been simple. The level of tiki_shoutbox was 4.1 but as empty I have replaced it with the last version. The installer in 8.1 could not run 20110904_shoutbox_def_tweetid_tiki2010 because 2010_better_column_fix_tiki.php had not run for unknown reason in his time (the other update of the same patch had been done normally before... nothing to explain).
We cannot, we must'nt risk bugs for this problem

To do ?

!!!Going on 12/06/2011
Know everything above.

• Add var dump into the function to dump the id of the patch var_dump($this->patches) in requiresUpdate() function of installib . This will display the patch(es) not done.
• You will find the sql instruction with the name into the dir

installer/schema

• Directly make the upgrade with phphmyadmin (if mysql) manually
• Add the record to tiki_schema

This bug has been demonstrated on show2.tiki.org

Please demonstrate your bug on show2.tiki.org

This bug has been demonstrated on show.tikiwiki.org

Please demonstrate your bug on show.tikiwiki.org