After last upgrade to 9.03.90 i see some problems on my sites.

Hi,
Check Settings > Security and increase amount of Form Tokens

Please do not hi-jack threads from other people. You now have a dedicated thread.
 

Can help me somebody with my problem?
If i am login like administrator in english language site work perfect.
If i am login like administrator in oher language site work very very hard and i can't save content just after 2-3 try.

Do you see any errors in your error log?
Admin > System Admin > Error log

Yes i have 13581 page with error from begin. Last two page are with error like in image and is repeat at other section like forum, news, etc but all are in theme function includes or locale

How to report an error: https://www.php-fusion.co.uk/infusion...d_id=40236

Thanks RobiNN i know now to report error.
I delete all my error 13595 pages and in 1 hour i have another 112 page with error. I see that some error are repeat every time but how to report all error?
By the way if i delete all error site work very good next 5-6 minutes and after this work hard again, i think that the list of errors hinders the performance of the site.

I put here some from error:
File: theme_functions_include.php
Page: /infusions/forum/index.php?forum_id=1&lang=Romanian&order=descending&sort=reply&time=1month&type=all&viewforum
Line: 962
Error message: Undefined index: timer

File: Locale.inc
Page: /infusions/forum/index.php?forum_id=1&lang=Romanian&order=descending&sort=reply&time=1month&type=all&viewforum
Line: 132
Error message: Undefined offset: 1

File: theme_functions_include.php
Page: /infusions/forum/index.php?forum_id=1&lang=Romanian&order=descending&sort=reply&time=1month&type=all&viewforum
Line: 954
Error message: Undefined index: timer_second

File: theme_functions_include.php
Page: /infusions/forum/index.php?forum_id=1&lang=Romanian&order=descending&sort=reply&time=1month&type=all&viewforum
Line: 953
Error message: Undefined index: timer_minute

File: theme_functions_include.php
Page: /infusions/forum/index.php?forum_id=1&lang=Romanian&order=descending&sort=reply&time=1month&type=all&viewforum
Line: 952
Error message: Undefined index: timer_hour

File: theme_functions_include.php
Page: /infusions/forum/index.php?forum_id=1&lang=Romanian&order=descending&sort=reply&time=1month&type=all&viewforum
Line: 951
Error message: Undefined index: timer_day

File: theme_functions_include.php
Page: /infusions/forum/index.php?forum_id=1&lang=Romanian&order=descending&sort=reply&time=1month&type=all&viewforum
Line: 950
Error message: Undefined index: timer_month

File: theme_functions_include.php
Page: /infusions/forum/index.php?forum_id=1&lang=Romanian&order=descending&sort=reply&time=1month&type=all&viewforum
Line: 949
Error message: Undefined index: timer_year

It's a translation problem. Update it https://www.php-fusion.co.uk/translat...anslations

Thanks very much i think that problem is solved.

Hey, guys! You should definitely take a look at the main problems here:

1. (extremely) excessive logging leads to increasing page load times (danyab's loading times went over 7-8 seconds/page);
2. missing locale should not lead to empty strings in the UI, but simply fall back to English.

The quickest and least invasive approach code-wise (although not optimal) would be to first load the English locale, then the site's locale. Of course the sub-optimal thing about this is doubling the I/O reads for locale. But there would be no errors reported with old locale, no empty strings displayed on the sites, and it would be easy to notice English strings here and there, so the site admins would then update their locale.

In the future, using gettext or similar would be welcome. The advantage of gettext is having the English strings directly in the code (so no I/O penalty), and if it's defined in the site's locale, English will be overridden on a per-string basis. Plurals are also better handled with gettext, considering there are languages with more than 1 plural form. Of course the correct plural forms could also be implemented in the existing locale system, but that's ultimately up to what you decide to do about the i18n system.

The translations could also be versioned/timestamped in the future, so the site owners know when they have an update available without constantly checking the project's website.

By the way, v7 didn't have the issue of excessive logging, but only kept one report per error, so there was no performance impact in cases like this one.

In latest v9 you can disable error logs or you can store them to file.


All translations are always updated with new release of CMS. We use Crowdin. So if string is not translated it uses English version.

It is hard to switch to another localization system like mentioned gettext a.k.a. WP Translate... We have literally thousands of strings, so it will be very challenging.


I agree with that.

Well, gettext is more popular thanks to wp and their implementation. I have no problem switching to another technology.
Tell old community members to use the new localization system. Man, a lot of them hate v9 because we use simple OOP codes (BTW. v9 it's very easy to customize. And no, OOP is not required for new themes and infusions, as many of them think.). Imagine what happens when we switch to another localization system.
I know gettext is much better, but we simply cannot do it. Maybe in v11-12 who know but not now. The best practice is to update the translation immediately after cms upgrade.

v9 is a deep rabbit hole that's way too off-topic for this thread, so I'll avoid it.

gettext is indeed a significant change, but having it done for the core (in v10+) wouldn't limit add-ons from using whatever localization system the developers want. Having missing strings on a live website is way worse than having them in English, even if that requires extra file opens. It's a serious usability issue and even the best practices can bite you in the rear when the locale update takes a few minutes to complete on an active website. Does the CMS update automatically enable the maintenance mode while it's run? That would be a good way to make updates smoother and safer for everyone.

In the future, the core could check if there's an updated locale package, check if the CMS has all the PHP features and file-system rights to update it, and maybe if there's an auto-update option that the site admins enabled, just do it. Sure, only after taking all the precautions, like having the downloaded file hashed and whatever else would be necessary for a successful update.

But the conclusion remains: logging needs to be fixed because anything can cause massive logs: locale, add-ons, etc. And doing something for the locale issue would be nice, especially for usability reasons, because good practices are fine but there will always be inexperienced admins (or new to the CMS) who don't know the best practices. Also, it's generally a good idea not to rely on people to learn and remember good practices when they can easily be automated in the update/upgrade process. It's both safer and more convenient.

Error log is already fixed.

We plan to add automatic updates so maybe translations can be also auto-updated.