DSystem

I tried with both the latest version (2.16?) and 2.1, and none worked (the index was not created for some reason).  With ElasticSearch 7.17 it seems to work fine.  I'm still making tests and I'll try again OpenSearch, but most likely I'll stay with ElasticSearch in the end.
Not sure which Debian version you are using, but probably you can use Docker to run ElasticSearch.

OpenSearch 2.1 compatibility ->https://invisioncommunity.com/release-notes/473-r114/
I'm setting up a new Debian server to host our eletronicabr.com forum.
I noticed that Opensearch compatibility is only up to version 2.1. But this version is not available for installation on the website https://opensearch.org/downloads.html
These are the available versions in the repository:
sudo apt list -a opensearch
Listing...
opensearch/stable 2.13.0 amd64
opensearch/stable 2.12.0 amd64
opensearch/stable 2.11.1 amd64
opensearch/stable 2.11.0 amd64
opensearch/stable 2.10.0 amd64
opensearch/stable 2.9.0 amd64
opensearch/stable 2.8.0 amd64
opensearch/stable 2.7.0 amd64
opensearch/stable 2.6.0 amd64
opensearch/stable 2.5.0 amd64
I didn't find an online repertoire for installing Elasticsearch 7.17 that currently works on my old server.
Would it be possible for the Invisioncommunity team to update this compatibility?
I noticed other customers having problems too:
https://invisioncommunity.com/forums/topic/473517-opensearch-210/
https://invisioncommunity.com/forums/topic/469896-reindexing-deleting-opensearch-index/

As a matter of principle, PHP 8.2 should be supported officially for v4 in the next months. PHP 8.1 is already in security-only support and that expires on 25 Nov 2024.

Allow a meta image to be uploaded per topic. Currently it just uses the default share photo so every shared topic looks the same if shared on social media (means less clicks and interest).
This is something I’ve needed for years which I’ve not even been able to get a working mod for.

@Adriano Faria In the past, I overloaded the function \IPS\Member::__set() checking for the key pp_reputation_points and then checking if the do parameter starts with (un)react. That should cover all areas I believe.
# We're updating the 'pp_reputation_points' value and we're (un)reacting if ( $key == 'pp_reputation_points' AND \IPS\Request::i()->do AND ( mb_substr( \IPS\Request::i()->do, 0, 5 ) === 'react' OR mb_substr( \IPS\Request::i()->do, 0, 7 ) === 'unreact' ) AND \IPS\Member::loggedIn()->member_id ) { // Your code } You also need to account for when the reputation is rebuilt though. That check is not included in the example above. It requires hooking the function that rebuilds the count and passing along some kind of flag.
 
If you want to check only removeReaction() skip the do=reactXXX check. That said, this kind of code doesn't let you know which reaction is actually being removed. It only acts on the points being updated. If you require to run it on specific reactions only, I have no idea how, unfortunately.

And again, fell into the black hole:
 
If there isn't an alternative for this, it won't be possible.

After watching your video, I can say for sure I forgot this... indeed, you can remove reactions directly in the popup that shows who reacted to the content:

The app doesn't extend this specific method, that's why it doesn't decrease.
I'll take a look. 👍

Get IPS to implement this:
 
Akismet is extremely effective and costs nothing to use. It would be a win-win for IPS and everyone who uses it.

So in recent weeks my forum has had a wave of spammers who have been able to freely post blatantly obvious spam on the site. Word filtering is absolutely ineffective to preempt them, and in the most recent case, isn't stopping them at all despite the terms being added to the post filter. In the support thread I filed, it was made clear your current anti-spam system only deals with user accounts, NOT with the content of the things they're posting. I'd say that's proven to be more or less useless. What IPS needs is preemptive/proactive spam defense, not reactive flagging and content deletion.
To that end, I'd like to very strongly suggest that IPB set up a partnership with the Akismet anti-spam service that's widely used by Wordpress blogs and a number of other sites and applications. Their system works by analyzing the actual content being posted and will return a yes/no type of response as to whether they think it's spam or not. From my own experience, they're rarely wrong about that. I'm using it on a bug tracking site I wrote myself, along with an obsolete forum package I still keep online for an old MUD.
A properly implemented Akismet setup will flag spam and store it in a temporary place for moderator review. From there, the content can be checked. If it's not spam, the moderators can click a button to indicate this, and a false positive is sent to Akismet for the system to learn from it. If it is spam, you can either delete it on the spot or let it sit in the pool until a specified expiry time (on my other 2 sites, I use the suggested 30 days). If a post actually does manage to hit the forum, the moderators can click a button there to have it reported as spam and their system learns from that as well. So it's very adaptable. What's even cooler, is the content scanning is done in real time so there's no having things sitting in some queue for days before it's evaluated by their servers.
There's a great deal more useful information to be found at https://akismet.com/ such as developer support and API documentation etc. I'm sure they could explain the gory details a lot better than I can. In the end though, this would be a wildly more effective way of dealing with spam than what we currently have.

What worked for me was this App:
 
It costs $8 per year. But worth the investment...

Just an update. I will be discontinuing any further development of this plugin in the future.
I have, however, totally rewritten this plugin from the ground up as an application instead. Not only that, but I have removed some features as they are no longer required due to being in the core now, and plan to add more features in the future.
The first release will be a beta version for testing purposes. if you would like to help out, let me know, and I will send you a copy to play with.

Find the IP address of the poster in your ACP and ban it.
Also, look into a Cleantalk.org subscription. Best $16 a year you'll spend.

Get a CleanTalk subscription and the plug-in from the marketplace. Best $8 a year you'll spend.

