Which version of OSMap did you have before you have updated it? As far as I know version 5.0.0 of OSMap just has been released, and that’s the first version which is compatible with Joomla 4. If you had a version 4.x of OSMap on Joomla 4, then that version was not compatible and it’s Update might have failed, and if it was a 5.0.0 release candidate, then updating that to the final 5.0.0 is not possible, at least that‘s what their support told me when I had contact with them for another issue in the last days.

Have you reported this issue to their support, too? Or have you reported it only here?

The previous version of OSMap was 4.something, but I had no problems after upgrading to Joomla 4.0 with disabled OSMap,
and no problems either when enabling it.

And as far as I can remember when updating, OSMap was marked only to have no update version available and not be listed as Incompatible / "Must be upgraded"

The upgdate to version 5.0.0 seems to be worked fine, the Extension is listed as Version 5.0.0 in under Manage Extentions

But I will try if I can reinstall it, to just be sure.

which doesn't work in current state (reupload)

But I will try if I can reinstall it, to just be sure.

@jiweigert That could be worth a try, at least to see if it helps. On the other hand I don’t really see how OSMap should cause such a problem, no js and css loaded at all. Do you have some extension like e.g. JCH Optimize installed, which combines js and css for „optimization“? If yes: can you switch these optimizations off to see if that changes something?

which doesn't work in current state (reupload)

Do you have a backup?

That is the next thing I'll try,
there should be a file & data backup from this morning 1-2am..

Richard Fath @.***> schrieb am Di., 12. Okt. 2021,
20:07:

which doesn't work in current state (reupload)

Do you have a backup?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#35812 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQNZU55URSIBBO3QKDCDVZTUGR2M3ANCNFSM5F3AZYDQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@jiweigert Does it help if you disable the ossystem plugin with following SQL command in phpMyAdmin (or similar tool), assuming ' xhr_' is your table prefix?

UPDATE `xhr_extensions` SET `enabled`=0 WHERE `type`='plugin' AND `element`='ossystem' AND `folder`='system';

@richard67 There is a easier method - rename `/plugins/system/osmap/' folder.

@richard67 There is a easier method - rename `/plugins/system/osmap/' folder.

Yes, that’s right.

I will try to restore the backup first.

Im on mobile now,
may I ask you to check www.swedishsoul.com for the actual error Code when
trying to access the js files?

That would be great

Richard Fath @.***> schrieb am Di., 12. Okt. 2021,
20:15:

@jiweigert https://github.com/jiweigert Does it help if you disable the
ossystem plugin with following SQL command in phpMyAdmin (or similar tool),
assuming ' xhr_' is your table prefix?

UPDATE xhr_extensions SET enabled=0 WHERE type='plugin' AND element='ossystem' AND folder='system';

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#35812 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQNZU53XBN7XRQVXKSC3RWTUGR3MNANCNFSM5F3AZYDQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Try remove from .htacces this part

I just wanted to suggest the same. I don't really get an error status code, just got a "failed to load" in the browser's network tool.

@richard67 When accessing any js or4 css directly I get "Content encoding error" - error message translated.

When accessing any js or4 css directly I get "Content encoding error" - error message translated.

@wojsmol Yes, me too.

@jiweigert The problem is indeed that the server compresses js (which can be seen by the "content-encoding" header value "br", which means brotli algorithm), and the .htaccess directive above means to use gzipped files. Both together doesn't work. You can either do as suggested above by @wojsmol , then you will continue to use compression at run time, or you switch off that server compression and use the gzipped files with the .htaccess directive mentioned above, which could be slightly better for performance.

Hmm, currently I'm back to Stage one means that i've a somehow working
backend and website. (Joomla 3 / beez3 template)

I don't know, why this brotli compression is used, but what I really wonder
is why I could successfully update to Joomla 4,
do some deinstallation of plugins/extensions and only after having today
this OSMap-update that produce this crazy error..

I mean, I worked on sunday several hours in the backend and checked the
frontend frequently.
And if that problem (brotli vs. gzip compression) had exist then, I would
had the problems then, but not now...

Thanks for now, I'll investigate into where the brotli compress setting
originate from and change it to zip-compression, as it should be this
anyway.

The isuue can be closed for now and thank you Richard and Wojciech for your
help!

Am Di., 12. Okt. 2021 um 20:42 Uhr schrieb Richard Fath <
@.***>:

When accessing any js or4 css directly I get "Content encoding error" -
error message translated.

@wojsmol https://github.com/wojsmol Yes, me too.

