netcarver

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.

@modifiedcontent Not quite your question but in your template, where you are rendering the comments entry form, you can do this instead. This should set up the correct value for the cite field for new entries... <?php echo $page->comments->renderForm([ 'presets' => [ 'cite' => wire()->sanitizer->entities($user->fullname), ], ]); For existing entries, I think you can iterate the comments and then set the cite attribute to the value you want.

Great, thank you @BitPoet Would be good to get the count of deleted keys back from deleteFor() rather than the value of the $force parameter. I've updated my dev fork to return the count of deleted keys.

@BitPoet I've cloned the module and pushed an experimental script for deleteFor() here. It uses a Lua script that's evaluated in the Redis server. My rough testing using 100k namespaced keys shows this to be much faster than iterating over the scan results in PHP and the PHP cpu + network load is also much lower. However, that is at the cost of blocking the Redis server whilst the delete is taking place. I've not massaged this into a pull request yet, as I'd like to get your feedback on it.

Even then, for large cardinalities, the Lua script idea (with or without a hash/set holding the key references) would be blocking on other processes using Redis. So this might not be ideal either. At least with your current implementation it's non-blocking as there are separate calls to redis. However, that needs to be weighed against the network overhead.

Looking forward to the update, @Adam

@BitPoet Fantastic, thank you. I guess you mean the flushing of a namespace regarding the SCAN with DEL/UNLINK operations? Hmm, I wonder if we could keep either a hash or set for all the keys within a namespace, then flushing the namespace could become something like a lua EVAL that iterates the hash/set doing the deletes and then empties the hash/set as one atomic operation without a load of network traffic. Will have a think about it, it's been years since I did any Lua scripting in Redis.

Change to U2F then save the user. When the page reloads, there should be options to set up the key.

@Kiwi Chris Glad you found the solution. That's interesting though - can you post a link to the documentation you found regarding pcntl and apache?

@Kiwi Chris I think it may be the file compiler as it seems to be translating the module so that PHP is looking for pcntl_signal() in the processwire namespace, hence the line from tracy: "ProcessWire\pcntl_signal()". It's also telling you where that line occurs. I've not used Tasker before, but I'm guessing you can edit that line and wherever you see "pcntl_signal()" being called, just prepend it with a backslash "\" character to put it in the global namespace. Doing so may reveal more errors about pcntl functions - but if that's the case, we know we are on the right track and you can do the same to them as they appear.

Hi @Vilunki3000 Welcome to the forums. Did this start with the upgrade? If so, what version of Processwire were you using previously (which version worked for you?)