Matt

It's just meaningless clutter.

The question comes up now and again, but it really doesn't get a lot of traction from fellow Invision Community owners. You can share the post permalink via the three dot menu, or by the post time link.

We're keen to keep visual noise to a minimum and let the post content be the focus.

What would you do when posts are deleted? Renumber the posts so that "check out post 4 with the answer" no longer points to the actual answer (it's now post 3) - or leave gaps in the numbering so it's obvious when content has been merged, deleted or moved?

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.

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

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

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

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.

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.

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.

Thank you, Matt for coming to the rescue. 
I unfortunately don't have knowledge deep enough on these sorts of issues to understand fully how it happened, but hopefully others reading about this dilemma will not make the same mistake I did. 

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.

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

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. 

I don't think that number of views is a particularly useful metric and doesn't reflect how beneficial the topic may be.

Also, which guest page caching, the topic view isn't entirely accurate and will only accurately count member (logged in) views.

I don't think that number of views is a particularly useful metric and doesn't reflect how beneficial the topic may be.

Also, which guest page caching, the topic view isn't entirely accurate and will only accurately count member (logged in) views.

I don't think that number of views is a particularly useful metric and doesn't reflect how beneficial the topic may be.

Also, which guest page caching, the topic view isn't entirely accurate and will only accurately count member (logged in) views.

I don't think that number of views is a particularly useful metric and doesn't reflect how beneficial the topic may be.

Also, which guest page caching, the topic view isn't entirely accurate and will only accurately count member (logged in) views.

I don't think that number of views is a particularly useful metric and doesn't reflect how beneficial the topic may be.

Also, which guest page caching, the topic view isn't entirely accurate and will only accurately count member (logged in) views.

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. 

yes there are files
i will try thanks

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

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

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.

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.