siwhyatt

I had the same issue. I had to deactivate “loco translate” and “translatepress” to access the editor or customiser. Not ideal! Seems to be related to: Function _load_textdomain_just_in_time was called incorrectly – This is being called by Astra, Spectra, Spectra Pro. Please sort ASAP. Thanks

I also have this issue.

Can you please clarify what action needs to be taken, if any, aside from update to the latest version of the plugin?

Forgot to mark resolved.

Thanks. I’ve updated to the new release and all seems to be working fine.

Thanks again for your replies. I had already tried those to no effect, though thankfully I have now found the solution.

It was the Linux ACL (Access control lists) settings which were too restrictive.

I’ve recursively run a setfacl on the uploads directory and subdirectories and the issue appears to be sorted.

Thanks for your reply. So I did a test by creating a plugin that just created a test file within a folder inside the uploads folder. This was also created without read permissions. So it does appear that the problem is not limited to the litespeed plugin but related to the wordpress installation / server in general.

I do still need a fix however, so any suggestions welcome!

Thanks for the replies. All parent folder and all other file permissions are correct. It’s only newly generated files created by the litespeed cache plugin that lack the read permissions. Other plugins create files with the correct normal permissions. The umask setting of the wordpress directories is 022, the recommended setting and the same as all the other wordpress sites that don’t have the issue.

Hi James,

Thanks for your reply, but it seems that you haven’t read/understood the issue properly.

I know what the file permissions are supposed to be.

My temporary fix is a script running on Cron correcting the permissions each time new files are generated by plugins.

What I need however, is to discover why plugins are generating the files with the wrong permissions in the first place.

The plugin also causes a fatal error on my website since the latest update. I’m currently on holiday so have simply had to deactivate. I won’t have access to a computer until I return in 2 weeks to properly debug for potential conflicts with other plugins. Running Astra Pro theme.

So it’s been one month since I opened the ticket on translating the “Sort by” dropdown, and still no resolution! This is exremely frustrating.

TBH of the 3 issues that’s the least of my concerns.

Having all events appear in the feed and the option to fully translate the plugin would be of higher priority.

@chouby A bit late maybe, but I just sent you a copy of the site health info. It’s a dev site currently under construction hence all the deactivated plugins, though has good health and no other issues aside from the critical error caused by the update.

OK, so this morning I’m again unable to access the WordPress dashboard.

This is with an older version of the plugin installed. Clearly something very strange going on here.

@chouby Is a permanent fix being worked on?

Hi @chouby thanks for your reply.

I don’t know how or why this error occurred, but the fact that it’s happened to so many people at the same time rules out human error.

As with the other people in this thread, website was working fine when I last logged in, today couldn’t access the dashboard. After manually disabling plugins one by one I found Polylang was the culprit. I deleted the plugin and uploaded an older version and problem solved.

I’ve deactivated automatic updates and will wait for a debugged version.

Thanks

I have the same issue @chouby – the update was done automatically via WordPress Automatic Updates, nothing to do with incorrect process.