Repair fix after upgrade 6.4.1 to 6.4.3

[Joachim]

Hi Mark and Stéphane,

the upgrade from 6.4.1 to 6.4.3 both on my test and production servers went smoothless. Only one point of slight irritation: despite having set memory_limit to 256M in my php.ini, WIKINDX displays an empty page with WIKINDX_MEMORY_LIMIT set to FALSE in config.php; I've set it to 128M (in my old config.php it was 64M), and all is good …

Stéphane, maybe you'll be interested with the results of repair kit used on my DB (test server only by now). I've got a huge amount of errors in DB integrity (see screenshot), and I had to run repair kit 32 times (!) before there were no errors left. Is that a reasonable result?

Best
Joachim

[Stéphane Aulery]

Hi Joachim,

the upgrade from 6.4.1 to 6.4.3 both on my test and production servers went smoothless. Only one point of slight irritation: despite having set memory_limit to 256M in my php.ini, WIKINDX displays an empty page with WIKINDX_MEMORY_LIMIT set to FALSE in config.php; I've set it to 128M (in my old config.php it was 64M), and all is good …

Could you past here the code of WIKINDX_MEMORY_LIMIT from your previous config.php file?

Regards,

[Joachim]

Of course, here you are:

public $WIKINDX_MEMORY_LIMIT = "64M";

In my php.ini:

memory_limit = 256M

[Stéphane Aulery]

The code is really simple and should have copied the original value. I will check later. FALSE is also fine because memory_limit in php.ini is higher.

        if (property_exists($tmpconfig, 'WIKINDX_MEMORY_LIMIT') && is_string($tmpconfig->WIKINDX_MEMORY_LIMIT))
        {
            $newConfig = str_replace('%%WIKINDX_MEMORY_LIMIT%%', '"' . $this->escapePHPDoubleQuotedString($tmpconfig->WIKINDX_MEMORY_LIMIT) . '"', $newConfig);
        }
        elseif (property_exists($tmpconfig, 'WIKINDX_MEMORY_LIMIT') && is_int($tmpconfig->WIKINDX_MEMORY_LIMIT))
        {
            $newConfig = str_replace('%%WIKINDX_MEMORY_LIMIT%%', strval($tmpconfig->WIKINDX_MEMORY_LIMIT), $newConfig);
        }
        else
        {
            $newConfig = str_replace('%%WIKINDX_MEMORY_LIMIT%%', 'FALSE', $newConfig);
        }

[Stéphane Aulery]

I could not reproduce this error either.

[Stéphane Aulery]

Hi joachim,

Stéphane, maybe you'll be interested with the results of repair kit used on my DB (test server only by now). I've got a huge amount of errors in DB integrity (see screenshot), and I had to run repair kit 32 times (!) before there were no errors left. Is that a reasonable result?

I'm sorry for these errors. I added 47 missing indices in a single query. Maybe one of the indexes already exists in your database or with MySQL (unlike MariaDb) there is a runtime error.

For me this means that I have to do a 6.4.4 to recreate each index by executing the queries separately.

The syntax of MySQL / Mariab for index creation is problematic because you cannot directly test whether an index already exists.

Thanks for the information.

Regards,

[Joachim]

On both servers I have MariaDB 10.3.27. Maybe it helps that you can look at my adminer.

[Stéphane Aulery]

Yes, I will execute each query one by one and see if I could find a culprit.

[Stéphane Aulery]

I did the test and can't get a single crash.

Did you experience a timeout?

[Joachim]

No crash or timeout, only a blank page.

[Stéphane Aulery]

Blank page? That sounds like a crash with errors messages disabled.

And that happens before you login or after? At what step?

[Joachim]

Oops, sorry, no, I related to the wrong problem (with WIKINDX_MEMORY_LIMIT).
No, as I wrote, Repair Kit managed to fix all problems after 32 rounds. No problems or crashes, I wanted only to mention the many iterations it needed. No complaints here, if this is normal behavior.

[Stéphane Aulery]

It shouldn't have happened, but as a precaution, I redo the creation of indexes in the next version 6.4.4.

[Joachim]

I just went through the repairs of DB integrity on my production server. All went well but for the last step, when I got this error message:

#0  SQL->sqlDie(Incorrect table definition; there can be only one auto column and it must be defined as a key, 
[SQL ERROR] ALTER TABLE wkx_configtemp DROP PRIMARY KEY;

) called at [/var/www/wikindx/core/libs/SQL.php:3184]
#1  SQL->internalQuery(ALTER TABLE wkx_configtemp DROP PRIMARY KEY;, ) called at [/var/www/wikindx/core/libs/SQL.php:229]
#2  SQL->query(ALTER TABLE wkx_configtemp DROP PRIMARY KEY;, ) called at [/var/www/wikindx/core/libs/SQL.php:254]
#3  SQL->queryNoResult(ALTER TABLE wkx_configtemp DROP PRIMARY KEY;) called at [/var/www/wikindx/components/plugins/repairkit/index.php:639]
#4  repairkit_MODULE->dropIndex(wkx_configtemp, PRIMARY) called at [/var/www/wikindx/components/plugins/repairkit/index.php:352]
#5  repairkit_MODULE->dbIntegrityFix() called at [/var/www/wikindx/index.php:136]
[SQL ERROR] ALTER TABLE wkx_configtemp DROP PRIMARY KEY;

The last stage, when I run the DB integrity repair again, is in the screenshot.

Joachim

[Stéphane Aulery]

The wkx_configtemp table have been removed a long time ago. just drop it.

[Joachim]

Thanks, that helped: The database structure is correct and there is nothing to fix.

[Stéphane Aulery]

:-))