Jump to content

Randy Calvert

Clients
  • Posts

    3,916
  • Joined

  • Last visited

  • Days Won

    78

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Projects

Release Notes v5

Invision Community 5 Bug Tracker

Forums

Events

Store

Gallery

Everything posted by Randy Calvert

  1. 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.
  2. 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.
  3. 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.
  4. Page view is the base loading of a raw page. Content view might only trigger on Ajax calls, etc.
  5. 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.
  6. It happens more frequently than you might think! It absolutely is not a "just you" thing. It catches even the best of us sometimes!
  7. 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.
  8. Was someone who is in a member group designated as “highlight replies” participating in the thread that has it showing?
  9. If you have references to ipb_ firewall inf your conf_global.php file, remove them.
  10. 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.
  11. 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. 😄
  12. 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. 🙂
  13. 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
  14. 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.
  15. 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! 🙂
  16. 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. 🙂
  17. You would need a plugin to accomplish this level of granularity.
  18. 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.
  19. 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.
  20. By default on new installs, you would use email address to login. Did you use the email specified when you setup the software?
  21. That looks like the banned screen, but without language strings.
  22. You might want to work with that plugin developer then if it only occurs when using it. At least you understand what is going on now and why it's happening!
  23. IPB does not have a concept of “forbidden”. That’s coming from your host or a firewall. Check with your host if you have anything like mod_security or a firewall (cloudflare) enabled. If so… try turning it off.
  24. IPS is not "detecting" anything. It's being notified of bounces and they're taking action based on that notification of a bounce or email marked as spam. In the IPB cloud, IPS gets notices via an API call when emails are bounced or marked as spam from AWS. (This is because all email is sent from "noreply@invisioncommunity.com".) When a message then bounces, it goes to AWS and AWS sends the notification to IPS to take action on it. In a self-hosted environment, most email providers don't provide a way of pushing bounces to an API endpoint for IPS to process. That means nothing ever reaches the software for them to potentially take action on.
×
×
  • Create New...