TheLlamaman

Thanks that fixed it. For some reason I had some slightly different entries in my constant.php, e.g. \define( 'REBUILD_NORMAL', '1000' ); I replaced this with what you suggested and was able to continue with the upgrade.

Are there instructions on how to update an existing v4 test installation to a v5?

+1 for this. I have recently had some posts on my Invision community with attached .avif images. It would be great if they could be fully supported by Invision community.

On my Invision Community, I use the Events feature extensively. There is an annoying 'bug' on the "Overview" page of the events section. On this page the events are shown in order that they occur that month. When you have an event which repeats multiple times that month, the next occurrence of the event is shown in the correct position relative to the current date. However the date label shows only the first time the event occurs that month. See my screenshot below for an example. The event which I have highlighted with an arrow repeats on 07 Mar, 14 Mar, 21 Mar, 28 Mar that month. The position of the event is correct, because today is 18 Mar and the next occurrence happens on 21th (so its correctly positioned between the events on 20 Mar and 22 Mar). But the label will always say 07 March, which is only the first time it occurred. To an end-user, it looks like the event is out-of-order and there's no indication that the event has repeat dates. A more useful output to the end user would be to either: Make the date label match the position by showing the next date instead of the first one. Make the date label show that the first occurrence of the event was 07 Mar but and repeats. Hope that makes sense! In my screenshot below I show two examples. The event on 6th March shows

This happens with my community too. I am using Amazon SES. Some people, probably out of laziness or lack of awareness, mark their notification emails (event new private message ones) as spam which ends up hurting reputation. I have a suppression list setup on the SES side to prevent sending of emails in the future to the offending email address, however it does not stop the reputation being damaged in the first place. A list-unsubscribe in the email would absolutely help here.

Hi, I recently had a user request to delete their account via the Deletion Requests form. I approved this. However, it has created some background tasks which are erroring and blocking other background tasks from running. I have attached a screenshot to show this. The blocking tasks are named "Merging <deleted user> posts". This is the error log from the failing task. TypeError: IPS\forums\_Forum::setLastComment(): Argument #2 ($updatedItem) must be of type ?IPS\Content\Item, IPS\forums\Topic\ArchivedPost given, called in /var/www/vhosts/<path removed>/httpdocs/system/Content/Comment.php on line 1360 (0) #0 /var/www/vhosts/<path removed>/httpdocs/system/Content/Comment.php(1360): IPS\forums\_Forum->setLastComment() #1 /var/www/vhosts/<path removed>/httpdocs/applications/core/extensions/core/Queue/MemberContent.php(137): IPS\Content\_Comment->changeAuthor() #2 /var/www/vhosts/<path removed>/httpdocs/system/Task/Task.php(54): IPS\core\extensions\core\Queue\_MemberContent->run() #3 /var/www/vhosts/<path removed>/httpdocs/applications/core/modules/admin/system/background.php(87): IPS\_Task::runQueue() #4 /var/www/vhosts/<path removed>/httpdocs/system/Helpers/MultipleRedirect/MultipleRedirect.php(93): IPS\core\modules\admin\system\_background->IPS\core\modules\admin\system\{closure}() #5 /var/www/vhosts/<path removed>/httpdocs/applications/core/modules/admin/system/background.php(138): IPS\Helpers\_MultipleRedirect->__construct() #6 /var/www/vhosts/<path removed>/httpdocs/system/Dispatcher/Controller.php(107): IPS\core\modules\admin\system\_background->process() #7 /var/www/vhosts/<path removed>/httpdocs/applications/core/modules/admin/system/background.php(42): IPS\Dispatcher\_Controller->execute() #8 /var/www/vhosts/<path removed>/httpdocs/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\system\_background->execute() #9 /var/www/vhosts/<path removed>/httpdocs/admin/index.php(13): IPS\_Dispatcher->run() #10 {main} Any ideas how to work around this and unblock my tasks queue? Thanks.

@Marc StridgenI have figured out how to replicate it. It only happens if one of your fields has the 'Unique Field' setting. As soon as I removed the 'Unique Field' setting from a text field I had setup in the database, the Copy to Database worked fine again.

