catbreadbat

A quick google search revealed an existing regex:
 

/^.{3,32}#[0-9]{4}$/

On 12/28/2021 at 10:17 AM, evcom said:

The Cloudflare Community came to the rescue with the right pointer. The 'activity log' of the firewall rules shows the details of the triggered event. What I now did, is to allow the Invision Community user agent...This resolved the issue and login to the marketplace is no longer blocked. 

There might be better solutions. Suggestions are welcome 🙂

Can you share a screenshot of the working firewall rule? I'm having trouble with this as well.

16 minutes ago, Jim M said:

While I understand that, some background processes may still be influenced by disabled applications which is why uninstalling unused or outdated applications may be in your favor here.

I have removed that application and all other unused ones and the issue persists. 

1 hour ago, Jim M said:

I would suggest first starting off by updating all your third party applications/plugins there are some there too which are far outdated, like the Rules application. 

Please then check your ElasticSearch connection in ACP -> System -> Search. Then rebuild the search index on the same page. If you're still having this error logged, please let us know. If it is resolved, please have your hosting provider truncate the table. 

The rules application is disabled and not in use. I’ve disabled all hooks loaded by the error, and rebuilt the search index yet again. Issue persists

5 hours ago, Luuuk said:

Hi,

You can truncate the core_log table. I always do the operation when lots of errors are recorded.

How to do this?

4 hours ago, Marc Stridgen said:

We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. 

We look forward to further assisting you. 

 

I’ve updated the information.

Clearing cache didn't fix the issue. I also tried rebuilding the search index and that hasn't fixed the error spam either.

The error was of type Elasticsearch. I cleared caches from admin CP and it seems to have stopped logging this error now. Will update if it spams the log again. Is it possible to clear these entries from the DB to reduce it's size in our backups?

Our log table is growing out of control, even with the pruning set to 1 week. Here's the message:

Quote

The log table core_log within the database is 179.71 GB in size.

There is a repeated error (500 times) that seems to be the cause:

Array ( [query] => Array ( [bool] => Array ( [must] => Array ( ) [must_not] => Array ( ) [filter] => Array ( [0] => Array ( [bool] => Array ( [should] => Array ( [0] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\core\Statuses\Status [1] => IPS\core\Statuses\Reply ) ) ) [1] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\forums\Topic\Post ) ) ) [2] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\downloads\File [1] => IPS\downloads\File\Comment [2] => IPS\downloads\File\Review ) ) ) [3] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\cms\Pages\PageItem ) ) ) [4] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\gallery\Image [1] => IPS\gallery\Image\Comment [2] => IPS\gallery\Image\Review ) ) ) [5] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\gallery\Album\Item [1] => IPS\gallery\Album\Comment [2] => IPS\gallery\Album\Review ) ) ) ) ) ) [1] => Array ( [bool] => Array ( [should] => Array ( [0] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\core\Statuses\Status ) ) ) [1] => Array ( [bool] => Array ( [must] => Array ( [0] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\forums\Topic\Post ) ) ) [1] => Array ( [term] => Array ( [index_is_last_comment] => 1 ) ) ) ) ) [2] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\downloads\File ) ) ) [3] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\cms\Pages\PageItem ) ) ) [4] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\gallery\Image ) ) ) [5] => Array ( [terms] => Array ( [index_class] => Array ( [0] => IPS\gallery\Album\Item ) ) ) ) ) ) [2] => Array ( [term] => Array ( [index_item_author] => ) ) [3] => Array ( [range] => Array ( [index_date_created] => Array ( [gt] => 0 ) ) ) [4] => Array ( [terms] => Array ( [index_permissions] => Array ( [0] => 3 [1] => m1252776 [2] => * ) ) ) [5] => Array ( [term] => Array ( [index_hidden] => 0 ) ) ) ) ) [sort] => Array ( [0] => Array ( [index_date_commented] => desc ) ) [from] => 0 [size] => 11 [error] => Array ( [root_cause] => Array ( [0] => Array ( [type] => illegal_argument_exception [reason] => field name is null or empty ) ) [type] => illegal_argument_exception [reason] => field name is null or empty ) )

On 2/10/2022 at 3:37 AM, Marc Stridgen said:

Glad to hear you like the achievements system. You can indeed re-add the defaults if you wish, even after upgrading. If you look in the following folder on your server, you will see the 3 xml files which are used to add these. You can use these files with the import button in the relevant areas. Of course, import ranks and badges before you import the rules

\applications\core\data\achievements

Once you have done that and made any adjustments you would like to make, you can then use the rebuild button to rebuild for all members on your site

Hope that answers your question, but please feel free to shout up if you have any further questions on these

