rgf100

I need to change the URL of my test install, but get the message: "There seems to still be an installation of Invision Community at the URL on file. Before you can change the URL, you must first remove the existing installation." There's no installation at the test install url. Obviously, there is one at the actual url, but that's not what I'm trying to change. How do I change the test url?

This bit me this morning, caused a bit of a panic. What you need to do, or at least what I needed to do, was to look for out-of-date settings for session.save_path somewhere, probably in .htaccess, user.ini (in the, y'know, main folder) or php.ini (in the weird folder one up from that). As far as I can figure out, that can reference a folder that doesn't exist or doesn't have the right permissions. Editing those, or if you have access to something like Cpanel's Multiphp INI Editor, might fix it, and it seems like using "/tmp" might work if you don't know what the setting SHOULD be.

That's a good idea. I have plenty of legacy blocks hanging around which I'm *fairly* sure aren't used anywhere, but don't want to delete just in case...

I see what you're saying, and it might not always be ideal - but if they're just queued up for approval rather than published, there's scope for editing. And it's also about what people expect - if you specifically market it as 'here's our best posts, don't forget to check out the full discussion', for example, people know what they're getting. At least with my site, I think if I could get the most popular posts in front of people's noses, it'd be valuable. The occasional false positive when everyone upvotes a two word inside joke won't do much harm, and can be removed later or caught during an approval process. There's scope for bad actors to, eg, spam reputation to get their posts onto the social media feeds, but again, it's not necessarily the end of the world. No need to let the perfect be the enemy of the "really useful, and we could have had it years ago."

While people are paying attention, can I point you towards this seminal 2017 post suggesting the use of reputation information to automate / semi-automate social media promotion. Take either the X top posts, or all posts with X+ reputation, and push those to social media, or load them up for promotion to await an admin edit / approval / rejection. In one fell swoop, you've automated getting the best of your site out into the wild.

Excellent. I'm just going to keep going and we'll see how fast you can keep up. Next point: "Under first post" is not the ideal position, for the topic summary or ads, or anything. Regular member traffic is much more likely to be heading for a #comment-xxxx anchor tag and will skip right past the first post. If I remember correctly anything after the # in a url isn't available to the server, but if you could work round that and have that content appear *where the user is actually looking* it's a lot more likely to be seen.

I like the new topic summary boxes, but have a few thoughts... "TOP POSTERS IN THIS TOPIC" - it's more likely people will want to read the posts, than the posters' profiles. If there's any way to bring together the posts someone has made (perhaps by minimising other posts?) that would be good, otherwise I'd have that link to the person's first / highest rated post in that topic. The "POPULAR POSTS" bit - I'm not sure how intuitive clicking on the date is. I'd make the post text snippet clickable (and perhaps that whole div, with the userphoto / name also going to the post, although I realise this would be inconsistent with behaviour elsewhere. POSTED IMAGES - I like this, but there's no way to get from the images to the associated post. I think there should be.

The 'popular posts' bit in the new topic summaries are a step in the right direction. But there's so much more that could be done.

I'm flogging a dead horse here, but... I still can't filter a post block by number of reactions.

I actually came looking for it on a per-forum basis - I'd like to keep controversial or contentious topics in a separate forum, where users can only make one or two posts per day. In case you don't know, there is a per-usergroup daily post limit - not quite a flood control, as you could use up your quota all in a few minutes. But it'd help a bit, I'd imagine.

Just to say, I'd *love* to see this based not on days, but on posts.

Looks like rebuilding the search index fixed it, for anyone having a similar issue.

It could be an oddity in my database, although... if both methods are the same... Let me know if there's anything I can do to help.

I was going to post a new topic about this, but figured I'd bump this. Here's what I wrote: Genuinely disappointed in the lack of engagement on this. If it's a dumb idea that has been rightfully ignored for 3.5 years, say so and I'll be quiet about it. If I've missed some new option in 4.4, I'll put my hands up and apologise. Edit: AND imagine how powerful this would be with social media promotion. Automatically (or automatically queue for admin approval) post to Twitter any post that gets X likes. The site would run itself!

Quick question - I bought and installed this yesterday. I'm running into an issue with approval queue count numbers. Here's what's happening, as far as I can figure out... Say I delete the cached modCpApprovalQueueCount_X value. If I then reload the home page, your app recalculates a value 2 more than is actually in the queue. One item in the queue, it calculates 3, etc. Three items, it calculates 5. Then I go to the approval queue. Initially in the "Approval Queue / Active Reports" bit it shows the incorrect cached number. As I start processing, that number corrects itself, presumably as it gets updated by IPB's own code. If I deactivate your app, the approval queue figure is always right. Is there a difference in the way the approval queue figure and the figure for your app are calculated? My best guess at the moment is that there's a difference, and this is causing the mismatch. It's possible your method is picking up some orphaned unapproved content somewhere, which the native method avoids.