netcarver

I generally use this with WiremailSMTP and haven't really tried it with other send methods. Which WireMailer are you using?

Highly recommend Gumroad for selling this. It takes care of all sales tax nightmares and can automatically generate a license key per sale.

Personally I wouldn't try adding license key checking into scriptable code (like PHP) as people who are going to cheat you are just going to edit the code to remove the check anyway, or just have it return true etc.  Where the key can come in useful is for access to value-added features like support, so you ask "What's your license key" as part of the user's access to your support mechanism (forums/email etc)

Sounds like a possible bug in FieldsetPage - can you open an issue for this in the issues repository please.

Hi @rash

You will need the salt from the original config file in order to allow existing users in the DB to log in with their current passwords. However, you can use the Recipe here for resetting an admin account password: https://processwire-recipes.com/recipes/resetting-admin-password-via-api/ That should, at least, let you log in as admin and use the interface.

You might also try installing the ForgotPassword module in order to let other users reset their passwords.

You're right that this is by design and is not best practice. I actually don't know there is any proper way of doing this, but my first port of call would be to try hooking the session::loginFailure() method and then looking at the reason argument.

Check out wire/core/session.php and look at the code in login() and the ___loginFailure() hook.

Yes, a long time ago. There are probably better options out there (services) and I think there is another module - though I have never used it: https://github.com/andreadewey/ShortLinkGenerator

@kater Hi there, could you try disabling the Nifty module (just disagree with the license) just to see if that has any bearing on the situation. If it does, you can get support in the VIP forum for NiftyPasswordPlus. If it doesn't we will have eliminated part of the complexity around what could be causing this.

Hi @CachePuzzles, welcome to the forum.

That's way more time than it should take. Are you using one of the WireMail series of modules for your emails? If so, which one?

I've used WireMailSMTP in the past to send via my own email provider's SMTP server and it works very well (although SMTP can be difficult to setup,) usually taking less than 10 seconds for email to arrive in my inbox sending that way.

There are also WireMail modules for SendGrid, Mailgun, Mandrill, Swift, PHPMailer and Amazon SES to name a few. You can lookup more wiremail modules here.

If anyone's looking for a shortcut to simplified/extended password reset features, there is a commercial extension module available.

@Confluent Design Nothing amazing I'm afraid, you'll have to edit the included CSS file (InputfieldStreetAddress.css) - or override the selectors it uses with your own in another CSS file that gets loaded later.

Update: Found out why LazyCron stops working sometimes. Have added an issue for the fix here.  If you are using PHP7 or above, you can improve the reliability of LazyCron by wrapping your hook in a try {} catch (\Throwable $e) {} block. (Note the catch - it's a \Throwable, not an \Exception, so it catches errors as well as exceptions.)

If I needed that spec, cheaply (ie. self-managed), I'd consider Contabo's cheapest plan at ~Euro5/month + tax.

Otherwise I've never had trouble with Digital Ocean's droplets or Hetzner's VPSs but the prices are much higher for that spec (US$40/month + tax on DO and ~Euro15/month for Hetzner + tax.)

You didn't mention your bandwidth requirements so you'd also need to look at what's included in those plans and budget accordingly.

@Marco Ro Can you expand on what you need from your hosting?  Are you looking for something managed, self-managed, shared or what?

Do you need to be in a data-center in a specific region?
 

There is a module that does something a bit like this already.

@PWaddict Which log file did you spot that in?

Also, you can try the ProcessDiagnostics module as it has a DB helper that can run table repairs. You should always back up the DB first though before any operations like that.

This sounds like an API bug, is it worth reporting this as an issue as well?

@ryan Not sure if small requests count here in this storm of idea goodness.

Please could you make ProcessLogger::formatLogText() hookable?

If you think you've found a bug in WireDatabasePDO, please do open an issue for it in the processwire-issues repository.

You'd know if your processes were forking as you'd be doing it yourself, or running software like php-resque that does it for you, so what I described above probably isn't the cause in your case.

@monollonom If you are using ProcessWire's database (ie $this->database, wire('database') or wire()->database depending on context) then yes, it should connect again on the next query.

What might be more interesting is trying to find out why the MySQL server is going away. Do you have any processes (like your API stuff) that are forking by any chance? If this is the case, the code in the forked process gets a copy of the parent state - including the pdo driver state - and when the child process uses that state to access MySQL, the DB server can close the connection, leading to "2006 MySQL server has gone away" for both the child and the parent processes.

I discovered this running PW-bootstrapped code from forked PHP processes in some of my own installations where I have background workers processing various jobs.

I do not know for sure why MySQL closes the connection, but my working hypothesis is that it closes it when it sees it being accessed from a different process ID. The cure, however, is fairly easy in these cases as you just make sure the first thing your forked code/background worker does is close the db connection - forcing the child process to create a new connection on the next database call which it then uses for the remainder of its operation, and leaving the parent process' connection intact and operational as well. Taking this action in my forked code totally cleared up these "2006" errors for me.

@muzzer Nice find, thanks for posting about it. Please could you add an issue to the issues repo for this.

Works fine on 3.0.148 - thank you!

Hi @Adam I upgraded a live site to the new version and, unfortunately, the update causes a 500 internal server error on PW 3.0.148. I suspect you might need to add a PW version check before calling the parent init() function.  I've verified that it's the changed line by commenting it out and the module then functions properly again.

Merry Christmas everyone.

Version 2.0.0 released. This has updated the Processwire version constraints.