Hi there,

Thank you for reaching out, and I apologize for any inconvenience caused by this oversight. Initial solution is use the previous version. I will share your issue to our developer team. I hope they will fix it as soon as possible.

Best regards,

Toufiqur Rahman (Team Lead, Support)

HI, Toufiq, thank you, installed 1.8.1 , Settings are damged completely https://prnt.sc/WNAZ9E9PtAxx , https://prnt.sc/ukfH6K1vL9LH .

Orders could be opened but without the possibility to set fulfilled.

Hi Tofiq, sorry for the delay. It seems to work after Cache clean under 1.8.1. Updating to 1.8.2 brings the setings issue again. Is it known?

Hi Toufiq, unfortunately it isn't working on direct way with my hosting. But I made a dump for download.

Hi Toufiq,

The issue is resolved. I did not import the database file you sent — instead I traced (with help of ClaudeCode) the actual root cause in the 1.8.2 code, and the real fix turned out to be a single field.

Root cause (confirmed in 1.8.2 code):

The admin app loads everything through AppConfig::getAppConfig(), which calls CustomInvoiceHelper::backfillLegacyInvoiceIds() unconditionally on every admin view (settings, orders, order detail).

That method casts the general setting customInvoiceIdCustomResetDate with (string):

(string) ($general->customInvoiceIdCustomResetDate ?? '') On my store this field was stored (by an earlier version) as a serialized DateTime object:

"customInvoiceIdCustomResetDate": {"date":"2027-01-01 00:00:00.000000","timezone_type":3,"timezone":"UTC"} Casting a stdClass object to string throws a fatal "Object of class stdClass could not be converted to string". The catch (\Throwable) rolls back and re-throws, so getAppConfig returns HTTP 500 on every load. And because the backfill flag is written after the failing line, it never recovers — the store stays broken on every page load. That is exactly why the settings page and order details would not open. 1.8.1 doesn't have this on-load backfill, which is why downgrading worked.

The same unsafe (string) cast appears in lines 60, 252 and 288 of CustomInvoiceHelper.php.

My fix: I simply set customInvoiceIdCustomResetDate to an empty string in my own general settings row. After that the backfill runs once successfully, sets its flag, and 1.8.2 works perfectly — settings, order details and fulfillment are all fine now.

Two requests for your dev team:

1. Please handle this defensively in the code so existing stores don't break — e.g. coerce/normalize the value to a string (or set the backfill flag) before any (string) cast, and don't let a single legacy value fatal the whole getAppConfig endpoint. A migration that sanitizes customInvoiceIdCustomResetDate on update would fix all affected customers automatically.

2 hidden Thanks for the help — you can close the ticket.

Best regards, Alexander