Matt

I definitely recommend disabling downvoting unless you have a very focused and trusting community.

 

The first paragraph was brilliant, and then it went downhill. 😂

We definitely want to add more flexibility in the future for more varied and flexible layouts. It's something we've discussed a lot internally, but it's not made it onto the roadmap yet.

Every integration point we put into Invision Community adds to the technical debt of the product. It means keeping abreast of changes to the API and adjusting our code as needed.

S3 is probably the most widely used system right now (and something we use natively with Cloud Communities). You are welcome to add a request for more to be added, and if there is demand for it then we will definitely consider it.

We are discussing this internally. 👍

Mevi, firstly I'm sorry for your loss.

I'm also sorry Senior here is already writing your obituary!

The idea of memorialising members has floated around for a while, and it's something I'd like to put some thought into.

It's something we've spoken about to extend the embed system but we do not have any firm plans at this time.

This is still the case.

Appreciate the feedback, thanks!

We're constantly looking for new ways to improve content discovery. There are already widgets you can use to show popular content when viewing a topic list but we're definitely open to any ideas.

I would also say that if your community is small enough to fit on a shared server, you probably won't derive any real tangible benefit to running Redis. Redis is great to help large sites scale up and reduce database I/O but if that isn't a problem you need to solve, adding Redis onto the same server will just take resources from other areas and you won't really get any benefit.

Unfortunately if a developer has abandoned the app or plug-in, then there's little we can do. We would not take ownership of the third party product and maintain it.

This is a good idea.

On 11/23/2020 at 10:33 PM, Colonel_mortis said:

Of the 147 members who were classified as 4 but not FASed, about 30 are likely spam accounts (based on manual classification by one of my moderators), which gives a precision of 61% (39% false positive rate) when classifying based on a score of 4.

I'd be happy to share some more detailed data with you if there's anything that you think would be helpful - feel free to reach out by ticket/email/PM(/slack), whatever is easiest.

Cheers Jack, I'll do that.

On 11/21/2020 at 5:35 PM, Colonel_mortis said:

Actually, looking further into the members who were caught by the spam service but weren't flagged as spammers, there are several who have made 0 posts (and thus weren't caught in my previous audit) but who are likely to be actual spammers based on their profile information. Based on the sample that I checked, the false positive rate is still too high to be useful, but it is not as high as I had originally thought.

You originally quoted 51% as false positives, what you do think it could be now?

Trying to capture spam is a constantly evolving process. Trends wax and wane. We tweak things to account for this but we can only do so after a trend has established itself. Given the size of your community and the number of registrations you get, I'd love to know more about your data and look at our capturing system to increase its accuracy.

Thanks for the kind words, Brad! I appreciate you taking the time to share them.

We were talking with them this week. Our approach is unusual in that there is not a single URL to push data through as its distributed software, so it's taking longer to approve. It's all positive though.

It's a little unfair to think of any app as being isolated in terms of updates.

Even though Gallery hasn't had a 'tear down' style revamp for 2 years, it doesn't mean that it's not received any updates. Simply by being part of the Invision Community ecosystem, it receives all the updates that the core gets, including UI updates, notification updates, performance updates, etc.

Quite simply we do not feel that Gallery needs a major re-invention at this time.

That's always a good tool to try if something isn't working right.

1 hour ago, Runar said:

Thank you! Any comment on the SSL issue?

That's a @Charles thing. I'm not allowed near servers, right @TSP?

Thanks, I've fixed those links in the descriptions.

Hi,

I'm sorry for the delay in getting back to you. We have been discussing this ticket internally, but we should have updated you on that so you're kept in the loop.

I've just given you an update in the ticket.

One thing to keep in mind with topic views is that with guest page caching, most guest views will not be counted. In addition to that, if you have a CDN in front of your web servers (as you would want to do, and we do with our cloud plans), then it's even less frequently that guest counts are recorded.

So while we can add the topic view count in there, it's not really reflective of the actual traffic that one topic gets.

Google Analytics is much better for getting statistical data on this level as it records every hit via a JS API.

I'm not against adding topic views in that block if it's clear what the number represents. 

No problem, it's what we're here for. 🙂 

Just for those reading, I'm working with FZ on their site.

The core issue is that the thumbnails being generated by PHP and GD are currently larger than the originals (in some cases 300% larger!), due to the image quality being set to 100.

I've been testing out various percentages and around 85% is the sweet spot and is now generating thumbnails less than the original (around 50% or less) with no real noticeable drop in quality.

100% tries very hard to preserve images, including artefacts caused by the compression of the original.

If you genuinely believe those files to be Ok (original files, and writeable) then you can add:
 

\define( 'UPGRADE_MD5_CHECK', FALSE );

In your constants.php file.

This prevents the file check from occurring.