Some of these are indeed not registered on kickbox as disposable yet. I'll forward them to be added.
I'll see if I can add support for verifymail.io too, but as this is a paid service you'd need an active subscription with them to use their e-mail verification. They may be a bit quicker adding some of these compared to Kickbox, but the prior does not require any form of monthly payment to utilize their API.

this is one i would disagree on. the documentation states this:
so this tells me that my hook is being extended by the compiled theme class, which looks like this:

any developer worth their weight in salt, would come to the same conclusion that calling a parent in an overloaded method, should not be a problem. its a basic feature of OOP in php. so i would still argue that the problem is an engineering one inside the framework. 
this is why i get extremely frustrated with IPS. its a substantial investment on my part to be apart of the third party community (renewal fees + time), then to be told that a lot of the support issues IPS faces if from third party and frankly a lot of that is on IPS hands. you give us almost no tools, no real sdk (like example or boilerplate code), IDE plugins, cli generators, etc, that a lot of free frameworks will have available.  like most of the "incompatibilities" created by third party i've ever run into in IPS could be eradicated with with included developer tools like a  proxy class generator or a way for hooks to be understood by IDE's. 
sure i understand IPS isn't a multibillion company and doesn't have the resources to develop like a IDE plugin for its framework, but most of the other things i mentioned, i was able to create without any of that and i'm just one guy with a linux PC and a deskcat. 
any way, i'm not even suppose to be here today!

 

I pointed this out just recently mate. 

Thank you for bringing this issue to our attention, CodingJungle. We understand your frustration and apologize for any inconvenience this may have caused you. However, it's important to note that when customers manually write custom code to interact with our framework, it's their responsibility to ensure that it's compatible. While we do our best to provide support and address issues as they arise, we cannot guarantee that every possible combination of custom code will work seamlessly with our framework. We appreciate the solution you came up with and shared with us. Moving forward, we will do our best to improve the framework and ensure that our customers have a smoother experience.
I did look further today to see if there's something we could implement to at least stop this causing a fatal error. I've committed an idea and put it to the rest of the development team for review. I can't guarantee we'll proceed with it after review and testing, but it looks hopeful.

sorry Daniel, but this is NOT a third party issue. This is an engineering problem inside the framework. This was an issue reported/showed up almost 2 years ago and u guys did nothing to fix it or even comment on it, it was left up to me to debug it and come out with a solution. This is a good example of us using features of php (and of IPS) and since the framework is still mostly a pho 5.3 framework, it not playing nice with the modern versions. This is honestly the kind of nonsense of why I left.
These are not third party developer issues, don’t let IPS TELL U THEY ARE. these are issues caused by an engineering problem with in the framework as demonstrated by the topic Adriano linked too. They are eval’ing a non extended class to check for errors or something like that and that is where it throws the deprecate notice in 7.4 and the fatal in 8.0+. Put IPS’s feet to the fire, demand better from a software company that charges $300 a year for renewals for mediocre improvements and many years of outstanding bugs they ignore or refuse to fix.

@InvisionHQ: Please consider adding an option to fill rows, rather than show x amount of users. Now IPS is responsive, it makes more sense to say fill 4 rows.
If there's space for 10, it would be 10x4
On mobiles if it can only show 3 per line, it would be 3x4
No empty user space.
This would be awesome for 4.7 updates. Please consider it.

Hi Marc,
Just to keep you updated regarding this issue, I removed the database table updrade_temp and started the upgrade process again, and the upgrade worked without a hitch.
Thank you for your time 🙂

I’ll add a compatibility version tomorrow after some tests. 👍

New version for this resource has been accepted recently.
Changelog for 1.1.1
Add new option: Category view > Display prefixes Add new option: Category view > Theme: List > Display two item per line Add new option: File view > Simplify submitter links Add new feature: File view now fully support widgets in both Custom theme 1 and 2 via widget manager Fixed bug regarding File view > Custom theme 2 > long titles overlapping the download button Fixed bug regarding File view > Custom theme 2 > container boxes now fit to sides in chrome Fixed bug regarding File view > Custom theme 1 > colliding boxes may break in certain desktop screen resolutions  
Most important feature with this update is now both File View themes can accept sidebar widgets. Demo with theme 1.

Done and new version uploaded. Waiting for review and @Daniel F re enable purchses on it.
👍

I said in the Stock Replies announcement  that I would stop supporting this resource but I won’t. IPS new feature uses stock replies added by the admin on Admin CP.
My resource is per user basis. The users creates, on front end, the replies they want to use. 
I’ll keep this alive. 

@Adriano Faria its not 4.6 that is at fault per se, IPS is at some fault here due to the way they engineered how the theme hooks work, but it's the latest php 7.4 and 8.0 that is the issue.
example:
<?php class myclass { public function myfunction(){ return parent::myfunction(); } } this will error out on the new versions of 7.4 and 8.0, cause myclass isn't a child class of anything, so there is no parent to call. 
the theme hooks get eval'ed as stand alone classes, they replaced the " extends _HOOK_FILE" with "_tmp" (same with parent::hookData() gets replaced with array() ), so the class would be something like class my_theme_hook_temp {}. during the eval process, it it validating the code and that validation is failing on anything with parent::myfunction() that is being called in the code, that is why the call_user_func_array is working for toolbox, cause it passes the validation, so the template will build. 
so its not the parent::hookData() that i original thought it was, cause i just took a cursory look at the code, patched my files, it seemed to work cause my datastore wasn't cleared, but as soon as it cleared, i got that error. 
so in any template overrides you are doing, you need to wrap it with a if(\is_callable('parent::myfunction')){} and then inside the if statement, call the parent method with:
return \call_user_func_array( 'parent::' . __FUNCTION__, \func_get_args() ); like i have done in the example hook i posted a few post up. if you need further help, send me the app, and i will make the changes so you can see within your code what i'm talking about 🙂