Marc Stridgen

Please do disable those first of all. Of course we have had updates, and no doubt they will have had at times too. It only takes 1 incompatibility to cause issues, no matter how long you have had them

You would be best to post up exactly what you would like to see within the feedback area, if you are looking for additions to how this is managed 🙂 

There is no specific link you can use that will take you to the last item that has been featured, unfortunately

Hmmm - actually, this looks like it could be reproducible without strict mode involved...
Ignore that - it's only reproducible with strict mode enabled on mySQL

For the guest group, the g_mod_post_unit evaluates to NULL in applications\core\extensions\core\GroupForm\Content.php because it's not present on the form:
if( $group->g_id != \IPS\Settings::i()->guest_group ){ $form->add( new \IPS\Helpers\Form\Custom( 'g_mod_post_unit'...... ...but the Save function doesn't take that into account:
/* Mod Queue */ $group->g_mod_post_unit = isset( $values['g_mod_post_unit'][2] ) ? 0 : $values['g_mod_post_unit'][0]; Not an issue if not using strict mode.

I'm blaming Friday. It is Friday, right?

I think Mark was thinking of PHP 8.2 when he replied. Anyway, while IPS has started recommending 8.1 with 4.7.15, there's no hurry to upgrade just now. 🙂
 
You can take your time and figure out the issue.

Would setting that category back to store comments in the DB rather than forums at least allow people to comment again?

Yes.
Or just set that field in the database to 0 for all your records, and run the task again (obviously, take a proper backup)

You should be using 8 rather than 8.1

Im not seeing your site in mid upgrade there. Did you manage to resolve this one, John?

The blurb is:
Correct - it does suggest it will rebult the topic content.
Your reading of the second sentence, however...
It won't recreate missing topics - as far as it is concerned, as a result of a topic previously being created it now has a record of that topic's ID and the rebuild would rebuild the content IN THAT TOPIC.
Let's say you change the "topic display format" for some of the database fields...run the task, it rebuilds the content in the topic that exists already.
Let's say you don't have the setting enabled for a database...you have a load of records, you decided that you want to have topics too. You enable the setting, run the task, it builds the topics because none exist already.
But once the task is run....you have a topic ID. Delete that topic somehow...it won't be recreated.
The field that contains the topic id for a database is the "record_topicid"

Verified to be working as expected
Thanks

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.

I have hidden that guide, as that is out of date

We only list essential cookies on the cookie page, the 'theme' cookie is not essential for the operation of the site.

In all honesty, if you have to ask that question, I would very much advise not doing this yourself. 

This issue has been resolved in the recently released 4.7.15 version. Please update your site if you are still experiencing the issue, and let us know if you see any reoccurrence.

Live topics is something already available to customers on our Creator plan and above. 
We agree 🙂 

In all honesty, if you have to ask that question, I would very much advise not doing this yourself. 

This issue has been resolved in the recently released 4.7.15 version. Please update your site if you are still experiencing the issue, and let us know if you see any reoccurrence.

It just means that you will have to update your MySQL Database at some point.
PHP versions and MySQL are two different parts to your server. You have highlighted your PHP version, it's your Database (bottom left of the picture) which is the issue here.
If you cannot update your server yourself, ask your hosting company if they will upgrade your MySQL version.

This not helped Problem reacting Content, than my all Browsers recognized my SSL Certificate then I ve bought today. I had always Connecting Errors - not secure connecting. You saved my life. Thanks so much, why I am not good technical.

Aha. 
Confused by the message from my host. 
I thought I had to set it up.
I'll contact my ISP.
Regards
Richard 

There's not a one size fits all answer. Drive Fsync speed, available ram, database size, other programs, MySQL (or MariaDB) version, number of CPU cores, if Query cache is available what the cache's fragmentation rate is, whether full ACID compliance is needed or if they can live with a second or so of loss if a crash occurs, and so many more variables.
There are many items that need to be tested, and benchmarked to do it properly.  I don't suggest tools like mysqltuner  -  it will often give very bad advice and I've seen outrageous settings it recommended that people used which hurt performance.  Its okay for getting an idea of a few basic stats.
 
 
 
 

This issue has been resolved in the recently released 4.7.15 version. Please update your site if you are still experiencing the issue, and let us know if you see any reoccurrence.