CoffeeCake

Only 17,566 to go 😁 What if you go to Mod CP > Hidden Content > All Content. Would that help? There's no sort, but you can jump to the last page and work backwards.

Sure! Go to ACP > Applications > System > Profiles and click on the permissions padlock. Disable for guests and any other user group you'd like to not have access.

You could certainly commission something. Check out: https://invisioncommunity.com/third-party/providers/ Your workaround may be to copy an existing forum with the permissions you're desiring. That's core functionality.

Welcome! You probably want to create a support request from the Client Area and ask this question there as this wouldn't be a common thing most of us would come across. My guess is that if the original install had those modules installed, you'd need to purchase and upgrade them or do something to your install prior to the update to remove them. Good luck!

I've not used the MySQL Migration Wizard before, but you probably would be better off using mysqldump to create a backup, copying that backup to your new server, and then importing that dump file via the mysql command on your new server. Details can be found here in the MySQL docs: https://dev.mysql.com/doc/refman/8.0/en/backup-and-recovery.html

Oops! 😁 Apologies, but we're an nginx shop. Glad it got you there! I've edited my original post for future time travelers.

Just a note, that we encountered the merge bug as well. Looks like an update is not yet available to fix.

The Chatbox+ developer has been very receptive to new ideas. You might reach out and ask for consideration of a "take this chat to PM" function.

Just adding an (completely untested, good luck, YMMV) nginx and apache example to get you going. Apache: RewriteCond %{QUERY_STRING} b=([0-9]+) [NC] RewriteRule ^/blog/entry.php$ /entries/%1? [R=301,L] Nginx: if ($request_uri ~ ^/blog/entry\.php\?b=([0-9]+)) { return 301 /entries/$1; }

How about creating a custom profile field asking members to self-identify for geographic locations from a list that is relevant to you and then filter based on that?

Don't do that. 🙂 That will become a nightmare to maintain over time. Instead, leverage rewrites on your web server to take your vBulletin blog paths and redirect them to what IPS is expecting. So, in your case, create a permanent redirect from /blog/entry.php?b=XXXX to /entries/XXXX. This will then get rewritten internally by the IPS handler to the new location. Any old links to blog/entry.php will still work and end up at the correct place and you don't need to modify/maintain any code. Behind the scenes, you'll have two redirects happening automatically: blog/entry.php?b=1234 -> /entries/1234 -> /blog/whatever-the-new-ips-blog-url-is-5678

Glad translating "Split" to "Move Posts" worked for you, @Elbmek! It's all about perspective, @Morrigan. The end result of using the "split" feature in all cases is that Post X goes from Thread A to Thread B. How or what steps are involved in making the determination, or in what buttons are clicked, or when Moderator Y of Community Z would typically do that don't matter all that much. If you want to put Post X "somewhere else," using the words "move Post X" is a perfectly sensical way of looking at things. Especially for those who haven't been working with forum software for decades. From a technical perspective, Post X's association changes from Thread A to Thread B--the identifier for the post is simply changed in the database to reflect the destination thread. "Change Thread ID for Post" would probably be the most accurate description. I don't think there's a "correct way" of doing things, and the translate tools allow us to customize things to what work for our individual communities. I'd hypothesize that if you asked a non-technical person with no forum experience who didn't have the background knowledge you and I do of administering forum software for many years to describe the outcome of a moderator using the split tool to describe what happened, you'd be hard pressed to find that people universally use the word "split" to describe the activity that took place. Maybe in those cases where two distinct conversations are happening in a thread and replies to discussion A end up in one thread and replies to discussion B end up in another, yet what about when someone accidentally replies to the wrong thread? In that context, "oh the moderator moved Member W's post to where it was supposed to go." I know understanding these terms are part of the training we put together for our moderators, who are typically non-technical. But the question is a good one that brings up things we might otherwise take for granted--is the right word to describe what this thing does for all communities and in most situations? Should we consider updating documentation to help make this clearer for new administrators and moderators? Are there improvements in the user experience we could make to help the person using the tool understand which tool is best for the intended action, and what choices are best to achieve the desired end result?

Either way, I think your choices are between handling them via SQL or one by one using the moderation tools in the web interface. If you choose to delete them outright, and do so via the database, be mindful of thread metadata that may need to be updated as well and actual threads comprised of only "hidden" posts. You'll also probably want to rebuild the search index.

Also, @Elbmek, you could rename "Split" to "Move" on your forum for your moderators if you'd like to do so. To do that, log into the ACP, go to Customization > Localization > Languages and click on the globe icon next to your installed language to "translate." You can then search for the word "split" and provided a translated word or phrase to make things easier to understand for your moderators. For example, you may want to change the System string "Split" to "Move Posts." Thank you for your service, and for providing your feedback. It takes a bit of a distinguished and trained eye to point these things out sometimes, and while others here may not bother with such things and accept them as they are, I think you raise a wonderful point about decisions in the user interface that could use a bit of KISS. Split doesn't do this. All subsequent posts will go wherever the poster replying decides to post them (unless you lock a topic to further replies). Split, in all honesty, just moves posts to either a new thread or a preexisting one. It does nothing more. I think IPS uses the word split here because that's what other forum software was using when it was first written, and they kept the conventions at the time. One of the most common use case scenarios would be where in the course of discussion on a thread, the topics branch off. As an example, perhaps @Elbmek has members in a single thread talking about military uniforms and then someone adds a funny picture, and a series of replies are made about the picture that have nothing to do with uniforms any more. In this case, you might want to "split" that conversation into two--keeping the military uniform discussion in one place, and the funny picture and anyone that has commented on the picture into a separate thread. In this context, "split" makes sense--the moderator is "splitting" off a series of posts. Yet, there are other reasons to move posts that will vary from community to community.

