Rikki

We have some ideas on making blocks and pages more flexible, though they are in their early stages. As things stand right now, custom templates are your best approach, but I certainly hope we can provide something more intuitive and robust in future.

We have some ideas on making blocks and pages more flexible, though they are in their early stages. As things stand right now, custom templates are your best approach, but I certainly hope we can provide something more intuitive and robust in future.

We investigated this and it turned out to be a bug whereby daily/weekly digests were not disabled when the link was clicked. The fix will be in the next release 🙂 

We investigated this and it turned out to be a bug whereby daily/weekly digests were not disabled when the link was clicked. The fix will be in the next release 🙂 

I have logged an internal report for investigation because if that is what is happening, it isn't intended. The link should stop all emails without any further action.

I have logged an internal report for investigation because if that is what is happening, it isn't intended. The link should stop all emails without any further action.

Thanks. Good to know, I actually read and you are right Google requires it 😐
Crap, without bg, button looks more "cleaner"

I hate being a perfectionist 😛 

We all agree 😂 Unfortunately your mockup is pretty much exactly one of their "no, you can't do that" examples

https://developers.google.com/identity/branding-guidelines

Google has strict guidelines about how their logo shows on social sign in buttons, so we're following those guidelines - in the past some customers received automated warnings that they were not compliant.

font-display: swap won't really give any benefit to that particular font since it's used for icons - there would be no system font it can use temporarily. We can certainly experiment with font-display: block and see if that would improve how lighthouse sees the page though.

font-display: swap won't really give any benefit to that particular font since it's used for icons - there would be no system font it can use temporarily. We can certainly experiment with font-display: block and see if that would improve how lighthouse sees the page though.

I'm not familiar with how MathJAX works, but it sounds to me like you'd need a plugin that listens for our Javascript events to reinitialize content when the page updates.

The reason is essentially that it'd be a big undertaking for us to update to FA5 for relatively little benefit for most customers. Some people (like yourself) would obviously have more need for it, but on the whole the cost/benefit of upgrading is minimal. They do have a migration script but again I'm not convinced it's worthwhile to include that on every site.

I think this boils down to understanding appropriate scope for services. Invision also does not support standing up and configuring apache, nginx, mysql, postfix, exim, iptables, or most fundamentally, PHP for stand-alone installs.
There are a lot of moving parts to self-hosting, and much of the responsibility of standing up an appropriate environment will come down to your team. That said, some general guides on configuration requirements (as an example, no assistance compiling or installing PHP, yet IPS gives a list of required PHP extensions) may be useful. In our implementation of Redis, we didn't need anything like that to get up and running.
You've identified a knowledge gap that you and your team have, that your hosting team can't fill in for you, and that IPS doesn't have an offering to assist with filling. Great news: Redis is an open source, highly utilized solution, and there are many resources online to help get you up and running and using Redis. A quick search found a number of guides, videos, podcasts, and walkthroughs to help you setup and use Redis.
If you don't want to fill this knowledge gap, you might be better served with finding a hosting company that will provide and maintain these things for you. The most obvious solution would be IPS' own hosted community offering. They'll take care of everything for you, and you're paying for that level of support.

In version 4.4 you had a dedicated share link easily accessible on posts, which you've now moved within the ellipsis menu. 
When you clicked the share button in the previous version it would open the share dialog and the link text would already be selected so you could quickly copy it, this no longer happens.
So two suggestions: 
When you click the share link in the ellipsis menu, please auto-select the link text Bonus: add a "copy to paste"-button next to the input field 

I would like for the embeds to contain a reference to the author name of the embedded content as before. In the previous version this would be contained within the title ("X replied to …")
I understand you currently reference the author with the avatar, however this is not enough information in most cases to understand who the author is. 
I hope you can consider adding the author name to these embeds, as it's something I've received feedback on from members, and I think it can be placed together with the date of when it was posted. 
For reference, example of embeds as they look now: 
In previous versions this was the look of embeds:


 

I’m a Luddite...62 years old and retired from a career in Commercial Art; specifically graphic design. No industry went digital as fast and as completely as the graphic design field. We went from building mechanicals on drafting tables to using computers and Software overnight, starting in the mid 80’s. I developed a severe case of Upgrade PTSD. Back then every upgrade or update of OS, and design software, was wrought with issues. Files wouldn’t open, fonts wouldn’t work, it was always a cluster, and work flow was impacted. We learned to hate Upgrades,
So, in addition to living in the woods of a Maine with extremely glitchy DSL “high speed” internet at a whopping 7 mbps...that’s not a typo. I put off IPB Upgrades and typically ask Support to perform even the most minor ones.
Recently I found myself 15 Upgrades behind...with no SSL Certificate...and my Board of 19 years...again not a typo...(I launched my Discussion Community back in 2002 on Ikonboard) was experiencing all sorts of errors and issues. 
I finally contacted Support, and they were responsive and professional and they resolved the SSL Security situation, and the Upgrade(s), and moved my Board to the new Cloud II Server. There are some minor Member issues to work out, and I’m becoming accustomed to the new features, look and functionality, but generally things on Board are snappy and going well. 
For someone who isn’t as fluid as many here with the backend of the IPB Suites and Software, and suffers from Upgrade and Digital PTSD,  having the Support team on call is a huge relief. I’m not putting off Upgrades any longer...I promise.

The date in every post provides a direct permalink to the post. Incorrect post numbers based on a user's individual permissions would certainly present more of a usability issue for both disabled and able-bodied users.
It's absolutely fine that some people would like to have post numbers back - we understand people don't always like change - but please let's not try and justify it as being a legal requirement.

