Matt

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.

Cheers Jack, I'll do that.

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.

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.

There is no 'fault' - there's just an approval process to go through, and we are currently proceeding through that process now.

I understand that. We've tried to keep everyone informed as much as possible with blogs like this. We also push this to our social media channels and do a monthly newsletter. I'm not sure how else to get this information out.

We were in beta for months, alpha for about a month before that. We've been talking about 4.5 since last year, and announced the new front end theme in April. We've been running a beta version on our own community here for months. I understand your point that you can't be expected to obsessively follow every bit of news we release, but with a major upgrade you should take a short time to investigate the changes before pressing the button. I appreciate the feedback but I think it's a little unfair to state that you didn't know what was coming and now regret it. We also have to design for a wide variety of screen sizes, so the layout has to be consistent and modular. It's easy to see a lot of whitespace on a single screen with a short topic title and few logged in actions at full screen on a 24" monitor, but when you consider this: I don't feel that there's much space to save here without cramming it into two lines and accepting some buttons will overflow.

Invision Super Groups v5.3 is the version we have this penciled in for.

I appreciate the feedback here. We're listening as always. My only request is that we keep it polite. We don't need to scream in each other's faces to be heard. If we don't reply or action the feedback immediately, it isn't because we disagree, or are ignoring what you're saying; it's more likely that we need to consider every change as a team and this takes time.

Selections should persist across pages. I’ll look into that.

Hi Dave, Thanks for your feedback! I'll dig in a little about what we do. There's generally two kinds of development. There's new features and there's maintenance. Each carries a small risk of destabilising the software. We use git for code contributions. When a developer is given the green light to either fix something, or add a new feature they work on it on their localhost installation on a branch of the latest stable release. When they are done, they put in a pull request and assign several reviewers. The reviewer looks over the visual code changes (this catches a lot of logic errors) and also tests the new or changed functionality and reports back any issues in testing (this catches a lot of errors!). When all the reviewers are happy, the change is squashed and merged into the development branch. This development branch is then pulled into everyone's localhosts. This also can find issues not found in the review process. This means we have three layers of checks. Now, nothing is perfect and issues do slip by. This may be configuration based where a customer has a specific order of settings we did not test, and this produces a problem. It may also be that while it worked great on our local installs using the latest versions of PHP and MySQL, some older versions throw up issues. There's a lot of moving parts, and a lot of variables when it's released. After a release, we monitor tickets for trends and investigate them if there are multiple reports on the same thing. Quite often we will spot a problem and patch it within a few hours of it first being reported. Now that we have an automatic upgrade system which generally means you do not need to log in to our client centre, download files, upload them and so on, we can deliver updates in a very timely manner which are fast to apply. We also have a patching system which shows you any fixes that have been released since you last updated and allows you to apply them. While there have been some issues that have slipped through our triple check process, I would say that Invision Community 4.5 is very stable for such a big release. We also put major updates through a beta testing process where we encourage (and support!) early adopters to upgrade to shake out the last few remaining bugs.