Randy Calvert

Put a phpinfo file in the same folder as your IPB... I'm almost willing to bet it will show the 7.x is going to be showing when it should be an 8.x. Take a look at the following cPanel support thread: https://support.cpanel.net/hc/en-us/community/posts/19139644116119-PHP-ea-php73-website-looking-for-ea-php70-session-data This is something you need to fix on your server/host itself, not within the IPB software.

This is not something support can assist with and is generally highly discouraged. There are TONS of interdependencies that link topics with posts, that are associated with other actions, etc. Those interdependencies can cause unintended consequences if you are manually adjusting the database. In addition, your site has new posts that are happening since the restore was complete. Let's say back in January, the last topic ID was 1000. The next topic in Feb would have been 1001, 1002, etc. Well... since that restore, the activity after that restore is now getting those IDs. Meaning IDs would be mixed up, and lots of things would not match up the way they should. With that said, you can try working with a 3rd party resource author to help with this, but just realize it's not a simple operation. It also means you may have things not working exactly as they should and that IPS itself would generally be unable to assist should something go wrong. Basically you would be in a situation where you have to restore that database again from the last good backup and lose even more content should the worst case happen.

You can limit the areas of the ACP that they can access by making them a Restricted Admin. Check out the following guide:

Font Awesome does not have a ticktock icon until version 5.13.1. https://fontawesome.com/icons/tiktok?f=brands&s=solid IPS still uses the 4.x Font Awesome in the 4.x IPB software. They're not planning to update FontAwesome versions until the 5.x IPB software. So it would require adding a manual SVG.

Yes there is. https://www.febooti.com/products/automation-workshop/tutorials/enable-google-app-passwords-for-smtp.html Google made this a requirement a few years back. All new instances require it. They’re slowly going back and requiring legacy deployments to use it. This is not an IPS issue/setting. All IPB can do is pass the request to Google. They can’t force them to accept it. I can tell you from personal experience they can and do require app specific passwords.

You’ll need to check your server php error logs for details as to what is going on.

Yes, it should. But there should be more buttons up there as well. Are you using an account that has full admin permissions?

Are you using an “app specific password”? Your regular login will be rejected by Google.

You don’t download single apps. You download the full software package. When you download it, the system knows based on your license what files to include. Upload everything to your site.

By the way… this is a massive problem across the internet. It’s not an “IPB problem”. Ars Technica had a story about it yesterday and how this sort of activity is getting harder and harder to detect with compromised accounts. Check out: https://arstechnica.com/security/2024/04/everyday-devices-are-used-to-hide-ongoing-account-compromise-campaign/ Yes… this is a problem, but it’s not a flaw in the software. It’s a user issue. The only way to “fix” it is to either use 2FA or make users use unique passwords. There are technically other solutions as well, but they’re super expensive and are only really viable financially by very large sites such as tools like ThreatMetrix or Akamai Account Protector.

You need to download a full set of the IPB files and upload them to your site. Go back to you were with the applications listen and you’ll see at the bottom a button to install the ones you are missing.

The database name, database username, and database password can be found in your conf_global.php file. That will be what IPB itself uses to connect to mySQL. If the database user has full permissions, it should also include the ability to repair the tables owned by that user.

Repairing a database is not done within the IPB software. It's a server level activity. You may need to contact your hosting provider for assistance. A search of Google for repairing mySQL databases on Windows servers turned up the following which might help you: https://community.spiceworks.com/t/how-to-repair-mysql-database-using-windows-command-line/1014346 If you are unable to repair the database at all, you may need to restore it from a backup.

In addition, I would recommend asking unique questions… don’t use “what street did you grow up on?” for example. Generic questions can sometimes be figured out from looking at social media or other places.

It adds another layer an attacker must overcome. Here’s a scenario in which this defense would prevent: A rather large number of people use the same usernames and passwords across multiple sites. If I get a list of credentials from another compromised site, I could try them on other sites like yours and because you used the same credentials… I now have access to your account without actually hacking your site/server/IPB instance. However with another set of questions, it’s much more likely the attacker would not have access to those as well and would be stopped. (It’s possible they could if they were targeting you specifically and had lots of info on you but it would stop those “attacks of opportunity”.) Now… it’s not as secure as something like having a 2FA implemented, but it’s better than nothing!

Look at your Spam Prevention settings. If one of the settings is set to register but ban, this behavior would occur.

You will need to work with your hosting provider to see what those 500 errors are. Once you know what is going on, more advice can be given.

I personally had random performance issues with Wasabi and instances where my content would not display. I moved away from it after the 4th incident of it happening. The lower cost could not justify the availability for me.

You do realize that’s because literally everything that could be breaking your site such as themes or third party plugins can’t work? If you rename that file… the software is essentially useless. If you think it’s truly a DDoS attack, you need to work with your host to mitigate it. But your test for third party resources or themes is flawed because renaming that file basically disables those along with everything else by breaking the full software.

There is not a set date for release. However the software is not far away from release. It’s being tested for bugs by some members of the community here. So it will be sooner than later!

The product is real and it's coming. I've been fortunate enough to play with the early alpha version and it's chugging along very nicely. The new editor is sweet and the UI update is slick. There are certain areas still under heavy development. It's not ready for prime time yet, but I've seen many bugs squashed and lots of great polishing being done to the stuff they've already announced.

The IPB software is detected on that hostname even though it's not configured. Remove the index.php or disable access to the site long enough for the license reset to be done and THEN make the files available.

Yup. The major crawlers tend to come every so often and when they do, they might have several different spidering instances crawling the site at the same time.

You submitted basically the same post 2 months ago: Marc's response is still applicable... why are you worried about this? If you are self-hosted and are having issues with resources, your best bet is to block them using a WAF like a Cloudflare or working with your hosting provider to block them. If you're hosted on IPB's cloud platform, there should not be any impact from this in any way.

Take a look at the following: https://community.cloudflare.com/t/how-to-block-a-particular-ip-address-in-cloudflare-thank-you/498515