CoffeeCake

One flares at the end, the other is mostly in the front.

I would think these are permanent (301) redirects, which should tell Google and other search engines "the new permanent address is over yonder." IPB can you confirm? https://support.google.com/webmasters/answer/93633

I asked questions about secondary groups. Can't recall if we ever found a working solution.

Fixing this involves ensuring your outbound IP address(es) for email are not used by someone else, that your email server is configured according to best practices, that you do what is required to define authorized servers for your domain, and perhaps most importantly that you don't do spammy things. This could be done on a shared server (assuming your outbound email is unique to you). The issue is that you may be hard-pressed to find a server provisioned like that. You don't want the ip address sending your mail to be the same as another site on your shared server sending out spam. Again, I think your problem is you are relying on someone who you shouldn't be. Get with one of the experienced folks on here if you want to keep on that route.

Peeking into that linked thread you provided, I think the member is asking for BB Code to be reenabled. You likely disabled it when you upgraded to 4.5, and BB Code is now deprecated. BB Code is where you do things like enter in [b]bolded text goes here[/b] to make bolded text. You can reenable this from the ACP, but it will be going away in the future. With regard to your member having to log in, I'd suggest that's a cookie issue if it's only that single member. Does it happen on all web browsers for them?

This isn't something you can do out of the box, but the following plugin gets you somewhat there. You can put posts with external links for new members into the approval queue, for specific usergroups.

You're never too old to learn! There are lots of online courses available for free, such as MOCs and such that teach all the things you'd need to know about these things, and most of what you'd need is a set-and-forget thing. You seem to have two big issues: AdminCP issues with Cloudflare (you should disable caching for your AdminCP in Cloudflare using page rules) E-mail being flagged as spam Your server guy, whoever he is, blaming IPS for the spam bit is a really good sign that your server guy is worthless. Replace him. A rock with a painted face and googly eyes would be a better investment. E-mail is flagged as spam by providers because you've been blacklisted, or because someone on your shared hosting has gotten you blacklisted. You may have gotten blacklisted by having a hacker exploit the send via e-mail vulnerability that was patched in the later 4.4.x series, though, to be fair to server guy. Isolating yourself from other sites is your only hope here. Amazon SES isn't supported through an API, so you need to use the SMTP option. Search the forums here for more on this. We don't use Amazon, so I can't speak to what's required, but lots of folks have asked for API integration. It's just not a feature of IPS at this time to configure the way you'd expect, but it can be done using SMTP. This can be done on the server (if that's what server guy is comfortable with) by routing mail sent to the local machine to Amazon SES, or more easily and quickly by plugging in the necessary values into the IPS AdminCP. If you tell this all to server guy, and he charges you, tell him he owes me $50.

I think the solution is rather straight forward. Go with what you're comfortable with, sized adequately to what you need it to do, or educate yourself to the ability you're able out of relying on this person so much.

MariaDB is fully interchangeable with MySQL in terms of IPS. You should have no issues. Check your host with the IPS4 compatibility tester before proceeding. Here are the minimum versions required (from the client area download): PHP 7.1.0 or above (7.3.0 or above recommended). MySQL 5.5.3 or above (5.6.2 or above recommended). Here's the IPS4 compatibility checker: For the MariaDB versions that correspond with the above, see: https://mariadb.com/kb/en/mariadb-vs-mysql-compatibility/

You can disable two-factor authentication temporarily by editing your constants.php file and adding the following: \define('DISABLE_MFA',true); Additionally, I would check the time on your server. If the time and date are off by too much, that would make it stop working. For constants.php documentation, see here:

Yes, the number of days constituting "new member" is hardcoded, presently to 30 days. If you wanted something other than 30 days, you'd need to work that logic out yourself in the theme or create a plugin that hooks into the joinedRecently() stuff.

There is also the possibility that it was fixed then and returned to being broken now. I get errors on all the links I've tested today.

If you are sending using local smtp on your server, check your smtp mta's logs to see what protonmail is sending in response to e-mail requests. If you're using a third-party SMTP service, look into how to see mail logs via your provider. As @bfarber mentioned, you'll want to verify your server isn't on any spam blacklists, and that you have setup correct DKIM/SPF/DMARC records. https://mxtoolbox.com/ is a tool out of many that you can use to validate all that. Start with your logs first.

I agree, @Runar. Support ticket was #67332. I noted that it may be a load balancing thing then. I don't permanently accept security warnings to bypass them, and when they told me they couldn't reproduce, I tried again then and the links worked without any errors. These links are everywhere in older posts, and I provided this link in the ticket: https://invisioncommunity.com/search/?q=community.invisionpower.com&quick=1

I noted this issue in a support ticket (specifically, the SSL warnings), and IPS couldn't reproduce it. Edit: It appears to happen sometimes. Not sure what the infrastructure is, yet if there's load balancing happening, it may just be a badly configured node.

Hi Bob, I think you're asking how to forward mail sent to bob@home2000.com to a Gmail account (just for illustrative purposes, I'll pretend your Gmail address is bobsnow@gmail.com). In order to do this, you'll need to first determine what your MX (mail exchange) DNS records are set to. Looking at your domain records, it appears that your domain is currently set to use SiteGround as your mail provider. You'll need to work with them to set a forwarding address that will take received e-mail and forward it to your Gmail account. Alternatively, if SiteGround provides you a way to access e-mail via POP3 or IMAP, you may be able to connect to your SiteGround account via Gmail's built in email checker. For instructions on how to set that up, see: https://support.google.com/mail/answer/21289?hl=en All of this would happen outside of the context of your IPB installation. Your best bet is to reach out to SiteGround for assistance on accessing your mail via IMAP or POP3. You can then use those instructions to set up your Gmail account per the link above.

