Morgin

It’s easy, but man, I would never recommend to anyone who values their time and having a secure server to run their own mailserver. It is not low maintenance. 

It’s easy, but man, I would never recommend to anyone who values their time and having a secure server to run their own mailserver. It is not low maintenance. 

Works not only with WordPress 

Could open source this with a git repository that anyone inclined to assist could contribute to. I have none of the skills required to do anything technical and all I can do is cheerlead. Frankly I also like the default skin save for some decisions about how big text and other elements are on mobile/tablet which is why I run at 75% zoom on mobile, so not a huge vested interest either. But clearly there are a lot of people who want a default skin that is far more flexible for their needs, and there is absolutely the talent here to help. Doesn’t seem like a candidate for a paid exercise, but something the community will need to figure out on its own. Ultimately, maybe providing a working framework that can be compared to what Invision provides and makes the case for certain changes. Would love to see that sort of collaboration. Can also happily assist with any grunt work lower skilled tasks if they are needed. 

Your cache level should definitively be Standard, the default setting. Using anything else will break IPS' cache busting feature, which is needed to recache static assets.
Cache TTL can come down to a matter of preference. Considering important resources like CSS and Javascript assets are cache busted as needed, it's safe to use values up to even 30 days if you so wish.
The potential concern with this is, if image attachments are deleted but left embedded into posts as an example, they will still display as cached in the users browser for however long you set this to. So, it can be a minor privacy concern, as IPS currently does not automatically remove image embeds from posts when attachments are deleted from the users control panel.
That's really the only thing to keep in mind. Otherwise, I recommend at least 7-days personally.
 
Outside of these, there are several useful features Cloudflare provides that I recommend taking advantage of.
Note, some of these features are Pro only, but if you're a Free user, use the ones that aren't. They help if even a little bit and there's no reason not to.
Now, if you have a high traffic website and you can afford it, I personally believe it's worth upgrading to the Pro plan.
 
But to get started with the optimizations, under the Speed tab, go to Optimization and make sure these settings are enabled.

Polish with WebP enabled can be hugely useful if you have a lot of PNG attachments / avatar uploads on your site, as WebP can provide substantially better lossless image compression compared to PNG.
Auto Minify is disabled by default and you should enable it. The actual performance improvement is small, but it's still an improvement with no risks, so there's no reason not to use it.
Brotli, again, small improvements, but no risks and and no reason not to use it for clients that support it. All the overhead involved in performing the compression is handled by Cloudflare here after all.

Enhanced HTTP/2 Prioritization and TCP Turbo are again zero risk performance improvements and if you have access to them you should enable them.
Mirage can be great in theory for mobile browsers by automatically optimizing images on slow networks. It's in beta, but I do definitely recommend enabling this. Roughly half the of the internets traffic today is mobile. These optimizations can yield huge benefits to your users.
Rocket Loader I do not recommend enabling, as it can cause functional and perceptional issues with IPB. It makes things look and act in strange ways, and can potentially just break things. Rocket Loader is one of those things that works well for some sites, but is awful for others. It's not great for IPB in my experience. I say the same for PageSpeed JS optimizations and so on as well.
Under the Network tab, make sure these settings are enabled.

All of these are, again, zero risk performance optimizations. No reason not to use them.
Argo tunnel can potentially be useful as well, but note that it can be extremely expensive depending on your bandwidth requirements. It's an additional $0.10/GB of bandwidth. Do not enable it until you have at least a months worth of bandwidth analytics logged from Cloudflare so you have an idea of how much you can expect to pay if you enable this feature.

Could open source this with a git repository that anyone inclined to assist could contribute to. I have none of the skills required to do anything technical and all I can do is cheerlead. Frankly I also like the default skin save for some decisions about how big text and other elements are on mobile/tablet which is why I run at 75% zoom on mobile, so not a huge vested interest either. But clearly there are a lot of people who want a default skin that is far more flexible for their needs, and there is absolutely the talent here to help. Doesn’t seem like a candidate for a paid exercise, but something the community will need to figure out on its own. Ultimately, maybe providing a working framework that can be compared to what Invision provides and makes the case for certain changes. Would love to see that sort of collaboration. Can also happily assist with any grunt work lower skilled tasks if they are needed. 

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

