CoffeeCake

What happens if you turn it off? Or, turn off combine_css? https://www.modpagespeed.com/doc/filter-css-combine

Oh! And forum rules too in ACP > Posting > Forums. You can do it there as well.

You can create an announcement in each forum that links to a common thread (or post the same thread in multiple forums and pin them individually). There's no way to assign a thread to multiple forums though.

It takes a bit of knowledge. Are you primarily concerned with it just not being visible, but okay with someone being able to right click on your community, select view source, and see the number of clicks there? Or do you want it completely hidden from the public, with no way for anyone to determine how many times it has been clicked?

You can edit it out of the template, create a template hook that removes it, or if you just don't want it to be visible (but still there to those who like to look under the hood), use some CSS to set display:none;

It's likely not this. Are you sure permissions are correct? ACP > Support > System Check

What does your browser console tell you? Any errors or warnings?

I remember replying to this. When was your last physical?

Yes, however IPS is not currently compatible with PHP 8.0. Make sure you stay on 7.x for now.

I believe this is setup at the product level. See this guide:

@AndreasW2000, if you don't mind my asking, what's motivating the desire to have search engine (or other web crawlers) identified as such in Who's Online? If the purpose is to determine the level of human traffic on your community as a community administrator, I'd suggest you'd explore some better options that exist to see these measures. If the purpose is for your membership to know this information, I might be helpful to talk a bit more about your use case here. As an administrator, I'd recommend using a third-party analytics package such as Google Analytics. It's free, can be turned on natively with IPS (ACP > System > Community Enhancements) and will show you in both real-time and historical snapshots human visitors vs. automated traffic. The data presented here is going to be far more accurate and insightful than any efforts to visually monitor the Who's Online page. No, this simply means that there won't be session data stored, and the overhead of creating/updating that session data in your database or Redis. Doing this would improve your site's speed and performance for things accessing your site that aren't logged in. Presumably (though I have no idea) these changes would apply to all non-authenticated traffic. It would not block or prevent them from crawling your site, nor viewing the content. Just an under the hood optimization.

Not natively, unfortunately. You could restore from a backup, but then you lose any changes between now and the time the backup was taken, or manually recreate the member. All of the member's posts and other content will now be associated with no account (guest). Beyond that, you'd be delving into a dark journey into recreating SQL rows and foreign keys, and that's outside of the scope of what would be safe for a novice to attempt. If you have a backup to compare against, that would probably make this easier to attempt.

Bottom line for us, holding moderators and members accountable, and to quickly see what was changed, by whom, and when it was changed. There are many different reasons why we'd want to do this. The edit history setting is one that's configurable per install. It's an item we need and want, and realize that others may not have a need for it. For those that have edit history turned on, it would be nice to be in line with the Jones who use Xenforo and vBulletin and see specific additions/deletions/changes highlighted in an easy to view way between different revisions.

Noting that this is a feature of Xenforo. I've got no issue resorting to pointing out competitive gaps 🤓: https://xenforo.com/community/threads/post-edit-history-and-logging.46726/

Yes, though @Stuart Silvester promises insane improvements. I'd need to see it myself first to believe it, that's how scarred I am from the experience. 😅 There is no support for partial conversions. You can't convert the first million posts and then go back and finish off the rest. Would this be nice? Yes. But... if they managed to get this down to a few hours of downtime, then great news for you. This means you have some choices in how to approach this. Our approach was to develop modifications to vBulletin to essentially create a "read-only" mode, make a snapshot of the vBulletin database at that point that would be our source copy for conversion, and then run the conversion on that snapshot in a separate migration environment from production. We had separate migration specific MySQL instances that were tuned specifically to perform as efficiently as possible to the migration, and removing any and all external load from slowing things down. We announced our planned migration window well in advance, had established a solid estimate for the length of time it would take, and kept members informed through a status page of our progress. Our production servers continued serving out vBulletin in read-only mode for the length of the migration, until we were ready for the switch over. Our cutover involved swapping out the underlying VMs, so after confirming everything was ready to go and all of our tests passed indicating as best as we could assume success, we redirected our IP traffic to the new IPS configured VMs and began serving out requests from our new production IPS environment. This resulted in minimal downtime of our content, though had the unfortunate impact of having to be in a read-only mode for the duration. We could have left vBulletin in full operation, but all changes that would have been made after we took the migration snapshot of the database would have been lost, and we determined that this was not acceptable for our case. I would not do this. I would only work with complete copies of your vBulletin database. Because of the layered approach the process takes, you can't be sure that things end up correctly until the end. If you want to create a sample of vBulletin data and then run migrations on that to just confirm a test to test conversion, that may be a good idea, yet I would early on start using copies of production. Every time we ran another test migration, we started with the exact process we'd use and take a fresh snapshot of prod. This is exactly the process we used. Don't overrely on your members though, and encourage them to report anything that seems off. Many of the issues we found that our testing members did not find were things they assumed were supposed to change. Make sure you include members with long histories on the community and new members, and that you have representative samples from all of your usergroups if there are varying levels of permissions in your implementation. And! Don't forget to test e-mails and make sure that test e-mails don't go to your members. We had a special process for redirecting all outbound e-mail from our test and migration environments into a viewer that allowed us to see the contents of those e-mails and make appropriate changes. There is a constants.php setting you can set to ensure that e-mails go to /dev/null until you're ready for that.

