Randy Calvert

Awesome! I'm glad you were able to get the issue straightened out! 🙂

I'm actually using @Ehren's "Uniform" theme. It fit VERY well with our logo without a lot of heavy customization. I did end up tweeting the button colors a bit to reduce some of the grey (some users thought the grey meant the button was disabled), but nowhere near what I would normally need to do to integrate a theme.

If the site is in a different folder, have you fixed your .htaccess file? (You can either fix it manually or download it from ACP > System > Site Promotion > Search Engine Optimization. There is a "download this file" link on that page.) Also, you might need to run the option to rebuild your system cache in the ACP > Support section.

https://invisioncommunity.com/contact-us/ Choose Accounts and Billing. They'll get you squared away. 🙂

Many of the fields most likely are not used by you. For example, do you even allow reviews of products? Most users don't even have specific brands to be able to be called out. And most likely you also don't have a global identifier such as a MPN or ISBN number. These fields if available could help with showing up in the Shopping part of Google, but them not existing wont hurt your overall rankings from what Google has posted previously.

This used to be a signifiant problem for me, but using CleanTalk has cut that down SIGNIFICANTLY for me.

Just so you're aware.... those tools don't fix underlying server issues such as weak FTP passwords or poor database configurations, etc. If you have not done, so, change passwords for EVERYTHING.... FTP, mail, mySQL, any sort of web-management portal, etc. Then look at ensuring any software program you use on your site (IPB, Wordpress, or anything else) is updated. Finally look at using a cloud WAF such as Cloudflare to help improve your overall security posture.

If you are simply trying to track member activity more... there is a plugin from @Adriano Faria that might work: This would be more accurate than trying to map to IP addresses which might be shared or change over time.

You can set up one or multiple custom php.ini files to define how your web site functions. For example, you might have a custom file in your /home/username/public_html directory for your web site's main pages, and a separate custom file in your /home/username/public_html/images directory for your web site's image files.

Typically you should not have two lines with the same function called. Just add the additional parameters to the first line all comma separated. It does not need the rest of the module lines. I would delete all of that and literally only have the one line with disabled functions. It should go typically inside your forums folder or wherever you want it to apply.

Did you edit your conf_global.php file to change your board path to be https and then clear the system cache in the support section of your ACP? If not, do that.

Use a cloud firewall like Cloudflare if you don’t want to deal with figuring out what IP addresses are associated with a country and maintaining that list.

MySQL 8 works just fine and is fully supported. 🙂

IPB does not have any sort of direct integration path, however there looks to be options through Zapier. https://zapier.com/apps/monday/integrations/invision-community

ACP - Commerce - Payments - Settings Choose Email Copies and then select what types of transaction emails you want and what address should be BCC’ed.

No, this is not possible out of the box. This might be possible with a third party customization, however I am not aware of any that exist for this in the marketplace today.

If spam is really causing problems, take a look at the CleanTalk plugin. It’s helped reduce spam tremendously for my community. Some obviously still gets through, but it’s lowered the amount by around 80 percent.

I did this myself for a license that was not making use of the blogs app. Just use the contact us link and make the request. The good folks in the accounts team will help get you taken care of. And you would lose only the apps you ask them to remove. Not everything. 🙂 Once the change is done, it may take a few days for your board to pick up the license change.

That’s awesome. I’m glad it’s working for you. I know several others have reported various issues that have had to be addressed. So it’s great that you have not managed to run into any of those yet. Once 4.7 goes final, it’ll mean IPS can provide support for it without telling you to downgrade to confirm it was not related to something they could not support (yet). 🙂

As an update… according to release notes… the latest beta version adds support for PHP 8.1. Now this does not mean any third party applications or plugins will support it but it’s coming to the core suite!

The latest beta release (4.7.0 beta 6) adds support for PHP 8.1. 🙂

IPB does what they can with sanitizing user requests. However in terms of someone spoofing headers… Some ways of preventing host header injections: Validate Host headers User input must always be considered unsafe and should be validated and sanitized first. One way to validate host headers, where needed, is to create a whitelist of permitted domains and check host headers in incoming requests against this list. Respectively, any hosts that are not recognized should be rejected or redirected. To understand how to implement such a whitelist, see the relevant framework documentation. When validating host headers, you must also establish whether the request came from the original target host or not. Whitelist trusted domains Already at the development stage, you should whitelist all trusted domain names from which your reverse proxy, load balancer, or other intermediary systems are allowed to forward requests. This will help you prevent routing-based attacks such as a Server-Side Request Forgery (SSRF). Implement domain mapping Map every origin server to which the proxy should serve requests, i.e., mapping hostnames to websites. Reject override headers Host override headers, such as X-Host and X-Forwarded-Host, are frequently used in header injections. Servers sometimes support these by default, so it’s essential to double-check that this is not the case. Avoid using internal-only websites under a virtual host Host headers injections can be used to access internal (private) domains. Avoid this scenario, do not host public and private websites on the same virtual host. Create a dummy virtual host If you use Apache or Nginx, you can create a dummy virtual host to capture requests from unrecognized host headers (i.e., forged requests) and prevent cache poisoning. Fix your server configuration Host header injections are frequently due to default settings, and faulty or old server configurations. Inspecting and fixing your server configuration can eliminate significant vulnerabilities that open the door for injections.

I was mid edit and my time ran out to fix something. Take two on my last paragraph. Number three… encryption in transit is controlled by TLS on your server. The value would not be able to be read by a third party if HTTPS is utilized. The value in the example above is not from the database. It’s what is being passed from the form BY the user to your server. The user knows what the value is because they typed it. So you’re not exposing anything to the user. If HTTPS is utilized, it also can’t be exposed or attacked by a man in the middle. Once the server gets the data… passwords are stored in the database in an encrypted format with proper hashing/salting.

Number one is not “exposing” anything sensitive that is related to the server or app itself. It’s user level info or public knowledge data. None of those fields contain anything that is not already available elsewhere to that user as part of a normal HTTP request (either via header or body values). Number two would be mitigated at the server or via a WAF. That is not a code level thing to check. Number three… encryption in transit is controlled by TLS on your server. The value would not be able to be read by a third party if HTTPS is utilized. Again the only group that can read it is the user for their own data if HTTPS is enabled. The value is not from the database. It’s what is being passed from the form BY the user to your server. You can’t hash/salt it until the server gets it. Once the server gets the data… passwords are stored in the database in an encrypted format with proper hashing/salting.