In 4.5 we've tried to keep headers consistent, so that buttons are where you expect them to be, there's space for additional buttons as each page/app might require, and so that each page/app can extend the data shown in the header without the whole thing breaking down. In 4.4, this was a problem - sure, on perfect example pages, the follow button worked well in the top right. But using a different app where more buttons need to be shown, or even just having a long topic title, suddenly it wasn't so pretty and usable. The new header is designed to be flexible and extensible according to requirements.
It's pretty easy to take one particular page and find criticisms - but remember we are designing a suite where each page might have some shared functionality and some unique functionality. We have to design components that can work well in more than one perfect scenario. 

Someone deserves a raise! 
I'm working on an upgrade to 4.5 now where I'm updating a custom theme, and as a result I saw that this bit of feedback has finally been resolved 😄
Sorry for the bump, but I had a slight squeal of joy as I saw this, as it has been one of those annoying little pet peeves I've had with the default theme for some years now. 

The 4.5. version revolutionised the forum world imo. It is the best. They really did a wonderful job.

We did away with our heavily customized forum skin and just went with the default, with our own header and footer added. Then I changed the colors of that skin to make a dark version. It required a few lines of code in custom.css and it's not quite finished, but the results are really good. This is the best our forum has ever looked, and it's also the lowest-maintenance its ever been.
The integrated GIFs, little changes like the rounded border around the reactions display, and other subtle improvements have made this update really nice. My community site feels lightweight, responsive, and alive. It definitely feels more like a "social community" than a boring old forum.

It would be really nice to note somewhere when a patch is released, even if it's a sort of opt-in thing, buried twenty levels deep, as to continue giving the impression that everything is fine in the "oops" hours following a new release.

Otherwise, you're left with one of two choices:
Unnecessarily clearing cache to see if a new patch has been released, which for a large community may have the impact of undoing mechanisms for caching resources that don't need to be uncached, slowing down stuff, and increasing bandwidth. Going crazy when something that does affect you doesn't work, trying to determine what's happened, eventually getting to the point where you clear cache, and then seeing that there was a patched release some unknown time ago that may have rendered the past hour of running about with your hair on fire unnecessary. I'd subscribe to a mailing list (or forum here) that featured alerts like "for those of you using Stripe and Commerce, a patch was released today that addresses edge case scenarios where payment is made in Reptilian Kettles, but your Stripe account is set to Grecian Germaniums as the default currency, and the transaction amount is between 46 and 47 parsecs, adjusted for inflation. If this applies to you, run the support tool or download an updated package from the client area." Maybe this applies to two IPS clients, but when it impacts them, it's really an issue for them. I think @SJ77 deals entirely in Reptilian Kettles.
Even having an option to check for new patches without clearing cache would be a welcome addition.

I'm really sorry you're taking this so personally @Malwarebytes Forums - the intent wasn't to vilify or offend you and I apologize for coming off snippy. I also apologize for misunderstanding the second component to the feedback - placing the actual post ID number from the database in the post.
I can understand, from your perspective, you're simplifying things for yourself and staff. Fair enough if you're able to remember ID numbers (I'm impressed to be honest.) From our perspective, it's far more end-user friendly (and if end-users aren't happy, none of us succeed) to provide a link (and you can prevent that from embedding if you'd like) to content, so a user can bookmark the content, re-share it for peer-to-peer based purposes (which is often a strong point of support communities), etc. The references to Twitter and the "rest of the web" were simply to illustrate a sense of familiarity to end users. Nothing I'm familiar with outside of legacy forums handles or references public facing content in such a manner - blogs, social media or otherwise.
I certainly did not refer to you (or anyone else) as inconsequential. I was clearly referring to the number itself. I realize now you personally were not talking about arbitrary in-line numbers that are in fact subject to change, but while the number is no longer arbitrary, it's still nonetheless not user-friendly if you have a 30 page topic and are told "see post 390."
I digress and am happy to concede that we simply disagree and that's ok. To address others' point "let us choose" - we'd love to accommodate every request vs an on/off setting, I'm unsure why there's a limited perception that we strip things out just to alienate folks. The reality is, everyone has their own "thing" and unfortunately, accommodating them all leads to a bloated management interface, increased development time via implementation, maintenance, etc. -- a "simple" setting doesn't seem like much on an individualized basis, but cumulatively it adds up, so we have to prioritize and we don't do so based on our own personal preference, but based on the demand of the majority. As I've said, our majority prefer moving forward and thus, software real estate is reserved - so-to-speak - for that purpose. Fortunately, the Marketplace is intended to accommodate things like this and to alleviate concern in that regard, no, we would not reject a resource that put this back. There's no performance overhead or functional backend issues. Mere cosmetic re-introductions are permitted.
As noted in line number 1 of this post (post number TBD after submission) in topic ID 457939 (I kid, I kid! Too soon?) - I do apologize for the seeming hostility. You're right in that we needn't agree on subject, but I don't want you to feel disrespected personally.

In 4.5 we've tried to keep headers consistent, so that buttons are where you expect them to be, there's space for additional buttons as each page/app might require, and so that each page/app can extend the data shown in the header without the whole thing breaking down. In 4.4, this was a problem - sure, on perfect example pages, the follow button worked well in the top right. But using a different app where more buttons need to be shown, or even just having a long topic title, suddenly it wasn't so pretty and usable. The new header is designed to be flexible and extensible according to requirements.
It's pretty easy to take one particular page and find criticisms - but remember we are designing a suite where each page might have some shared functionality and some unique functionality. We have to design components that can work well in more than one perfect scenario.