CoffeeCake

There are a lot of moving parts to e-mail. Are you using a cronjob task for IPS tasks?

Void. You don't want to delete all traces of fraud, but rather stop the transaction.

You'll need to dig into what's going on with whatever is running on port 25 of your web server then. This may involve working with your hosting provider. Alternatively, you could use something like sendgrid to get e-mail off of your server.

@wohali, I think @Lindy is misunderstanding your question. This is exactly how we download updates--we step through the installer, download them locally when given the option, and then put the files into our production server using our deployment mechanisms. We do not have sftp open to the world, and we manage code changes via git. We step through the updater, provide IPS credentials, and then click the link (look carefully for it) that says something like "I'll upload these changes myself." You will then get a zip file with delta changes in your browser (only the files that have changes to them), and can use whatever your process is to deploy those files. Alternatively, log into the Client Area and download the suite. This will include all files (not just those changed between the release you've deployed and the latest).

Yes, this sounds like an issue with your server configuration. Can you provide a screenshot of your mail configuration within IPS ACP?

While you've got me on a rant, IPS will not use two-factor authentication for ACP access when providing support. This, while a really good idea, is required to be turned off by IPS or they cannot log in and we reach a standstill. So, this requirement has to be disabled for an account that IPS uses in the context of providing support. I can appreciate that finding a nice way for people around the globe to share TOTP tokens is a challenge, but it's not unsurmountable, and there are other great ways to confirm that the support person logging in has more than just the username and password. Edit: The constants.php guide probably could some references to where to read more about changing the constants listed there (For example, go look at init.php for details on others available and for notes on usage and associated warnings).

As @Morrigan shared, the feature is marked as deprecated. See line ~295 in init.php: //-------------------------------------------------------------------------------------- // DEPRECATED OPTIONS: CHANGE AT YOUR OWN RISK // These constants were once customisable but their fucntionality should now be // considered deprecated. // AdminCP Obscurity Settings // It was once recommended for site owners to rename the directory for security // and set the CP_DIRECTORY constant so some links still work, the upgrader can put // files in the right place, etc. While it is still honoured, it is no longer recommended // as much more secure alternatives like two factor authentication now exist. 'CP_DIRECTORY' => 'admin', // The name of the directory where the AdminCP is If we're all cool leaving this exactly as is, maybe with bigger warnings, and flashing traffic cones and such, then all is right in the world.

You may want to go to CodingJungle's web site and purchase from there. www.codingjungle.com https://codingjungle.com/articles/records/why-i-am-leaving-the-ips-marketplace-r90/

Please don't deprecate this. Hide in the docs, put up big warnings if you must, warn people that there is no additional security by doing this by itself, but please leave the option intact. Security through obscurity is the reliance of hiding things on security and is bad news bears. However, having the admin control panel in a non-standard place is one of many layers of protection, upon which moving it is not relied upon for security. Consider Magento: https://docs.magento.com/user-guide/stores/store-urls-custom-admin.html Capturing and mitigating against attempts to access the default URL serves a honeypot of sorts (we identify and isolate attempts to hit /admin which would be coming from no one up to any good), helps protect against scripted attacks, and layered with other protections, serves as a multi-layered approach to security. We secure administrative things on multiple fronts, including moving the ACP address, protecting access behind zero trust authentication, and having separate accounts for elevated administrative functions. We monitor and block traffic attempting to access known paths that no legitimate user would have any business accessing (i.e. example.com/wp-admin/, /admin, etc.), but we protect the actual administrative things as if the URLs were known to all. The option to change the ACP path absolutely should come with a big "do not tamper with unless you know what you're doing" sticker. But please don't take it away.

Did you copy the filesystem from your existing server to your test server before the upgrade? You need to restore both the files on the filesystem and the database. I'm not sure how things worked in 3.x, but with 4.x files are typically saved on disk. You might have something like Amazon S3. Again, not sure how it worked in the 3.x branch.

You can do this. In member group settings, under content, there is a "can report content" feature. It's all or nothing, meaning if you take away the ability to report content, they won't be able to report any content. There is no built in functionality to make the content of a moderator/administrator unreportable (and I'm not sure I'd recommend enabling such a thing--it may be best to deal with the abusive member's behaviors directly).

Don't use phpMyAdmin for this or any other major SQL operation. Connect via SSH and use the command line client. You can script out all 202 tables into a single command that you send at once.

Does the phpinfo in the ACP reflect the changes you made? What are your web server's settings? Have you tried switching between gd and imagemagick?

Looks like you both are using 10.5.9 from the logs provided by @DreamOn. This was released about a month ago. Have you tried downgrading to a previous stable version?

You likely installed a version of mysqldump that doesn't match the version of mysql on your server. In any case, try adding: --column-statistics=0 to the command.

Install mysqldump. Don't use phpMyAdmin for backups (or anything other than a last resort to examine a value in a database). Anything serious should be done via terminal/SSH.

Just take multiple backups, and be sure that your backup is using the correct character set. I'm not sure about 3.x, yet you need to make sure that your 4.x backups are encoded with utf8mb4. Otherwise, any emojis in your posts will be forever lost in time. This is not the default behavior of most backup tools. https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html This isn't mentioned in the above guide and probably should be. @Jordan Invision To make a backup with mysqldump, you'd want to do something like the following: mysqldump -u <yourmysqluser> -p <yourIPSdatabase> --default-character-set=utf8mb4 > mycarefullytakenbackup.sql You can never have enough backups.

Whatever you do, don't go to admin/install. 🙂

Cautionary tale: Be careful on what third-party applications or extensions you decide to purchase and depend on. Get nothing you can't live without or upgrade/support yourself if anything other than "works today" matters for you.

Along these lines, it would be nice to be able to purchase a subscription for another member, without needing anything other than the member's displayname.

Have you followed this? https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ Have you checked your hardware? Failing disk perhaps? That's not a particularly large query and queries should never crash your database daemon. Have you checked your disk for corruption/failure?

MySQL is crashing? How do you know? See: https://dev.mysql.com/doc/refman/8.0/en/gone-away.html

This is correct. Zapier is only available for communities hosted by Invision. Learn more here:

It sounds counterintuitive, but reduce the limits and make sure that everything with a limit matches. Your CDN, your web server, and PHP, as well as anything else (suhosin) that may be running on your server and interfering with uploaded files. IPS will chunk uploads into segments for files larger than your post max size. You do not need or want to set things to the maximum file size possible.

Your server is likely underpowered and/or needs its configurations optimized. MySQL server goes away errors are typically related to timeouts. Timeouts happen when things take too long, and things take too long when they're not optimized or overloaded. You may consider using elasticsearch instead of MySQL for searches if the size of your community makes sense for that. Work with your web host to diagnose or take a look at some of the third-party providers that do this work for you if you cannot. https://invisioncommunity.com/third-party/providers/