Ryan Ashbrook

This should be fixed now.

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.).

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).

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.

Finally, one of the most requested features for clubs in Invision Community is coming with our March 2024 release: Pages databases in Clubs.
You may be surprised to see a new feature being introduced for Invision Community 4 during our flow of news for Invision Community 5, but as we're committed to Invision Community 4, we wanted to continue to bring optimizations and improvements to the platform.
What is the benefit of this new feature?
Clubs enable communities to host multiple micro-communities with many benefits. Clubs allow more specialized and focused discussions on specific topics. This can lead to higher-quality content and a deeper exploration of niche subjects that may get overlooked when posted on a busy forum. Clubs also offer the ability to tailor the community experience based on the needs of that community. That customization is what this feature focuses on.
Pages is a powerful application that allows truly custom layouts for content areas. Simply by adjusting templates, you can create a news feed layout (it is what we use for this news blog area!) or something even more customized to your needs.
The March 2024 release allows you to create Pages database categories directly inside clubs, including custom fields and templates.
How does it work?
Setting up your Pages database to allow clubs to use categories is simple. Simply allow categories to be created within clubs when creating or editing a database.

Once that is done, club owners can add a Pages database category to their club in the same way they can add topics, galleries, etc.

Once the Pages database category has been added, you can then add content as you would any other club area with the added features of Pages, including custom templates and custom fields.
This example club uses a custom Pages database listing template to show the articles in a custom format along with custom field data.

Likewise, viewing an article in this example club showcases the use of custom templates to present the content differently from the standard topic templates Invision Community uses elsewhere.

Allowing Pages database categories inside clubs brings the opportunity for more complex custom areas making use of multiple custom fields along with truly custom layouts using templates. This is a great way to bring additional areas, such as news articles, into your club areas to compliment discussions.
We hope you enjoy this feature, and if you have any comments, please leave them below!

View full blog entry

That’s a somewhat dishonest approach. You suggest that the claim “not even good for seo” is proven by the links that the Google search would reveal, yet I checked the best results and they say NOTHING of the sort. The query doesn’t address “seo” in any way and so the results also don’t. They discuss the possibility of having emojis in URLs and agree that they are possible. 

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.

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.

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.

Whether someone is paid or not, they are still representing your “company” so I would still suggest vetting that individual and formalizing the relationship to a degree. If little things like this are making you think twice on someone, it’s likely for the better you don’t make them a moderator. Or vice versa, if you as an admin are having second thoughts relinquishing control over small things like this, are you ready for/need staff or can you get by with the bare minimum? There are a lot more critical details staff will need access to as you grow so plan how that gets attributed/promoted too.
I don’t think many people know this but many of the IC staff became staff through having communities of our own. So I don’t mean to say these things from a “I know better” place but we do have real world experience, yet are happy to be proven wrong or if there are other scenarios.
I typically don’t have a “contract” for my community staff but a do/don’t list, minimum tenure before becoming staff, quick questionnaire wouldn’t be unheard of, training steps starting them out, etc… all a good time for you to vet them further or for them to opt out 😉 .

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.

I believe key is a reserved keyword in MySQL. Try this.
\IPS\Db::i()->delete( 'core_tasks', array ('`key`=? AND app=?','steamCleanup','steam') )  

Ah, yes. I encountered that same issue recently on a client's site using my Moods application. Adding backticks solved it.
I didn't think of that because without backticks the query threw a specific error about having a wrong LIMIT value, and you didn't mention anything like that. 😅

I believe key is a reserved keyword in MySQL. Try this.
\IPS\Db::i()->delete( 'core_tasks', array ('`key`=? AND app=?','steamCleanup','steam') )  

Yes, in your Admin CP > Community > Calendars, edit the calendar and set "Events must be approved?" to Yes.