In the latest Invision Community release (4.7.13), I have tried to use the 'Copy to Database' feature of the Pages application. I selected the 'Copy Posts?' option and 'Use original author?'. When I submit, I see the following error suggesting there is a syntax error in a DB query: Note I've removed some paths and sensitive info. SELECT COUNT(*) FROM `cms_custom_database_4` WHERE field_25='<name removed>' AND primary_id_field != IS NULL IPS\Db\Exception: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'IS NULL' at line 1 (1064) #0 <path removed>/system/Db/Select.php(388): IPS\_Db->preparedQuery() #1 <path removed>/system/Db/Select.php(446): IPS\Db\_Select->runQuery() #2 <path removed>/system/Db/Select.php(370): IPS\Db\_Select->rewind() #3 <path removed>/applications/cms/sources/Fields/Fields.php(1069): IPS\Db\_Select->first() #4 <path removed>/applications/cms/sources/Fields/Fields.php(412): IPS\cms\_Fields::validateUnique() #5 <path removed>/system/Helpers/Form/FormAbstract.php(382): IPS\cms\_Fields::IPS\cms\{closure}() #6 <path removed>/system/Helpers/Form/TextArea.php(119): IPS\Helpers\Form\_FormAbstract->validate() #7 <path removed>/system/Helpers/Form/Text.php(298): IPS\Helpers\Form\_TextArea->validate() #8 <path removed>/system/Helpers/Form/FormAbstract.php(170): IPS\Helpers\Form\_Text->validate() #9 <path removed>/system/Helpers/Form/FormAbstract.php(147): IPS\Helpers\Form\_FormAbstract->setValue() #10 <path removed>/system/Helpers/Form/TextArea.php(66): IPS\Helpers\Form\_FormAbstract->__construct() #11 <path removed>/system/Helpers/Form/Text.php(125): IPS\Helpers\Form\_TextArea->__construct() #12 <path removed>/applications/cms/sources/Fields/Fields.php(3163): IPS\Helpers\Form\_Text->__construct() #13 <path removed>/applications/cms/sources/Fields/Fields.php(433): IPS\cms\_Fields->buildHelper() #14 <path removed>/applications/cms/sources/Records/Records.php(518): IPS\cms\_Fields::fields() #15 <path removed>/applications/cms/modules/front/database/topic.php(200): IPS\cms\_Records::formElements() #16 <path removed>/system/Dispatcher/Controller.php(107): IPS\cms\modules\front\database\_topic->form() #17 <path removed>/applications/cms/modules/front/database/topic.php(47): IPS\Dispatcher\_Controller->execute() #18 <path removed>/system/Dispatcher/Dispatcher.php(153): IPS\cms\modules\front\database\_topic->execute() #19 <path removed>/index.php(13): IPS\_Dispatcher->run() #20 {main} This feature used to work fine up until recently, but it is now broken. Is this a new bug?

For the Geolocation settings, is there a way of filtering all countries EXCEPT the specified one (i.e., a whitelist instead of a blacklist)? My forum's users are all based in one country, so it would make sense for me to validate all users outside of this country. Also, does the work for users who register via SSO (e.g. Google Login)?

@Michael.J I've been using this for the last few weeks. The firewall works well when accounts are created via standard registration form, but NOT if someone creates an account via single sign-on such as Google. It appears that SSO accounts completely evade the geolocation firewall. I am using this to block spammers located in certain countries, but people in these countries can evade this by simply using Google login. I can't disable Google login because many legitimate accounts on my forum already use this method. Is there any way this could be fixed / worked around?

I've taken the latest optional patch and it's still happening unfortunately. I can't find any other possibilities in the admin cp

Database problems are now solved. Just verified that this didn't solve the error with the tasks mentioned.

Access details have now been updated. Thanks.

Ever since I installed the Commerce application to my Invision community, I have been seeing a popup in my AdminCP saying there are errors with system tasks. Upon inspection of the tasks list, these are the two which are failing: Commerce monitorEvery Commerce expectedOutputMonitoring If I run these tasks manually then the same error is returned. They have never successfully ran. I have v4.7.9 of Invasion Community with PHP 8.0 installed and have tried the following: Clearing system cache via Get Support page in AdminCP Disabling all customizations This is the error in the system logs (note - removed the directory path) EX0 Something went wrong. Please try again. RuntimeException: (0) #0 (host path)/system/Patterns/ActiveRecord.php(148): IPS\_Task::constructFromData() #1 (host path)/applications/core/modules/admin/settings/advanced.php(828): IPS\Patterns\_ActiveRecord::load() #2 (host path)/system/Dispatcher/Controller.php(107): IPS\core\modules\admin\settings\_advanced->taskLogs() #3 (host path)/applications/core/modules/admin/settings/advanced.php(38): IPS\Dispatcher\_Controller->execute() #4 (host path)/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\settings\_advanced->execute() #5 (host path)/admin/index.php(13): IPS\_Dispatcher->run() #6 {main} The same error also happens on my test installation which runs PHP 8.1, so I don't know what could be causing this. Could anyone suggest any other steps I could do to diagnose this problem? What would be the impact of these two tasks not running? Thanks.