You can create a custom activity stream that only includes the type of content you want, and set it as the default for the community. You can also restrict the ability for member groups to make custom streams if you need to.

Here's how it worked in the days of yore:

Prior to whatever optimizations were made and before the release of 4.5, our conversion took about 4-5 days (I think, from memory?) to get to the point where we reopened the community. At the time, we had about 7 million posts (text only, we don't use images or attachments) and 500k members. We allowed the post rebuilding to run for a bit (it goes from newest post to oldest) before reopening the community as things looked absolutely wonky for a bit, and kept our membership informed well in advance of beginning and throughout the process. How nice to hear that this got much needed attention. We documented and scripted and tested the process over and over again on a test environment taking snapshots of our production vBulletin install and going through the conversion process again and again. This helped us identify bugs in the conversion process (though, regretably there were some we didn't identify until after we had migrated the live site as there were features of vBulletin we didn't have in our test plan, but many members were using to our surprise, and a rather large snafu with the handling of private messages, which has now been fixed in the converter, but was bizarely designed to just remove the entire private message if any participant in the message had deleted any part of the conversation on their view). We also made optimizations that made sense for our use of vBulletin, and changes that migrated over modifications we had made to vBulletin to their IPS counterparts. This also helped us nail down a solid approximation of how long it would take by repeating the process over and over on identical infrastructure, until it was a well choreographed dance. To address the travesty of the web-based conversion, we stood up a client machine within our infrastructure and used a remote KVM to control it. This was the most absurd part of this process, but.... hey, if it's 60 million posts in 1.5 days now, great. We are entirely virtualized and increased the specs of virtual machines until we saw no change in performance. It was very iterration heavy, so tons of queries being thrown around. I'm going to go stare at the deltas for what's been changed now, because it was painful getting it down to the number of days we did.

Precisely our experience as well. Points inform what will happen when you send it, and whatever it says will happen when you send it is what happens. vBulletin also had the ability to send non-punative warnings (we renamed the entire system, so I don't recall what the terms vB used were), which essentially functioned as zero point notes. We've replicated that behavior by assigning everything a default of zero points and are actively rethinking how we might use it better.

Edit: @bfarber came in for the win.

You'd want to rely on the username/password supplied by the end user. A custom public oauth client, not a custom confidential oauth client.

This works differently than vBulletin and got us all tangled up. vBulletin was based on points, and worked like you're thinking it should. I feel that you and I are kindred spirits. In IPB, the time is set at the time of issuance based on the conditions (number of points, settings) at the time of issuance. In your example, Matt is getting moderated for two months. I should note that Matt probably deserves it.

You are playing in dangerous territory. You should not be running your test site on the same environment as your production site, and they are now in some mixed up state. Every post in this thread you're introducing changes instead of taking things one step at a time. I'd not touch anything at this point and open a support request focusing on restoring your live site into operation. Once that's done, I'd investigate options you have on creating a separate, standalone test environment.

This is why I've nominated this for the first installment of "@Jordan Invision Jigs It!" The guide is not at the level it needs to be, and you're helping highlight that. We'll get it though. Keep calm and methodical. We'd ideally isolate these into two separate environments (two separate servers, or a minimum, two separate chrooted hosting accounts). If you're restoring your production (live) site data into a copy to create your test site, there are some things you need to seriously consider: Updating conf_global.php to make sure that you have a different database connection from production, making sure that you have a different hostname than production, and making sure that your values are correct. Use different mysql accounts for production and test, that do not have access to each others databases. Handling your member e-mails. Your test site will try and e-mail your members when the normal task processes run. You probably don't want this, and your members probably definitely don't want this. You need a constants.php in there. You should probably make sure you have \define('EMAIL_DEBUG_PATH','/dev/null'); as a minimum if you aren't taking other precautions (such as updating all of your member e-mail addresses in your test database to test values). Understanding that the files you are copying contain hardcoded references to your production site, so you will have to wipe cache (that's what you keep copying over) and rebuild it after you modify your domain in conf_global.php. Right now, you rebuild it by doing the "Something isn't working" option in ACP > System > Support. I hear that this will cease being quite so stupid in 4.6.