DSystem

I've added protection for this, in a future version, so if a service cannot be reached it does not cause an error in the queue (it will still log it to the System Logs, however, as it's important to know what happened if a notification is not sent).

I also hated the way this looks and changed mine a long time ago, but it does involve changing a template. Many of my members have a profile photo and I wanted it out of the area where the photo goes.
 

@GaryI did it very fast, but perhaps something like this where everything can be readable. 

I’ll take a look for February release. I just released a new version. 
Thank you.

Thank you for updating that information. Please be advised I have moved this to a ticket for further investigation. Please watch your email for further correspondence. 

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'm a little late to this thread, but just wanted to confirm that I too had the same problem. Couldn't connect to MySQL.
This was solved by changing from 'localhost' to '127.0.0.1' in the conf_global.php file.

Invision Community 4.7.2 now features a third party application and plug-ins PHP 8 compatibility scanner.
Please read this post as you may find applications of plugins disabled after upgrading.
Why do we need this?
The underlying programming language that Invision Community uses is PHP. The latest version, PHP 8 was released in November 2020 and features many breaking changes and incompatibilities that are not backwards compatible. Some of these changes mean that what was a harmless silent notice, is now a fatal error which would mean that if you upgrade with incompatible code, your community would throw a fatal error which results in either a white screen, or a server level error message in your browser.
These fatal errors cannot be captured by Invision Community and managed. The fatal errors are deeper in the execution chain.
PHP 8 has been out for close to two years, and PHP 7.4 is 'end of life' and security updates will cease from November which means that it becomes insecure, so everyone will have to move to PHP 8 very shortly.
What is it
The compatibility checker examines all third party applications and plugins that you have added from the Marketplace.
We encourage our Marketplace authors to test with PHP 8 but not all do, and as such applications and plugins that work fine with PHP 7.4 will fail with PHP 8.
The compatibility checker scans all third party code for issues that could cause fatal errors, and if it finds them it will disable the application or plugin on upgrade.
The only way to re-enable the application or upgrade is to update it to a 4.7.2 compatible version from the marketplace.
Can I re-enable disabled third party plugins and applications?
Yes, if you are confident the plugins and applications are fine to run with your current PHP version then you can re-enable them until our November release which will then enforce the disabling of applications.

It's worth reaching out to the authors of key plugins and applications to see if they have a PHP8 compatible version available, or plan to have one by November so you can prepare for the November upgrade.
Is this really needed?
Unfortunately yes. PHP are making bold changes that are not backwards compatible. Invision Community is fortunate to have so many third party developers releasing apps and plugins to further enhance the feature-set, but we do not have direct control over this code. Our priority is to ensure that your site upgrades smoothly and remains online.
Why now?
We finally ran out of road. We have been working towards PHP 8 compatibility for a while, and we have encouraged our third party authors to do so too, and to test with PHP 8. We also informed the developers in August about the scanner and what it may do to their applications. We also have been releasing Invision Community 4.7 betas since May of this year to give them as much time as possible to update their applications. Enforcing this change is painful in the short term but benefits everyone in the longer term.
What else can I do?
Your self-hosting license allows you a test install which you should use as a staging site and test any upgrades on that staging site before performing the upgrade on your production site. This will enable you to capture any issues that may arise before you run it on your production site.

As always, we recommend that a back-up snapshot is taken before any upgrade so that you can easily rollback if you encounter any issues.
I'm using PHP 7, does this affect me?
Yes, the compatibility scanner will still run on the upgrade and check for PHP 8 issues so that when you do upgrade to PHP 8 you won't find that your community is no longer working.

Thanks for reading!

Judging by the error, it is running the queries without select the proper content somehow. Nothing has changed in the content items. Nothing has changed in the widget “model” or in this widget specifically so I suggest you to simply edit it, choose the content again (probably topics), save and see if the error continues.

@HDiddy
Here is the guide I used to install opensearch 2.0 on centos 7
Install OpenSearch 2.0
java
sudo yum install java-11-openjdk-devel
java -version
 
OpenSearch -> https://opensearch.org/docs/2.0/opensearch/install/rpm/
sudo curl -SL https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/opensearch-2.x.repo -o /etc/yum.repos.d/2.x.repo
sudo yum repolist
sudo yum clean all
sudo yum list | grep opensearch
sudo yum install opensearch
sudo systemctl start opensearch.service

First Test
systemctl status opensearch.service
curl -XGET https://localhost:9200 -u 'admin:admin' --insecure

Added when starting linux
sudo systemctl enable --now opensearch

