Ryan Ashbrook

This should be fixed now.

Most likely - on their site, the Pro account advertises that they have blocking / challenging of automated traffic. In most cases, this is simply detecting that the request is coming from an IP from a data center and not an actual ISP (I should know, our corporate VPN gets hit by this all. the. time.).

It's likely that Cloudflare is detecting that the IP the request is coming from is from a server / data center, and is blocking it as automated traffic. When the Admin CP tests for these things, it makes an HTTP request to https://example.com/login/ for FURLs, and to https://example.com/api/core/hello for the API.

This would definitely be something server side and / or associated with other software on the server for a few reasons. While we do use a custom session handler, we use the proper session_set_save_handler and related functions, rather than ini_set. The only usage of ini_set throughout the software is during an automatic Admin CP upgrade to disable errors, which is a fairly typical use case - and if it fails, the error is suppressed and ignored. This is the case for both 4.16.12.1 as well as the current version. Based on the error itself, it looks like there may be a configuration issue somewhere in php.ini, or in a .htaccess file that is present on the server, attempting to set that directive (which is incorrect in itself - the directive is session.save_handler instead, though that could be as simple as the server interpreting the dot as an underscore in the error).

@Randy Calvert is correct. This would be a browser issue - most likely because it suspended the contents of the tab, so when put back into focus, it automatically refreshes to get the latest update for the page.

It looks like there was a temporary issue with your license - I have refreshed that, and your databases are back now.

You can also temporarily block those countries from registering under Spam Prevention > GeoLocation Settings.

The default for Action to take for 1/4 has always been Allow user to register as normal. Typically, you would only change that if you going through a spam attack, so yes setting it back to that is recommended.

This should be fixed now.

By default, it's 90 seconds. Then it looks at the max_execution_time PHP configuration and will then use that instead, if it's less than 90 seconds. Then it looks at wait_timeout in MySQL and if it's less than max_execution_time, it uses that instead. Then, it looks at the memory_limit PHP configuration and if it's not unlimited, it takes that into account. Then it will run the task as many times as it can until one of the following happens (in this order): The task indicates it has nothing else to do. If the task is explicitly told to run X amount of times, it will stop when it reaches that amount. If it gets close enough to the timeout that it cannot run another cycle. If it gets close enough to the memory limit that it cannot run another cycle.

No, only MySQL is supported at this time.

You are missing your beginning and end delimiters. Try this: /^(fa(-[0-9a-zA-Z]+)+)( (fa(-[0-9a-zA-Z]+)+)+)*$/i And then set Apply text formatter to Yes, and then set Formatting Option to All lower-case in case someone enters a valid Font Awesome icon class, but uppercase.

To clarify - if a member is in a group with permission to see anonymously online users, if you hover over the status it will state that they are online anonymously.

Working with images, particularly large ones, is actually a pretty intensive process. For instance, if I open Affinity Designer, t immediately uses about 750-800MB of memory, then opening a single 1.6 MB file makes memory usage jump to 1 GB. If the files are going to /tmp then it's likely because ImageMagick is running out of memory available to it so it's forced to use disk instead, which has larger space to work with, but is much slower. It may be worth contacting ImageMagick with your configuration to see if any improvements can be made.