I think the confusion stems from the fact that the "split" option for moderators has two inherent functions. In the current incantation of IPS, split is the single option you'd select for the following two scenarios: Move selected post(s) in a thread to a new thread in the same or different forum; and Move selected post(s) into a different thread that already exists, regardless of what forum it's located in I think what @Elbmek is trying to do is the first option. One of his members posts a funny picture in reply to a conversation about something else, and he'd like to remove that post from that discussion and instead put it in a new thread in the funny post section of his web site. From @Elbmek's perspective (and feel free to correct me if I'm wrong), keeping things simple would involve to separate options in the moderator toolbar. One that moved posts into new threads in a forum of his choosing, and a second button that stuck posts in the middle of a preexisting thread. "Move" may be a better name for "split" in the moderator toolbar. While move exists for threads within a forum, it's got a different name at the post level within a thread. I think the names we have now are just a byproduct of the things that existed before IPS and how they worked in the past, rather than a reflection of any common sense. I've been confused by the ability to merge two posts together into a single post, even when the posts are written by different people. That'd be a nice one to turn off entirely. Good luck fixing that mistake. 🙂 To give you a simple way to do what you're trying to accomplish, @Elbmek, tick the single post you'd like to move to your funny forum, click "Split" on the toolbar, make sure "new topic" is selected, and then choose your funny forum from the drop down list. The other options in that window are likely not things you're looking for, but you can do things like set the title of the new topic that will be opened in your funny forum, or lock the resulting thread so no one can reply, etc. You shouldn't have to preselect a URL for anything unless you're putting all the funny picture posts into a single thread, in which case you'd copy the web address of the funny post picture thread and supply it for the existing thread option.

Thank you for this question. That statistics block takes an absurd amount of time to run, and having not looked in depth at it before, I've just sped up my forum homepage by a very significant amount by removing it.

What happens if you add WHERE queued = 0 to remove hidden posts? The forum statistics block will only count unhidden posts, plus any archived unhidden posts you have (if you have archiving turned on). To replicate what the block does, use: SELECT (SELECT COUNT(1) FROM `forums_posts` WHERE `queued` = 0) + (SELECT COUNT(1) FROM `forums_archive_posts` WHERE archive_queued = 0) AS `PostCount` For code reference, look at applications/forums/widgets/forumStatistics.php, in the render() function at line 46.

If you had redirect rules in vBulletin that were not the default URL paths, then the trick is to redirect from your old URL scheme back to what the out of the box vBulletin path would have been. For example, we had a custom solution in place that would change our forum thread URLs to things like example.com/forums/forum-name/thread-name-1234/. As part of our migration to IPS, we redirect that style of URL to what the original vBulletin URL would have been: example.com/forums/showthread.php?t=1234. This then gets redirected by the IPS handler to the correct migrated thread.

InnoDB uses an estimation to display number of rows for things like SHOW TABLE STATUS. This is why you're likely seeing ~XXXXXX where ever you are seeing it. It's an approximation. To get the actual number of rows in a particular table at a moment in time (forums_posts, for example), use: SELECT COUNT(1) FROM forum_posts For a bit more of an in-depth here, check out https://dba.stackexchange.com/questions/17926/why-doesnt-innodb-store-the-row-count If you were wanting to celebrate the 1,000,000th post, I'd go with @Nathan Explosion's suggestion and use the post ID of 1000000. This makes things super easy. The post ID increments with every write to the forums_posts table, so it would include deleted items in the count (and if you did anything like truncate the table when you were first setting things up--unlikely, but... including here as a caveat). Otherwise, if you want to exclude posts made in forums that aren't incrementing toward post counts or any administrative/staff forums, you could calculate the 1,000,000th post via a SQL query that excludes posts in those other forums, or those that have been hidden, etc.

I think that the Mod CP use case is the individual review of one message at a time. The scenario you're describing only occurs if you have 17,000 new posts happen within a short period of time, in which case, the typical solution would be "more moderators, still reviewing one at a time." I suppose a list of multiple messages with checkboxes to select the ones you'd want to approve (vBulletin had this, as an example) would be a nice addition, but I rather like the focus of a single post in this particular use case. Since this is a byproduct of your conversion, you'll likely want to deal with these en masse. There's no way to do this efficiently within the interface, however you can update the underlying database to mark whatever action should be taken on these 17,000 legacy posts. The query you'd use would depend on what you want to have happen to these posts. Maybe you want them all approved. Maybe you want them all hidden. I agree that better use of checkboxes and mass-moderator actions is a much needed improvement, yet for the issue you're experiencing, updating the database directly now is probably your best bet. Here's a thread where we talked a bit about this, and the different things to consider.

We handled this by modifying the conversion script when moving from vBulletin to IPS, however you could update the value of the queued column in forums_posts via MySQL to handle all of these legacy posts and remove them from the queue. Backup everything before you do so.

It'd be nice to be able use variables (like %customermemberdisplayname% or %supportstaffdisplayname%, etc.) in stock replies within Commerce support.

It's probably something in the actual code in showad.js. If something in that code overwrites something that IPB uses, then boom. 🙂

There could be places in your web server configuration as well as php. Check the documentation for whatever web server you are using. Additionally, if you use a CDN or security software you may need to adjust settings there. The limit will be the smallest of all relevant settings. Look for POST limits and upload limits.

This is the expected behavior with 4.5 and purchases on Marketplace. You cannot access the files directly, regardless if you are self-hosted or a CIC customer.