After looking for this, I determined through careful testing that if I unplugged the server, I stopped seeing the message.

I'm not sure what options CIC customers have, but there is a way to override the default error/upgrade page via a setting in constants.php. For those expecting their site to be moved, it might be nice to create such a page for your members and those who happen upon it to make it appear less.... install-y. I'm not sure if this works when conf_global.php is missing and it thinks things need to be installed from scratch. I suggest this incorporated into these pages: If you can do it, here's how:

I'm sure the support folks will be in touch shortly. For non cloud future time travelers, do what the error message tells you.

Are you on Community in the Cloud? This is the message that happens when the file indicated is not available (or readable) to the web service. If you are Cloud customers, you'll want to open a ticket.

The reason you're seeing Move there is because you're looking at threads (collections of posts), and not at posts within a thread. The behavior you were expecting is exactly how it works for moving threads. Imagine a thread about military uniforms in a forum that's supposed to be about military vehicles, instead of the military dress forum. You could move the thread into the correct forum (and optionally, leave a link in the forum the thread was moved from that will be erased in 30 days to help folks find it). The hierarchy, from smallest to largest, is as follows: Posts (what I'm typing in now) Threads (collections of posts, in our case here called "Moving a Post" that contains all of our posts) Forums (collections of threads, in our case here, this thread is currently in the "Feedback and Ideas" forum, which is a child of Sales, Feedback, and Information category-type forum) You can move forums from within the ACP. This works by dragging and dropping forums in and out of parent and children containers. You can move threads from one forum to another, anywhere within the hierarchy of forums you've created from the ACP. Out of the box, this is referred to "Move" and is what you had in your screenshot above. You can move posts from one thread to another (or create a brand new thread consisting of the posts you're moving). Out of the box, this is referred to as "Split" and is what we were looking at earlier where you wanted to move a single post or subset of posts from a single thread into another. Hope that helps!

Understood, @Hockey Dad. Still wouldn't touch it for this with a 10 foot pole. There are too many points for failure. I don't know what the size of your database is, but if it's anything larger than empty, you'll get better performance creating a backup on the source MySQL server, moving that dump file to the destination MySQL server, and then restoring the database on the destination server. It's also a good opportunity to ensure that your backup/restore process in the event of failure is sound. Make sure that you use the correct collation when creating the backup file, lest you find yourself with a lot of broken emojis when you restore. You want it to match the collation set for the database currently.

As I shared prior, we caught this issue in our vB conversion and handled it by altering the conversion script. Our approach to the migration was to stand up an environment to quickly run through the conversion over and over again, test it, identify issues, and implement fixes. We had many, many more hidden items than what you're dealing with. Were I in your position now finding this after the fact, I'd make a copy of my production environment and work to develop a SQL-based solution to fix it that I'd test in a test environment and validate before running on production. I might even open a ticket to ask to make sure that my logic was sound and wasn't missing anything, with the understanding that this was an unsupported thing I was about to do. I think whatever time commitment it would take to do that has to be less than the time it would take to manually address 17k worth of posts. So, good time to brush up the SQL skills. 🙂 From my understanding, you'd be dealing with posts, with threads that contain hidden posts, and possibly with search results. I'd search for "queued" in the source code and go from there. Don't forget blog comments if you had those too. Posts are the easiest. Threads you need to consider whether or not to hide the thread based on first post being hidden, updating the thread_queuedposts/thread_hiddenposts/thread_lastrealpost columns with accurate info, and maybe some other fields in there--not sure without digging into it myself and I'm about to walk into a meeting. Search, I have no idea off the top of my head, but... maybe a rebuild of search index fixes everything. 🙂

Agreed. You should be able to select and take action via mod tool bar on items where ever you can see items, including search.