Disabling security -> https://opensearch.org/docs/2.0/security-plugin/configuration/disable/
echo -e "\n# To disable security\nplugins.security.disabled: true" >> /etc/opensearch/opensearch.yml
systemctl restart opensearch.service
Second test
curl -XGET http://localhost:9200
{
  "name" : "srv.xxxxxxxx.com",
  "cluster_name" : "opensearch",
  "cluster_uuid" : "gNoLRKpERSOmQS9raXqUig",
  "version" : {
    "distribution" : "opensearch",
    "number" : "2.0.0",
    "build_type" : "rpm",
    "build_hash" : "bae3b4e4178c20ac24fece8e82099abe3b2630d0",
    "build_date" : "2022-05-19T00:25:28.444553037Z",
    "build_snapshot" : false,
    "lucene_version" : "9.1.0",
    "minimum_wire_compatibility_version" : "7.10.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

optimization -> http://wiki.centos-webpanel.com/how-to-install-elasticsearch
sed -i -e 's|-Xms1g|-Xms2g|g' /etc/opensearch/jvm.options
sed -i -e 's|-Xmx1g|-Xmx2g|g' /etc/opensearch/jvm.options
 

File updated to 4.7, 4.6 and 4.5. Waiting for review.

@HDiddy
Here is the guide I used to install opensearch 2.0 on centos 7
Install OpenSearch 2.0
java
sudo yum install java-11-openjdk-devel
java -version
 
OpenSearch -> https://opensearch.org/docs/2.0/opensearch/install/rpm/
sudo curl -SL https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/opensearch-2.x.repo -o /etc/yum.repos.d/2.x.repo
sudo yum repolist
sudo yum clean all
sudo yum list | grep opensearch
sudo yum install opensearch
sudo systemctl start opensearch.service

First Test
systemctl status opensearch.service
curl -XGET https://localhost:9200 -u 'admin:admin' --insecure

Added when starting linux
sudo systemctl enable --now opensearch

Disabling security -> https://opensearch.org/docs/2.0/security-plugin/configuration/disable/
echo -e "\n# To disable security\nplugins.security.disabled: true" >> /etc/opensearch/opensearch.yml
systemctl restart opensearch.service
Second test
curl -XGET http://localhost:9200
{
  "name" : "srv.xxxxxxxx.com",
  "cluster_name" : "opensearch",
  "cluster_uuid" : "gNoLRKpERSOmQS9raXqUig",
  "version" : {
    "distribution" : "opensearch",
    "number" : "2.0.0",
    "build_type" : "rpm",
    "build_hash" : "bae3b4e4178c20ac24fece8e82099abe3b2630d0",
    "build_date" : "2022-05-19T00:25:28.444553037Z",
    "build_snapshot" : false,
    "lucene_version" : "9.1.0",
    "minimum_wire_compatibility_version" : "7.10.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

optimization -> http://wiki.centos-webpanel.com/how-to-install-elasticsearch
sed -i -e 's|-Xms1g|-Xms2g|g' /etc/opensearch/jvm.options
sed -i -e 's|-Xmx1g|-Xmx2g|g' /etc/opensearch/jvm.options
 

@Matt I'd love it if you guys take a look at the bug reports in https://invisioncommunity.com/forums/forum/504-developer-connection/ ...
I reported a lot of minor bugs myself lately (easy fixes, too) but nobody replied to the topics and I don't see them listed in the release notes, either. 🙄

@Stuart Silvester encouraged me to look into this as he mentioned not having an issue with some testing. I may have found the fix to this and got it working on my sites. Turns out that even though the default notification settings in ACP where correct for email:

 
The DB was not showing this under the default notifications table and showing inline only (not sure why).

I re-saved in ACP and now the db is correct:

After this, it does seem to be working. It seems that the fix may be to re-save the default notifications in ACP. Why the db did not reflect what is in ACP, I do not know. I am going to have to recheck all default notifications and re-save them. Check your db table core_notification_defaults if you are having issues.

would it be possible to improve the subscription and checkout page to make them more powerful and better convert the sale?
we could for example use widgets...
here is the example of a subscription page and another of checkout
https://thrivecart.com/special-offer/confirm-your-order/
https://checkout.thrivecart.com/thrivecart-standard-account/
 
thanks

This issue has been resolved in 4.6.12, which has just been release. Please let us know if you still have any issues once you have upgraded to that release.

Someone from IPS needs to approve the new version (4.0.0) before it shows up for download.
In case you don't want to wait the file is already available on my site: https://community.invisionbyte.net/files/file/274-tb-bump-up-topics/

I agree, I am sure there was once a way to trigger a rebuild for all members.
The workaround I can see:
Go into any member from Admin panel Click down arrow under Posts Click Recount Select Recount for all members Follow the same procedure for Reputation Level.

Not sure if my opinion is worth anything, but it'd be useful to have all the rebuild/recalc options on the support page (like clear caches). vBulletin does it that way (or at least used to) and it was quite handy. 
That did it. Awesome. Thanks! 

It's a good idea and seems a natural place for it to be. Maybe post it in Feature Suggestions?
https://invisioncommunity.com/forums/forum/499-feature-suggestions/

@EmediatoIt's already a lot if I can pay for the license (vsito that the forums in 2021) hardly anyone uses them anymore...
I cannot spend a hundred euros for Sendgrid.
By the way there are many better email providers than Sendgrid but ipb only supports Sendgrid so it is essential that you implement both the ability to send emails by yourself and with other email providers.

This is still an open issue at present

It was the cookie path that was being set incorrectly. Nginx was configured:
server_name _; which was then being used by
$_SERVER['SERVER_NAME']; in
\IPS\Request::getCookiePath() which was causing the cookie path to be set to "//domain.com" instead of "/". I was under the impression that Nginx automatically set the server name to the request's host when using "_", but that is incorrect.
Simply setting the correct server_name or manually changing the server name header to $host would fix it.

Many thanks but ipb should take care of this ...