This didn't work for us, we only have the default 4 in the badges.xml file. Is there another way to get these back?

EDIT: it seems some of the defaults come from re-importing the rules themselves actually.

On 7/6/2021 at 8:25 PM, All Astronauts said:

I might charge a touch as I'm probably throwing this into an app and adding in ACP widgets for the service status stuff.

 

Was this ever released?

I am also curious about this.

On 4.6.5.1, this breaks the default twitter emoji

Same issue for reviews on the Downloads section.

I have this issue as well.

Got this warning on dareboost:
 

You have 10 img tags, but the following tag does not define the alt attribute:

<img src="https://example.com/forum/uploads/set_resources_29/5544dacf0188947ee7ee3cab199909ca_Discord_Icon.png">

Doesn't seem to work for me with subscriptions on 4.3.2:

When a user tries to submit their request for deletion, this error is thrown:

UPDATE `IPB_core_members` core_members  SET `deleteaccount`=1,`deleteaccount_reason`='<p>
	User no longer wants account.
</p>' WHERE member_id=234782 
IPS\Db\Exception: Unknown column 'deleteaccount' in 'field list' (1054)
#0 /home/user/web/site.com/public_html/forum/system/Db/Db.php(870): IPS\_Db->preparedQuery('UPDATE `IPB_cor...', Array)
#1 /home/user/web/site.com/public_html/forum/system/Patterns/ActiveRecord.php(489): IPS\_Db->update('core_members', Array, Array)
#2 [internal function]: IPS\Patterns\_ActiveRecord->save()
#3 /home/user/web/site.com/public_html/forum/init.php(441) : eval()'d code(68): call_user_func_array('parent::save', Array)
#4 /home/user/web/site.com/public_html/forum/system/Member/Member.php(317): IPS\Patterns\rules_hook_ipsPatternsActiveRecord->save()
#5 /home/user/web/site.com/public_html/forum/init.php(441) : eval()'d code(40): IPS\_Member->save()
#6 [internal function]: IPS\core\modules\front\system\hook1153->_deletemyaccount()
#7 /home/user/web/site.com/public_html/forum/applications/core/modules/front/system/settings.php(55): call_user_func(Array)
#8 /home/user/web/site.com/public_html/forum/system/Dispatcher/Controller.php(96): IPS\core\modules\front\system\_settings->manage()
#9 /home/user/web/site.com/public_html/forum/applications/core/modules/front/system/settings.php(35): IPS\Dispatcher\_Controller->execute()
#10 /home/user/web/site.com/public_html/forum/system/Dispatcher/Dispatcher.php(129): IPS\core\modules\front\system\_settings->execute()
#11 /home/user/web/site.com/public_html/forum/index.php(13): IPS\_Dispatcher->run()
#12 {main}

Running 4.1.16.1

21 minutes ago, Kevin Carwile said:

Well, you cant really do that. How do you know which topic to check against when the second "duplicate" one is created. The topics are not related to each other and are not both present in the event, so I dont even know how you are attempting to check one against the other from a rule.

How and why do you have duplicates anyway? It might be a better idea to just fix that problem before it happens.

 

Good point.

Somtimes the post won't 'go through'. So the page doesn't switch to the topic page after creation, so user clicks submit a second time, which posts topic a second time. At least, that's how it's been described to me, I haven't encountered the issue myself.

Any idea how to create a rule to check for duplicate topics, then delete the duplicate which was created AFTER the first? I tried setting up a rule for this, which doesn't work:

• Run on topic created

Conditions:

• Check if topic titles are the same.
• Check that topics were created within the same hour.
• Check that topic creation dates, are not the same. (so topic being created is not deleted for matching itself).

Actions:

• Delete topic. (run action 2 minutes after)

With that above, minus the third condition, the first topic is deleted upon creation, because it's matching against itself somehow. How can I make a rule that waits for both topics to be created and can check them against each other?

Same here.

Whenever I run the IPS support tool, it prompts me about an error in the database, and to run this command:

ALTER TABLE `IPB_rules_arguments` CHANGE COLUMN `argument_custom_action_id` `argument_custom_action_id` INT (11) NOT NULL DEFAULT 0 COMMENT '';

I'm trying to setup a rule to do the following:
- Send members that follow a bug report a notification, when original report content is edited.

I have everything in place, but it doesn't seem my 'action' is sticking. Whenever I go back to edit it again, the fields are clean again, and I must re-enter all the data. I found this out because I get the "Operation skipped (missing argument) No argument available for: recipients" when I clearly have recipients stored.

I'm currently just evaluating the lite version, and will probably purchase if we can get this resolved.