Come on guys, Invision is never going to please us all. And even if they adopted granular ACP theme adjustment tools same as Xenforo has, we'd still need to sit back and adjust dozens and dozens of margin, padding, line height and similar parameters to suit all of our individual tastes. And then you have the menu, which in my view should be docked in an object that can be bound to the DOM either on the server or in a CSOM. But, even if Invision did that, we'd still need to position it ourselves, and move it around depending on the app currently in use. So I say, be careful what you wish for as even though I'd like to see pages that are rendered a little more tightly and menus that break from the current paradigm, you can bet if Invision did that, we'd still be back with another set of demands next month.
So how about we get together, put our hands in our pockets and see if we can find a designer come dev to create a configurable theme for us - and I mean a theme, not a (wanit in green, blue, red?) skinning exercise. It could include all sorts of presets including spacing, fonts, menu positions and so on, including specifics for desktop and mobile. Won't be cheap, but at least at the end of it we will have something we can use to give us what we want, rather than assuming Invision can pull a theme styling rabbit out of the hat which is going to miraculously please us all. I just don't see it.
Of course, Invision are more than capable of doing this themselves. But a bit a string only goes so far, and if they do this, then all the other stuff we need like video transcoding (ok I need that 🙂 ) will get pushed to the back of the queue.
So how how about it? Put our energies into something creative?

I don’t pay IPS nearly enough for what I get from this software and the support. I suspect self hosting is not exactly a profit centre, per say! 

Oh that's right, this is what you'd need:
@media screen and (max-width: 767px) { body { zoom: 0.8; } }  

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. 

Yes, it’s my assessment that this layout is well-thought-out. (The one I commented, which was from Pages)
I work as professional web designer for more than 20 years and I customize these Pages templates all the time—inspecting every little detail, checking the flow of content in many situations and at every CSS breakpoint. 
Of course if you can’t have an open discussion and need to laugh at people just because they say something you don’t agree with, this discussion ends right here. If all you guys can do is judge a web layout in one desktop view, you know very little of web design and have a lot to learn, but with reactions like the one I quoted you are apparently not willing to. I am out. 

Once again. It is enough to compare screenshot 4.4 and 4.5. The main content (list of topics / posts) should be displayed as high as possible on the page. This was the case in 4.4. Now, I open a forum and half of the screen is taken up by useless elements and empty space.
20 years wasted. So sad... 😭

This post is... not the vibe.
There's a way to offer suggestions and offer constructive criticism versus call something "absolutely terrible" that people spent a lot of time and energy on. 

Thanks @christopher-w. I've much appreciated your input here over the last few years so would love to see what you've cooked up. Will watch for that post!

If you ever want to share any of this back (appreciating for strategic reasons you may not want to) it would be welcomed by many. Love seeing the small adjustments others make. 

None of our own CSS selectors use the .sp prefix - that comes from a third-party library we use. But frankly, the possible overheard for the browser is so negligible that it isn't even worth worrying about,

I think you should view the out of box experience as a starting point for your own personal preferences. We’ve not even launched yet and already have 12 nested scss includes, covering everything from button placement to injecting section  descriptions (selector:after etc ) when for example, core doesn’t offer the facility to add them in ACP  

We’ve also replaced the native menu system with our own custom implementation resembling the sliding menu in FB groups.
We are now working on cleaning up the native mobile experience. 

With a little perseverance you can create a very tight, functional and dare I say it, class leading experience.  
 
It would be a surprise if anybody who needed Invision’s multi app coverage chose either Discord or XF. They are chalk and cheese. 

Click the time of post. Similar to twitter etc. in that regard.

This thread is a good reminder of the diversity of users. I haven’t thought about post numbers in decades. Would never have thought some people are so passionate about this topic. Certainly a curiosity to me as to why people are so hung up on them, but that’s what makes this community interesting!

Click the time of post. Similar to twitter etc. in that regard.

