sadams101

I agree that it would be much better to restore the ability to edit CSS templates.

I agree that it would be much better to restore the ability to edit CSS templates.

As Marc mentioned, this is likely an out of date theme. Specifically, the forums > topics > topic template. If you open that template in your theme, click the Variables button and make sure it looks like this:
$topic, $comments, $question=NULL, $votes=array(), $nextUnread=NULL, $pagination=NULL, $topicVotes=array()  

Right...I think we all understand this. He's not been heard from since Jan 2021.
Unfortunately I'm unable to wait until he's back here to update this application, as I need it updated for 4.6 and php 8. Some of you may be in the same boat.
If anyone is interested in a version of this that is PHP 8 and IPB 4.6 compatible, please contact @DawPi

I don't know about you, but I'm wondering if it's perhaps overdue that IPS got stuck into a huge performance and speed based review and implement it in the next medium sized update! I think a lot has changed in recent years in relation to site performance. Core Vitals in Lighthouse as many admins will be aware are now much more important in terms of SEO ranking, performance isn't just for the obsessed enthusiasts any longer!
Google Search Console tells me that on one of my IPS Communities, my Mobile Pagespeed test result sucks, just 28%-30% at present, so I started checking a few things under the hood. I like to keep my sites high performing, so I was quite surprised it was so low. 
One thing I found out in minutes looking at the optimisation list and then checking my IPS configuration is that if you have the IPS Lazy Loading feature enabled, it doesn't apply to your uploaded images in Advertisements or Post Author Member Group Icons. Both are shown in my topic view so I get scored down on mobile in particular.
I think it's now time that Native Lazy Loading was offered, either as a choice or as the default if enabled.
Also where possible IPS should support Local WebP conversion via the Task Manager.
I know some of us sometimes bash IPS for not delivering more obvious updates like Gallery, Blog, Pages and Commerce improvements for the sake of instead quick things like disabling features but IPS4 is quite a huge behemoth these days, no matter your pricey VPS, CiC, use of Redis pools etc.
More performance improvements I'd like to see considered include...
(Now admittedly I'm basing this list on a similar big audit that another website framework I invested in conducted and implemented last year. These are the options you can now simply toggle off/on as a result in their Dashboard. They can make a huge difference to bloat.)
Dynamic Modular Framework
Enable this to allow the IPS Framework to only load code that are actually used on the page, and process the logic for the features in actual use.
Dynamic CSS
Dynamic CSS could greatly reduce CSS file size by dynamically generating only the styles and assets necessary for the features and modules you actually use. This eliminates most if not all CSS file bloat and greatly improves load times.
Dynamic Icons
Font Awesome is 2 generations behind. The FA4 icon font could be broken up into various subsets. These subsets are loaded only when needed based on the modules and features used on each page. If you need access to the entire icon font on all pages (for example, if you are using lots of FA icons in a custom theme or want to allow members to insert them via the post editor), then you could disable this option and load the entire icon font library on all pages.
Load Dynamic Stylesheet In-line
This option dequeues the IPS style.css file and prints the needed contents in-line. This removes a render blocking request and improves the PageSpeed scores of individual pages. However, it also prevents the style.css file from being cached. Since the stylesheet is often smaller when dynamic or critical, it could be recommended to keep this option enabled. Accepted there are some potential CSP-related security concerns with inline CSS an or JS.
Critical CSS
Critical CSS greatly improves website load times and Google PageSpeed scores by deferring non-critical styles and eliminating render-blocking CSS requests. Critical CSS often covers what most users see when first loading the page, so called 'above the fold' content.
Critical Threshold Height
When Critical CSS is enabled, IPS would determine an "above the fold threshold" and defer all styles for elements below the fold. However, this threshold is just a estimate and can vary on different devices. Increasing threshold height will deffer fewer styles, resulting in slightly slower load times but less of a chance for Cumulative Layout Shifts to occur. If you are experiencing CLS issues you can then increase or lower the threshold 'height' via a drop-down low, medium, high setting.
Dynamic JavaScript Libraries
When enabled, IPS would only load external JavaScript libraries when they are needed by a specific sections or modules on the page. This removes unused JavaScript from the main scripts bundle and improves load times.
Improve Google Fonts Loading
Enable caching of Google Fonts and load them inline. This reduces render-blocking requests and improves page load times. Also presents an opportunity to switch to the Google Fonts API, to offer a dynamic dropdown list to allow admin to choose from all available GFonts. The Task Manager could check for and cache new versions of selected fonts in use weekly.
Limit Google Fonts Support For Legacy Browsers
Enabling this option will lower the size of Google Fonts and improve load times, however it will limit Google Fonts support in some very old browsers. You can turn this off to increase support for losers insisting on their older insecure browsers at a slight cost to performance.
Defer jQuery And jQuery Migrate
When possible, jQuery and jQuery Migrate could be moved to the body to speed up load times. If a third party plugin registers jQuery as a dependency, it would be moved back to the head.
Enqueue jQuery Compatibility Script
Some third party scripts may be incorrectly enqueued without declaring jQuery as dependency. If jQuery is deferred, these scripts could break. If you are experiencing console errors after enabling the "Defer jQuery And jQuery Migrate" option, you can enable this option, which will load an additional compatibility script that will attempt to solve the issue. (You can turn this feature off if everything is working fine without it).
Defer Additional Third Party Scripts
Warning: This can cause JavaScript errors in some cases and should be used with care. When enabled, scripts registered by plugins and themes will be deferred to improve performance and jQuery will always be loaded in the body.

When adding an image to an article in Pages, which is probably accounts for 90% of the images I use in articles in Pages, I see this when uploading the image:
Accepted file types: gif, jpeg, jpe, jpg, png However, when using the insert tool to insert an image within the text of an article I see this:
Accepted file types: gif, jpeg, jpe, jpg, png, webp I guess I am wondering why webp would be excluded as an option for the article's main image?
 

I agree that it would be much better to restore the ability to edit CSS templates.

For years IPB has promised site speed increases, and every one that you've delivered to date has turned out to be too little, too late--at least for anyone who is concerned at all about their Google rankings.
Here is a speed test of this very forum thread--and you use CDN with zero ads running--you score a 51%, which is an F for FAILURE:

 
After mostly CSS changes made with the ability to edit CSS files directly--the feature you just took away from everyone (and with the help of @Adlago), here is a similar forum thread on my site--I have no CDN and am running a large number of graphical ads:

What you see here is a site with mostly CSS changes, and it scores 25% faster than a site that is on a CDN with no ads. How is that possible? Perhaps you need to hire @Adlago because apparently speed improvements are still not on your radar, and now you've gone out of your way to strip the ability for those of us who actually care about this issue to be able to do something about it ourselves.

I agree that it would be much better to restore the ability to edit CSS templates.

I also cannot believe that you've removed this, and, after more than 15 years, and also looking at alternative boards to import my site into...totally unacceptable!
Your site speed is absolutely horrid...the only way I've been able to make my site get even average speed scores has been through extensive modification of CSS--now you've removed this ability from my--WHY??!!

When adding an image to an article in Pages, which is probably accounts for 90% of the images I use in articles in Pages, I see this when uploading the image:
Accepted file types: gif, jpeg, jpe, jpg, png However, when using the insert tool to insert an image within the text of an article I see this:
Accepted file types: gif, jpeg, jpe, jpg, png, webp I guess I am wondering why webp would be excluded as an option for the article's main image?
 

This is added so that the software does not embed a link when you have embedding switched off in the admin CP. I have tagged developers so they can add more on this

Please disable any third party applications/plugins and switch to an unmodified theme when troubleshooting these types as things as it may not be in the core 🙂 .

Before going this route, I am running a simple test here. I have cut and pasted a link in your top menu using the right click "copy" and then pasted it here:
https://invisioncommunity.com/news/ 
When I looked at it in "view source" I don't see the embedded code. I suspect this must be coming from my drop down menu plugin and will look into this possibility first, and let you know what I find out.
Test #2:
https://invisioncommunity.com/files/ 

I agree that it would be much better to restore the ability to edit CSS templates.

I agree that it would be much better to restore the ability to edit CSS templates.

I agree that it would be much better to restore the ability to edit CSS templates.

I’m sure they do; but that’s when IPS can simply have an automated reply at the ready or even a tutorial link to resolve. So really it shouldn’t strain support at all and increase overall user satisfaction even though it is a trivial issue.
Designer mode is recommended to use on a test install. While that may work, it is an extra step which realistically feels like only expert theme designers use.
4.7.0 did introduce an easier way of adding CSS which is great for newbies, but again, I don’t see why there was a need to remove the intermediate option.
It was a very convenient way of playing around with (a copy of) your theme.

Page speed aside, there was really no need to remove the core CSS from the templates. I agree that most users do not need it so they would of course simply ignore it; but the ones that do need it had the option to view, understand, learn and modify if they wanted to.
CSS is basically harmless and any issue that may come up we could just restore the file to the original version so this shouldn't strain IPS support.
Basically: us self-hosters are already getting hammered with the cloud only features. There's no need to remove features too now.

I have no doubt that some Invision communities are doing "very well" in Google. Some might even say that my site is one of those, however, I can assure you that I've gained at least at least 100,000 in my USA rank (now around 50,000) after dealing with the many speed and SEO issues inherent in the out of the box version of this software. This is a huge difference, and in my case represented the difference between ~100,000 unique monthly visitors before, and ~350,000 after.
So my question to you is, could those communities that are now doing "well" actually be doing a hell of a lot better? Yes.

If you are selling your house, you want to get the best possible price. If you place lots of ads in the newspaper and social media and have loads of people show up, you are NOT guaranteed the best price if your house "looks" undervalued.
The CSS Project is akin to advertising and the continued improvement of the suite will go a long way towards upping the site's overall perceived value.  Also known as "curb appeal".
It doesn't do us much good having lots of folks knock on our door if they immediately walk away to check out one of the other bright and shiny houses down the street.

Wouldn't it be easier on your staff, third-party developers and customers to improve upon CSS in a phased approach?
Why not break down the CSS Project into sub-projects? 
One sub-project you concentrate your attention on commerce.  You develop the "new" features you want to offer for that module while addressing any appropriate CSS changes needed.  You concentrate many IPS developer's and testers eyes on just that section of your overall codebase.
By concentrating "lots" of eyes on "one" module of the suite you will make it easier to identify any underlying performance, security problems or bugs. At the end of such a CSS sub project, you will end up with a much better underlying codebase then trying to tackle the entire suite all at once. Once that CSS sub project is "golden" you move on to the next sub-project
Upon release of the "CSS Project - Sub Project X" the third-party developers, theme designers and your customer base only have to make appropriate changes to "one" section of the IPS suite not the entire suite. 
By adopting a more phased approach you will significantly lighten the load and make it much less stressful on your third-party developers, theme designers and your customer base.

They are all marked as compatible, but IPS still needs to approve it. 

No, it is not automatic. but yes, almost all of my resources are compatible even by current versions with IPS 4.7...
Nonetheless, I have recently submitted updated versions/marked as compatible of all of my resources, and they are awaiting for approval. Including Mobile Navigation.

I recently upgraded to 4.7 and noticed that several of your plugins that I run now say they are not compatible with 4.7, including:
SuperBlocks 1.2.0 Enhanced Forum Views 1.4.1 SuperTopics 1.1.0 SuperGrid 3.2.0 Each one appears to be functioning in 4.7, so perhaps IPB automatically flags all plugins as non-compatible until the author checks off that their plugin is compatible?
In any case, do you know when those plugins will be marked as compatible, or an updated version will be available?