adrian

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.

Have you had a look at alpinejs - a good option if you are already familiar with Vue

@Kola - glad you figured it all out ? The key thing here is that it's not really the ASMSelect inputfield, but rather the Page Reference fieldtype that's behind it - because you have that set to store multiple values you need to use the add() method. Same would go for checkboxes etc.

@gmclelland - looks like you have upgraded from a very old version of Tracy - just go to the module settings page and save it and the error will be gone.

I did mention that above ?

I've had issues with MySQL passwords with special characters before. I hadn't thought about which character was causing the problem, but I agree with @horst that the $ is the likely problem.

@digitex - I agree that there are still some big issues with this. Setting widths to use percentage-based widths in the Uikit theme settings seems to help with many of the issues, but definitely not all. Have you seen this mammoth issue thread: https://github.com/processwire/processwire-issues/issues/480 (linked above by Robin). The default admin theme definitely works better than Uikit on this front.

Hi all, I just added the ability to restrict access to custom FieldsetTabs which makes it easier to block certain user roles from having edit access to entire sets of fields (in the selected tabs). I also added a new "Exempt Roles" setting that makes it easy to make sure certain roles are not affected by this module - particularly useful if you use the "View" permissions approach.

This works for me: $store->getUnformatted('products');

Yeah, that version is 3 years old ?