@jiweigert https://github.com/jiweigert The problem is indeed that the
server compresses js (which can be seen by the content-encoding header has
value "br", which means brotli algorithm), and the .htaccess directive
above means to use gzipped files. Both together doesn't work. You can
either do as suggested above by @wojsmol https://github.com/wojsmol ,
then you will continue to use compression at run time, or you switch off
that server compression and use the gzipped files with the .htaccess
directive mentioned above, which could be slightly better for performance.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#35812 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQNZU53QF5KAH4M6SREKFYTUGR6TBANCNFSM5F3AZYDQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Closing issue as stated above. I also have no idea how it could have been caused by updating OSMap.

Hello Richard @richard67 , is there any list of hardcoded id's / keys in the installer scripts?

Because, whatever I do, I still get JInstaller like: Duplicate_Content(KEY) (something like that) after update
and when I try a reinstall of joomla 4 No field like system.field_list

And yes I stripped the 3.10-system down to the baare minimum..

Thats why I'm asking above question... Are there hardcoded id's because of assuming that nobody has to change something, like system plugins/modules?

It would be nice, if you could react to that.

Thanks!

@jiweigert If you restore a backup of Joomla 3.10 from before the update to 4, you have to restore it into an empty database. When using Akeeba to make and restore the backups, the backup has to be restored with use of kickstart.

See section "I cannot restore a Joomla 3 backup on top of Joomla 4; the site is broken." here: https://www.akeeba.com/news/1748-joomla-3-10-and-4-0-common-issues.html .

Alternatively you can try to clean up your database using the SQL statements in the description of this issue: #35664 .

Well, as of description of the providers provided backup-function (which I use), It restores by replacing the original database with the backup version and I carefully selected the filesystem of the same day to be consistent on both db and file-system.

Which sound to me as the way you recommend for the db.
And the backup I use, is old enough to not be in a maybe mixed state (over a week old).

I do not use Akeeba-Backup.

But you haven't asked the question, if there are hardcoded (unique) ID/keys hardcoded in the Installer- / Update-scripts you are aware of, which interfere with the existing ones in my db.

As long as you don't tell me the precise error message (which contains the table name) but only provide things like "JInstaller like: Duplicate_Content(KEY) (something like that)", how shall I know?

One candidate for duplicate keys is this update script: https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/components/com_admin/sql/updates/mysql/4.0.0-2018-05-15.sql .. but if you get a duplicate key there then it means you have had Joomla 4 tables left from previous update trials in your Joomla 3, and that would mean your database was not clean.

I only can say again: Try the SQL provided in that issue ##35664 .

Youre right, well then I will run through this anoying process of deleting plugins / extensions etc again, to reproduce it.

For me, it looked like a non-specific error, there was no tablename mentioned on the first error, that I'm aware of.

Hello Richard, In the screenshots below you see the specific error, sorry to be that vague before.

I activated the Debug mode, to have a trace stack, maybe that help you.

Hello Richard, In the screenshots below you see the specific error, sorry to be that vague before.

I activated the Debug mode, to have a trace stack, maybe that help you.

@jiweigert No, the stack trace doesn't help me much. I only can say again that it is caused by your 3.10 installation still containing some data from trying to update to 4.0 before which should not be there, e.g. workflow tables. I linked to an issue in which's description you can find SQL statements to clean that up, or if you don't want to use them you see there at least which tables you can check if they exist. But up to now you refused to do that.

If you are testing this on a local environment then you should have even access to the log files of your database server and there you could easily see which SQL statement fails.

You also can see in the update log "administrator/logs/joomla_update.php" which SQL statement was the last successfully executed statement at the first attempt to update 3.10 to 4. The next one in the sequence of update SQL scripts would then be the one which has failed.

If you post that log here I can have a look if you don't find it our yourself.

But please stop to be so demanding to me. I am only a normal contributor and maintainer, and I do that in my spare time beside my full day job.

If you think that it is wrong that I have closed your issue, then feel free to re-open it.

this really is an issue for the forum

Sorry Richard, that i sound demanding, that is not my intention.

I do not run or have created any workflows

I have no local test environment, to look for such logs besides whats written into the file system, all I can do is todo a test run of the update again and see if I can catch something in the logs, the provider may offers to me..

If youre ok with that we can still let this issue closed, but if you feel it should be reopened im ok with that too.

I do not run or have created any workflows

@jiweigert This is absolutely irrelevant. On update from 3.10 to 4, new tables for the workflows are created, regardless if you use them or not. If such tables exist after you have restored your backup from before the update, then your backup is not clean.

Ahhh! ok, now I've understood your point. I'll check if those tables exist
and run those delete statements.

