Randy Calvert

4.7.4 will continue to require PHP8. They've updated the Beta 1 release notes to more clearly indicate PHP8 is required. 4.7.3 is the last release that will support PHP7.4. You're welcome to use that version if you like, but the system requirement of requiring PHP8 for 4.7.4 won't change.

Remember... there are 2 options... override and respect. You can set a manual cache time, but you have to do it in 1 hour increments. If you're respecting origin, IPB's cache control headers are set to 900 seconds. Meaning would be delayed NO MORE than 15 minutes. Here's the exact header values being passed: As you can see, the max-age value is 900 seconds. This means the LONGEST it would be delayed is 15 minutes... assuming someone posted something new just seconds after the original topic page was cached. Again... that's a worst case scenario. The more common case is a few minutes.

In this scenario, you're better off honestly without caching. 🙂 Think of it this way... even a site that shows 300 visitors online is 300 users over the last 30 minutes. That's an average of 10 users a minute on AVERAGE across your entire site. They're all not going to be sitting on that one page to be cached... they're viewing different topics, or sub forums, or looking at your other various pages. You're spending more server efforts putting a page into cache for that subsequent page view when 95% of the time, no one is ever going to get that same page within the next 29 seconds before it expires.

Cloudflare will only allow you to respect the cachability headers from origin or 1 hour, 2 hour, 3 hour, etc. But again if you’re setting 30 seconds, you’re not getting any value anyway honestly. Just forget about caching period because I can almost guarantee it’s not giving you value.

With the Cloudflare cache, you can either respect cache control headers, or override them. However the minimum time you can set in an override on the free and pro plans is 1 hour. To be honest unless your site is like CNN, you get no real value from 30 seconds. You would need a hugely trafficed site for it to be worth having a cache value that low. Remember reach region has its own cache. Meaning Chicago’s cache is separate from LA which is different than NYC.

This is something your hosting provider will need to assist with as that is most likely either a reputation issue or a mail configuration issue. As long as the software can get the request to your mail server, IPB loses insight to what happens after that. FYI… IPB does support integration with other mail providers such as Sendgrid. You could also arrange for another company to deliver mail for you by utilizing SMTP delivery instead of php mail.

Set the cache to honor origin. IPB will set appropriate cache control headers.

Sounds like you don’t have all of the files downloaded properly? Download a copy of the 4.7.3 files from the client area… upload them to your website via FTP (override anything already there) and then run domain.com/admin/upgrade again. If that does not work, an IPS staff member may need to look. Make sure you have your info updated in the client area (both FTP and ACP details) as that is a common thing that delays getting help. If you use an email to login to the ACP instead of username, make sure that is used when you put your info on file.

4.7.4 IS the November release. Beta 1 is the first “draft” of that release. 4.7.3 is the currently supported “live” version. I would generally suggest restoring from backup and installing 4.7.3 as it does support PHP7.4. Just release it’s the last version that will support it and PHP7 itself is end of life literally in a few weeks.

Now that you can get into the ACP, remove the constants.php file. You can resume the upgrade by going to domain.com/admin/upgrade

Recovery mode has you edit (or create) a constants.php file which you upload via FTP to your site. It then disables all plugins and applications. Use the second link I gave you for details on how to do it The compatibility script you also upload via FTP to confirm you meet the requirements for the version you’re attempting to install. It’s in the first link I gave you.

The only way to “cancel” an upgrade is to restore from a backup. If you’re getting an error, it means either you don’t meet the system requirements or you are using a 3rd party plugin that is not compatible with the latest version. You can install the following script to check if you meet the system requirements for the latest version of IPB: If everything is green there, you can use Recovery Mode to disable all of your 3rd party resources: Use a different browser to make sure you’re not logged into the ACP already. Once you turn on recovery mode and logged in, it will make you remove the variable from constants.php to continue using the ACP.

You MUST be on PHP8 for IPB 4.7.4.

If it’s being called via a web browser, move the existing files above public_html into /home/username/ such as /home/username/old Files not in public_html can’t be accessed online. Only via SSH or FTP. The other possibility is to just save your conf_global.php and just delete everything else. You’ll lose attachments, avatars, etc…. But you’ll know for sure nothing got carried over.

