adrian

Is it a publicly available module? If so, it would be good to know which one.

How can you move on at the moment - I thought your sites were still broken?

Local dev is 161 (actually just updated to today's commits). At the moment, the live sites vary between 156 and 160.

What I can't fathom is that you uninstalled Tracy and it's still a problem. It suggests to me that it's not Tracy related. I am running the latest version on several different sites and different servers without any problems. This sounds like the likely issue - I know you said you put the old versions of the templates back and they are still broken, but with Tracy uninstalled and its folder removed, it can't be impacting things anymore. Any chance you accidentally messed with the htaccess file?

I've replied on your other post about this - please try to keep things in one place ?

Hi @gornycreative - sorry you're have a rough time with this. Did you properly uninstall 4.21.19, or did you just remove the files? I know you said you aren't getting any errors, but are you talking about PHP errors only? Does the browser dev console show any JS errors? What about errors in the apache logs? Have you done a modules refresh and clear session & cookies from the Processwire Info panel in Tracy? Do the sites work in a different browser / incognito window?

Sorry, that is the new page I created and saved before running the above.

Is it only when using field templates, or is the trimming happening on a textarea field and as such would happen even if you output it directly? If so, take a look at this issue (https://github.com/processwire/processwire-issues/issues/459) and the noTrim option.

Not certain, but it sounds like it hasn't made it in yet - sorry, I forgot that feature wasn't in yet.

You create the user and then follow the instructions in this post https://processwire.com/blog/posts/pw-3.0.159/ which explains how to force the user to set up 2FA themselves.

That is how the PW is supposed to work already - just unfortunately with the new(ish) uikit theme, it doesn't always work as expected: https://github.com/processwire/processwire-issues/issues/480 The percentage based option may or may not fix it for you.

Hi @AndZyk - please try the latest version just committed.

In my humble opinion, that module is too broken to use and hasn't seen any updates since 2017 ? Either use the new Pro version, or code something from scratch yourself.

Hi @MoritzLost - what version of Tracy are you running? Trying to figure out what is on line 409 as highlighted in the call stack. It doesn't seem to me like it's the latest version, but I could be wrong. What changed that started the error? Did you update something?

Hi @maddmac - no, there isn't a lost password option. I'm not sure what it would take to implement the PW core version into this. I am super busy with client work for the next month so can't really tackle this at the moment I'm afraid. If you feel like having a go, I am happy for PRs ?

Honestly not sure - maybe the permissions on that file got messed up? I expect it was something locally specific.

Thanks @teppo - I actually noticed there was a new version the other day and used the PW Upgrades module to update, but for some reason it's not actually updating the module (I just tried again) - I assumed it had worked. Anyway, I manually updated to 2.1.0 and you're correct of course - it seems like they have been fixed.

Actually, I think it needs to be: $this->destroyLogins($this->wire('user')->id); because I am getting this error: HP Notice: Object of class ProcessWire\User could not be converted to int in /var/www/html/site/assets/cache/FileCompiler/site/modules/LoginPersist/LoginPersist.module:400

Also a bug: $this->destroyLogins($user); needs to be: $this->destroyLogins($this->wire('user'));

Looks like @ryan just upgraded the modules site from PW 2.x to 3 and that has caused something to break. I no longer have access to the admin so I can't see what the cause of the error is, but hopefully he'll read this ?

This is the version I am experiencing the issues with. I actually assumed (wrongly now that I look at that Maria page) that I was running a version that was compatible with MySQL8. Maybe the issues I've been having are not specific to "8" but rather default settings that come with MariaDB that don't come with MySQL? Not sure at this point. The main issues that have shown up are cases where PW was not setting the value for the table's sort field or other similar instances where a value is required. Maybe it's even just the way Maria throws errors - maybe it throws errors where MySQL doesn't bother. Really not sure without spending more time which I don't have at the moment - sorry!

@MoritzLost I am running: MySQL Server: 5.5.5-10.3.22-MariaDB-0+deb10u1 This is the default version with Debian these days, although the reported numbers for these are always a bit confusing - I have no idea why there is 5.5.5 before the 10.3.22. Honestly I think hosts should be upgrading - these versions of MySQL have been the stable release for a couple of years now - I think Ryan is lagging behind on this so having hosts upgrade might prompt him to also upgrade his environment.

@michelangelo - the AdminActions module also has an action for this:

@Craig - thanks for your work on this. If a cronjob is run it throws this error: PHP Notice: Undefined index: HTTP_USER_AGENT Would you mind disabling this module when called via the CLI, eg. PHP_SAPI !== 'cli' Thanks!

There have actually been quite a lot of issues. Ryan has fixed several of them, but there are still some outstanding issues and I expect more will continue to surface and AFAIK Ryan still hasn't upgraded his dev environment so he's not seeing them and not being able to replicate so there has been some guesswork and back and forward with me on them. That said, I do have several sites running on MySQL 8 / MariaDB 10 so I am reporting new things as they come up. Not ideal, but hopefully they'll all be sorted sooner than later. However if I were you, I wouldn't upgrade yet.