Just to be sure, they will not affect a running (restored) 3.10.x system
right?

Richard Fath @.***> schrieb am Sa., 16. Okt. 2021,
19:05:

I do not run or have created any workflows

@jiweigert https://github.com/jiweigert This is absolutely irrelevant.
On update from 3.10 to 4, new tables for the workflows are created,
regardless if you use them or not. If such tables exist after you have
restored your backup from before the update, then your backup is not clean.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#35812 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQNZU55TX4FZHLO4HHJWNPLUHGWFNANCNFSM5F3AZYDQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Just to be sure, they will not affect a running (restored) 3.10.x system right?

@jiweigert No, it will only remove stuff added when updating to Joomla 4.

You can copy the SQL code in the description of #35664 and replace #__ with your database prefix and run that in phpMyAdmin. For your convenience I've copied that to here. If you move the mouse above the code you will see a "Copy" button at the top right corner of the code box so you can easily copy that code, paste it into phpMyAdmin's SQL window, replace the database prefix and run it.

# Installer: :Installer: Found SQL Duplicate entry '1' for key 'Primary'
DROP TABLE IF EXISTS `#__workflows`;
DROP TABLE IF EXISTS `#__workflow_associations`;
DROP TABLE IF EXISTS `#__workflow_stages`;
DROP TABLE IF EXISTS `#__workflow_transitions`;
DROP TABLE IF EXISTS `#__template_overrides`;
DROP TABLE IF EXISTS `#__finder_links_terms`;
DROP TABLE IF EXISTS `#__finder_logging`;
DROP TABLE IF EXISTS `#__finder_terms_common`;
DROP TABLE IF EXISTS `#__webauthn_credentials`;

# Installer: :Install: Error SQL Duplicate entry 'com_config.test_mail-' for key 'PRIMARY'
DELETE FROM `#__mail_templates` WHERE template_id = 'com_config.test_mail';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_contact.mail';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_contact.mail.copy';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.massmail.mail';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.password_reset';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.reminder';
DELETE FROM `#__mail_templates` WHERE template_id = 'plg_system_updatenotification.mail';
DELETE FROM `#__mail_templates` WHERE template_id = 'plg_user_joomla.mail';

DELETE FROM `#__mail_templates` WHERE template_id = 'com_actionlogs.notification';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_privacy.userdataexport';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_privacy.notification.export';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_privacy.notification.remove';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_privacy.notification.admin.export';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_privacy.notification.admin.remove';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.user.admin_activation';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.user.admin_activation_w_pw';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.user.self_activation';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.user.self_activation_w_pw';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.user.registration_mail';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.user.registration_mail_w_pw';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.admin.new_notification';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.user.admin_activated';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_users.registration.admin.verification_request';
DELETE FROM `#__mail_templates` WHERE template_id = 'plg_system_privacyconsent.request.reminder';
DELETE FROM `#__mail_templates` WHERE template_id = 'com_messages.new_message';

# Installer: :Install: Error SQL Table 'j_history' already exists
DROP TABLE IF EXISTS `#__history`;

# Installer: :Install: Error SQL Duplicate column name 'extension'
ALTER TABLE `#__mail_templates` DROP `extension`;

WTF... Those tables were present..
Be 100% sure I selected everytime "Replace Database" when restoring the backup.

Ok, so far the site is still running.

If that replace/restore of the db hasn't worked, I fear, the fs backup havent worked as described too,
Are there specific folders which are unique to a 4.0 installation which I can clean up too?

Thanks so far Richard for your help. :-)

@jiweigert A list of folder can be found in section "I cannot restore a Joomla 3 backup on top of Joomla 4; the site is broken." here: https://www.akeeba.com/news/1748-joomla-3-10-and-4-0-common-issues.html . Even if you don't use Akeeba but you can read it. I had posted that information already in my comment above #35812 (comment) . If you remove these folders before restoring the backup, the restored backup should be clean.

If you want to remove only the Joomla 4 folders after having restored the backup: Why don't you simply download the full installation package for Joomla 3.10.2 and the one for Joomla 4.0.3, unpack them into 2 folders and then compare them using a good comparison tool line Beyond Compare, Araxis Merge, Total Commander or whatever people have to compare folder structures?

Thank you for the tips, I alread have read the linked document.
I used Total commander to check if there are amy dirs from 4.0, and at least the fs-backup function seems to have worked as intended. Yay!

Thank you so much for your help and more, patience. :-)

I just have to figure out, why, even deinstalling all custom plugins/ extentions and templates/frameworks, this mess could happen...

Have a great day!