Paul, the feedback truly is appreciated. With anything, there are inherent risks. You can buy anything and it can go unsupported, warranty denied, or any number of things you hadn't hoped for. The Marketplace is an inherent risk to IPS as well. Anytime there's a fraudulent purchase, a developer disappears and/or there are chargebacks, IPS bears the burden of such - financially and otherwise. When you are dealing with inexpensive resources at a 10% commission, one $15 chargeback it can take dozens of transactions to recoup the loss from that one previous transaction. The Marketplace, from a financial standpoint, is a loss leader for IPS, but it's something that adds value to the product and enhances the customer experience. So, yes, there are risks - for everyone. We've drastically improved the footprint and presence of the Marketplace for 4.5 and thus increased exposure - which ultimately, will be great for everyone. With that, however, necessitates the need to leverage tighter control of the Marketplace. If you buy an app in the App Store or Play, you don't get the source. If the developer disappears, that's the end of the app. That is the unfortunate reality that we all face virtually everywhere else. 99% of the time, the risk pays off.
I completely understand where you are coming from, Paul. Truly. You are fortunate to have the skills and desire to get your hands dirty. I do, however, have the advantage of knowing our customer base and  very respectfully - you are indeed the exception, not the norm. Most want to point, click and go. I understand the argument that has been raised: "why not have both?" - we effectively do, even if it's not quite what you had in mind. You can manually install resources and if you wish to purchase something in the Marketplace, there is nothing stopping you from contacting the author and asking for files and likewise, nothing preventing the author from providing it to you. The only caveat is it's installed through the unofficial installation side of the framework and thus unsupported. Beyond that, if the author agrees with your assessment that you should have the ability to view and alter their resources, what we've done in 4.5 should have no bearing on you. If you're asking to have it like it was, I'm afraid we have no intention of doing so, to be completely candid. Whether that changes in the future is unknown, but at this juncture, we will continue to improve the infrastructure, processes and work with the authors to create the best experience we possibly can. There will be bumps. There always is - as we speak, there's an app I can't open on my iPhone since an update - it just crashes. I've been doing this long enough to know things happen and I don't expect the developer or Apple to catch everything. Likewise, we can't predict the perfect storm in every circumstance and when we find something, we will all learn from it, do our best to ensure it doesn't happen again and rather than mask issues that bubble up outside of the Marketplace, they will be dealt to ensure other customers don't encounter the same thing.
Invision is moving in the direction that the majority of the Internet has already moved towards. Point. Click. Done. Fewer and fewer people have any interest in the nuts and bolts of things anymore. We used to have our own datacenter space long ago. I remember personally, in our earlier years, getting late night calls because a power supply failed, or one of the Cisco 6509's didn't come back after an update, or a processor failed. I know nothing about latest server hardware and I haven't had to telnet into a power strip in years... do you know why? Because I don't have or want to. 🙂 Our infrastructure is housed entirely within AWS these days. They do what they do, so we can do what we do and while they aren't perfect either... it works. That is what the overwhelming majority of customers want. Of course, if I wanted to get my hands dirty and rack a server, there are still colo providers available. If we wanted to download, hack up and mess with a collaboration and communication tool - we could, but why? That's what Slack does and I don't care what their code looks like, or what the third party developer's code looks like. It's point. Click. Done. If there's no done, they will work until there is. Again, it may not be your ideal outcome and I really do understand the mistrust, but we just can't be something to everyone and in this case, we're focusing on the things you shouldn't -have- to focus on vs carving out space for you to rack your own server. Others do that well, but we are moving away from that model and I do realize it's a big change for some. We hate to alienate or turn away anyone, we really do.
In short: I would encourage you to contact authors moving forward if you want a copy of a resource and see if that's an option, either as a courtesy or by purchasing from their site instead of the Marketplace. We are standing firm on our position with regards to how the Marketplace will function moving forward. You have my word and commitment to making that the best possible experience it can be. We will also improve communication for these types of things in the future. I think we just assumed everyone would welcome the change - who doesn't like simplicity, right? There's obviously a few that do care and we'll be more mindful of that.
Thanks again for taking the time to provide concise and constructive feedback, Paul. It's appreciated.

This means they are on an OG iPad, ipad2, iPad 3rd gen, or iPad mini 1. Basically, hardware released at latest in 2012 (and possibly earlier) where Apple only supports up to iOS 9. iOS 9 has been out of security support for a few years now  
This also means the hardware is at least 8 years old. That’s a long time for mobile/tablet device compatibility, especially given how much changed over the last decade.
Can’t support everything forever. For the software to improve, it’s gotta look ahead. I’m sympathetic given how expensive it is to update what otherwise “works”, but also selfishly glad they are not burdening this software with legacies from the past. 
And as @Charles alluded to, someone on iOS 9 is gonna find 90% of the web unusable, not just IPS. 

There is no legitimate reason anyone or any organization should be using IE. If you have users stuck on it, that sucks, but it’s akin to having users tell you they unfortunately are stuck on 14.4k dialup and find the site loads too slowly. 
IE is dead. Let it Rest In Peace. 

There is no legitimate reason anyone or any organization should be using IE. If you have users stuck on it, that sucks, but it’s akin to having users tell you they unfortunately are stuck on 14.4k dialup and find the site loads too slowly. 
IE is dead. Let it Rest In Peace.