Database update version does not match CMS version

[Nick Savov]

I'm trying to track down a bug where one of the sites is producing the following error message in administrator/index.php?option=com_installer&view=database:

Database update version (None) does not match CMS version (2.5.27)

Does anyone know where it's checking for the "None" or "2.5.27"?

-------

By the way, if I try the fix button, the error still displays.

For other information, it's showing:

Database schema version (in #__schemas): 2.5.27.

Update version (in #__extensions): None.

Database driver: mysqli.

66 database changes were checked successfully.

48 database changes did not alter table structure and were skipped.

Also, attempting to update in extension manager results in https://github.com/joomla/joomla-cms/issues/5006

-------

Kind regards,
Nick

[Nick Savov]

Based on the hint in "other information" and a search in a working
database, it looks like it's supposed to be coming from _extensions table,
specifically the "files_joomla" entry:
https://github.com/joomla/joomla-cms/blob/staging/installation/sql/mysql/joomla.sql#L619

The corrupt site is missing it. I'm not sure why yet, but maybe that
should be checked within the database fix (though there's a dependency on
it too).

Kind regards,
Nick

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to joomla-dev-cm...@googlegroups.com. To post to this
> group, send an email to joomla-...@googlegroups.com. Visit this group
> at http://groups.google.com/group/joomla-dev-cms. For more options, visit
> https://groups.google.com/d/optout.
>
>

[Nick Savov]

I ended up finding it with a different ID (perhaps due to a discover
install) and switching the ID to 700 resolved the issue.

Looks like the ID is hard coded into core, so discover install would break
for it:
https://github.com/joomla/joomla-cms/blob/aa211d32e5c6fd5f40927eb1df5a6cc5298151b8/administrator/components/com_installer/models/database.php#L174

Kind regards,
Nick

[Tristan Bailey]

Interesting edge case nick. 

Do you know if the server had updated or changed php or MySQL before the Joomla update some time or you just think the install had sort of corrupted ?

It was a LAMP setup not IIS too ?

Tristan 

---
Tristan Bailey
Freelance web developer
+ analytics and social building

[Nick Savov]

I'm not sure about the server history, but it's a LAMP stack.

Judging by its previous ID (10039) being over 10000, I'm guessing what
happened is that extension was added sometime between 1.6 and 2.5, then a
discover install for the extension was used via
administrator/index.php?option=com_installer&view=discover, thus giving it
the next ID in the discover queue (in this case 10039). I'm not sure
though.

Not sure it's worth reporting as a bug either. I can if anyone else feels
like it should.

Kind regards,
Nick

>>> sql/ joomla.sql#L619

[Bakual]

It's indeed hardcoded to 700 and has to be. We use it in several places through the CMS and I'd expect several things not working correctly if the id is different.

[Nick Savov]

In that case, we could do something like the following for the database fix:

UPDATE `#__extensions` SET `extension_id` = 700 WHERE `name` =
'files_joomla' AND `extension_id` != 700;

If that seems reasonable, I can submit a PR and testing instructions for it.

Kind regards,
Nick

[sovainfo]

Would consider that PR inapropriate and object to it.

Normally this would be considered an incident and with your fix closed as such. With the amount of real bugs reported in this component, suggest to remove it or completely redesign it. It doesn't meet the expectations! Back to the drawing board!

Proper problem management would react when this would have been reported many times, similar to the number of times problems with the #__assets table was reported. Research for the real cause would be done and when found would be fixed. Not the workaround (AssetFix from Elin) would be implemented in Joomla, if possible the cause would be taken away. This assumes there is something wrong in Joomla, yet to be determined, also in this case. In the case of an user mistake (UBF) you could investigate whether this can be avoided.

Can't imagine an administrator (a Super!) discovering and installing a Joomla update in an broken environment that doesn't have an id of 700. In my opinion these are not to be discovered and when they are, that would be a real fix. That still leaves the missing 700, what causes the 700 missing? And a proper fix would insert the 700 instead of updating a very unlikely existing row with a different ID.

Looking forward to the extension of Hannes that will really check whether the version is correct, hopefully he'll extend it to check the database for its definition based on installation/sql/joomla.sql. That would be a proper structure check. A bonus would be further consistancy checks like AssetFix and Rebuilds of the trees in tables (lft,rgt) or even contents

[Bakual]

I wonder how you got that installation to a state where the joomla_files can be discovered. Sounds like a badly broken installation then.

But the fix of course would be an easy one and should work without issues.

> email to joomla-dev-cms+unsubscribe@googlegroups.com. To post to this
> group, send an email to joomla-dev-cms@googlegroups.com. Visit this group