This makes the assumption your old and new instance of IPB are the same version… Move all of your existing files from the main location to a new location. /var/www/html to /var/www/backup for example (not a real location… just an example that should be modified based on your setup) Once you’ve done that, put a fresh set of files in /var/www/html Copy your old conf_global.php over from the backup location. That will provide your database info and bring the site online. You can copy over specific things you need from your uploads folder etc.

While it won’t break anything to keep the existing setup… you won’t get much overall value in my experience. I would PERSONALLY turn them off to simplify the experience and have less things there to possibly go wrong. Unless the feature is actually helping something, I would not really force its use.

Think of the data flow like this: End User —> Cloudflare —> Origin In a reverse proxy scenario, there are two legs to address… End User to CF. (This is the “edge”.) A user’s request actually terminates there and CF handles this encryption. But there is also the communication between CF and your server. (This is the “origin”.) If a request is not in cache or not allowed to be in cache (like for a logged in user), CF will have to retrieve it from origin. In this case, your origin server is responsible for SSL. If you have a valid cert, and plan to keep a valid cert on the origin… you can use full encryption. It’s saying both legs of the trip MUST be properly encrypted. If not, throw an error. Flexible SSL says only the communication between User to Edge must be encrypted fully (which CF takes care of) but that for the back half of the journey, you don’t HAVE to present a valid cert. You can but it’s not required. Cloudflare will ignore certificate warnings or if a cert if not presented. The reason this setting exists is to help mitigate potential Man-In-The-Middle attacks. If you don’t have SSL enabled, something between you and the server (or something between CF and your server) could possibly read the request if it wanted to because it’s not encrypted. For small gaming sites, this may not matter. But if you were handling sensitive financial transactions, you might want to ensure full encryption for the entire request flow instead of just one part of it. So you don’t HAVE to use “Full” encryption. You have the option to do so since you have a valid certificate. If you however did not have a certificate at origin, you would get an error if you used “Full” since it would be impossible to fully encrypt the request flow on both segments. Regarding the ORIGIN section of the SSL area, you can ignore it. It allows you to import your own self signed SSL certs or for you to use a CF provided origin cert at origin. (That cert is only trusted by CF, not regular browsers.) It’s only needed by those that actually sign their own SSL certificates instead of using ones issued by full certificates issuers (called Certificate Authorities or CA’s).

You should be signing into the Marketplace with the IPB client area credentials.... which should be an email address. If you are picking a username, it's most likely not right (unless you originally signed up a social network such as Facebook or Twitter, then it's that account login.) Go to the Marketplace. If you are signed in with an account, click Signout. When you do that, you should see a sign in button. Sign in with the same username/password that you use to login to the IPS client area with.

You can access the ACP by going to domain.com/admin (just add /admin after your site).

The important thing is that it's working now. 🙂 That's all that really matters!

Just be aware that version 3.4 has been EOL for a LOOOOOOOOOOOOOONG time. It first came out in 2013 and was 100% end of life'ed in 2017. While I realize it would take time, money, and effort to upgrade... it means you're running software (IPB, Apache, PHP, mySQL) that are all highly out of date with many known security vulnerabilities. The longer you wait, the harder it is going to be to upgrade. It also means you potentially risk your community being destroyed if one of those security vulnerabilities are ever exploited. At minimum, you should make sure you have some really good backups. But even if so... if it exploited, it could happen over and over again.

Try going into the ACP and pulling up the cron settings... see if it gives you a path to PHP8. If not, then yes... your host is most likely the best place to check with.

The cron error is most likely not related to this plugin. Check your cronjob... it's most likely set to the 7.x version of PHP. Your server most likely has a different path for version 8. Cron uses the CLI version of PHP which is different than what Apache uses.

What are your Spam Defense settings set to? If they have a score of 4, it by DEFAULT most likely is set to not allow the user to register. If that is the case, you can either lower the action taken for scores of "4" or add their IP address to the Spam Defense Whitelist to allow them to register regardless of what their reputation is. Just know that that their email or IP address is known to have been doing bad things elsewhere.

Is the email address or IP address used by that user blocked? ACP > Members > Member Settings > Ban Settings Typically I only see that message if the user is blocked... or if they're not allowed by the Spam Prevention System... ACP > Members > Content Moderation > Spam Prevention > Spam Defense Logs