Randy Calvert

How are you trying to deploy it? Just creating a compute instance and installing a full LAMP stack? If so this should be fine. The server won’t have email or DNS or other thing so make sure you plan for all of the various components you will need.

You don’t need blogs to use Adsense. However you do need to know their guidelines about what content is allowed and where ads are placed. The ad code can be added to your theme HTML. But you would have to configure Google itself to ignore pages like login, logout, and wherever else Google says they don’t want ads served.

Yes, Pages will continue in v5! 🙂

When a crawler tries to access a topic that it does not have permission to access, it will get a message denied. It can't do anything else. In terms of IPB trying to figure out what speed your server or site can handle... it can't do this. It does not know if it's on a shared host, or some monster beast, etc. It does not know if it's the only thing running on the server or if there are other sites/applications also running. You need to monitor and control bad bots outside of the software. Good bots will follow robots.txt instructions you place in. Bad ones that don't... you should be blocking from getting to the site at all which is done either at your server denying by the IP addresses or ASN (for example using CSF), etc or within some sort of WAF that sits in front of the site/server. The best place I would suggest doing this would be within some sort of WAF such as Cloudflare. There is no way to do this. If you go to the Sitemap tab... that value should be pre-filled in with something valid. Can you actually open that path? It should be whatever address you use to access the ACP, but without "/admin", and adding /sitemap.php on the end. Out of curiosity, have you tried this in a different browser to make sure it's not a browser auto-fill issue and have you also tried disabling any 3rd party resources (applications/plugins)?

Remove any references to IPB_Firewall from conf_global.php. See:

1. Click on crawl management tab (you see it in your screenshot). Click on custom and define your own. You can also click on “Do not use” and create your own file via FTP. Remember though… if you choose custom or do not use… you start with nothing for the file. So you might want to add even the stuff that might already be in auto the IPS generated version. 2. This is typically just the root of your install with the protocol. So https://yourwebsite.tld/invision/sitemap.php based on your example above. 3. Slowing down bad bots, etc is not something you do at the software level. You do that at either your server level or firewall level. Talk to your host for help with that. And bad bots don’t respect robots.txt just fyi. 🙂 4. That’s a server/hosting issue. You might block them using custom .htaccess rules or via a firewall.

That would be potentially great if people actually updated their license when they clone a prod instance to a QA. (You can simply ignore license warnings once installed.) But if they could fix their license, they could also simply turn off the cron job as easily or had a constants.php created that is non editable or replaceable with those flags set. Another idea is within the payment gateway, only accept transactions submitted by your prod instance. For example in Stripe, create a radar rule to reject transactions that don’t come from your prod server IP.

Index.pl, index.cgi and index.html are files that do not exist in a default installation of IPB inside of the /admin folder. My guess is when you try to access domain.com/admin/, your host is first trying to find file index.html which does not exist. It then tries to find index.pl which also does not exist. It then tries index.cgi which also does not exist. It succeeds when trying index.php. The order in which files are tried are managed in the DirectoryIndex directive of the server. Each of those “not founds” would trigger a 404 error. This is not an IPB problem. You can ignore the warning or have your host make the default file index.php and to try it before trying other variations. The other issue is that an attacker is just trying to guess files and randomly just trying to load /admin/index.cgi or /admin/index.pl, etc. If this is the case, there is nothing you can do to block it within IPB as it's trying to attack something outside of the software. In either case, it's a server/hosting related issue.

Page view is the base loading of a raw page. Content view might only trigger on Ajax calls, etc.

I know it does not help in this case, but one thing I do on my community is to have a "RIP" member group. This group has essentially a group with no permission to access/do anything on the site. It serves a few purposes: Locks down the account in case someone were to hack it, etc. Preserves the member account for things like search Shows the RIP group as a way to remember/memorialize the lost person so any of their content. You could even choose to highlight posts by this group? Makes it easier for me to remember why something was done earlier (instead of simply banning them). If they are in RIP, I know exactly what happened.

It happens more frequently than you might think! It absolutely is not a "just you" thing. It catches even the best of us sometimes!

Unfortunately then you would need to ask your host to explain it. The IPB software itself does not control how database sizes are reported. They're the user of the database, not the administrator of it.

Was someone who is in a member group designated as “highlight replies” participating in the thread that has it showing?

If you have references to ipb_ firewall inf your conf_global.php file, remove them.

The April showers are almost done!

Did you check to make sure you have all of the system requirements? There is a handy script you can upload and run to make sure you have all of the required PHP modules, etc. If this is a new install, you might be missing something IPB is expecting but not finding.

It looks like IPS has just recently upgraded their site to the beta version. My guess is there is a bug they're gunna have to work out if emails from the community to you are actually delivering. 😄

You need to look in your server's apache error logs to see what is going on. It should give you more clarity about what the problem actually is. 🙂

It's something being tested by IPS. For cloud customers, they're introducing bounce management. If emails sent from a cloud community bounce to a member, it will disable emails being sent to them and the user will be prompted to update their email address. Check out

The author has not logged in since July 2022 and does not have an active IPB license (he’s in the member group instead of clients). So it does not look promising.

Awhile back, I got around this by uploading the resource without uninstalling the original MP one. But that looks like that does not work anymore as it gives an error now. So I dunno! 🙂

In his initial message he said As soon as he uploaded the direct version from you, it changed the app to custom. From my own experience, if any file is ever updated outside of marketplace… it becomes custom and no longer is manageable from MP without manual intervention. He needs to pick one place and stick with it. 🙂

You would need a plugin to accomplish this level of granularity.

It's possible those are not real members and instead fake spam registrations that are just entering addresses. Ultimately IPB does not control delivery of mail. It sends the request to your host server. If you want to confirm that it's not an IPB problem... send an email to one of the addresses outside of the IPB software.

That’s not something that happens in the base software. Either something in your hosting is causing problems or a third party resource is. I would start by disabling all resources. See if the problem continues to occur.