sobrenome

As of 4.7.0, only true custom CSS files will show to discourage editing framework CSS. 
 
Have you edited framework CSS files in the past?

Same problem here, following upgrade to 4.7.0.
With "Advanced theme editing" enabled, I can only see core-front-custom-custom.css. None of the other css files are showing. I have also run the support tool and cleared the cache and the issue remains
I made a note of css files I need to revert, after updating but now I'm hamstrung and can't do the reverts.

In the top right you should see an "Advanced theme editing" button. This will bring up all templates if needed

Any Idea?

Since im using the BETA, im not seeing all templates / css files in theme editor (for example)

 
Has something changed or is my theme not compatible ?
 
Im Using Dynamic Theme 1.1.9
 
 

Using this guest page cache is a very bad idea in my opinion.
Yes, what you wrote can probably be done - I don't know how, but you try reflect on a possible situation (I have observed such - and with less cache time) - what I mean.
You want to use one hour of cache - but after that one hour, if a user with a slow internet connection is the first creator of that page - then for the next one hour, your guests will see a very bad version of your site... no matter where ( in the case as you say - cloud cache) they will receive this.
If you want your guests to receive limited, but high-quality (and probably much faster, due to the limited content of your main site), then use conditionals of the type - "if the user is registered - this, if not  ... " etc. This practice will save you resources for guests, and better performance such as site loading speed for example.

I have moved this to our developer area for you, as this is custom development rather than standard support. 

Does anyone know in which php file ips4_IPSSessionFront is set for guests?

Whoops!  Obviously meant to say MariaDB 10.6.8 🙄 lol

Running MariaDB 10.6.8 without issues.

I am currently running 4.3 and 4.4  Invision versions on a php 7.2 server  which they will update to 7.4  imminently. 
The serveradmin just asked me if its ok to also at the same time update to 10.3 Maria db  (which they have running) 
because my server still has  10.1 maria db. 
1) Will I be ok with Mariadb 10.3   for now? 
2) and, when in the future I will update to php 8  for  4.7 invision,   should i watch out for something with the Mariadb version  ? Will it also have to be renewed updated once more ? 
thanks in advance 

For what it's worth, I'm currently running IPB 4.7 on MariaDB 4.6.8 and PHP 8.0.8 with no issues whatsoever.  Because my VPS allows me to switch PHP versions with the click of a button, I've even done some preliminary testing with PHP 8.1 and have had no problems with that either.

The cache status of a site depends on the options created by IPS. But it also depends on the tasks of the cache server. In many cases, an nginx server is used as a cache server, and the usual caching time for that server is 15 minutes.
Question - you from IPS development - do you have an idea to synchronize the cache - so that the presentation of the cache is in the rhythm of time ... ie. when the server makes a recache, automatically follow with a recache header, footer, sidebar, etc.
thanks🙂

Happy Hump Day.
Identifying what members are frequently searching for is an important job for community managers. Built directly into the statistics panel of your ACP is a section that includes the most-searched-for keywords. Understanding what people search for helps you:
Improve upon those items Create more content around the term(s) Provide further clarity for people who search for the word or phrase in the future Because of the importance of search, we made some major improvements!
You may have noticed Invision Community introduced an update to our Search Bar user interface. @AlexJ certainly did 😜.
 

 
Previously, the search bar was smaller in size and included different options that could be confusing at first glance.
We've simplified the search experience. Should the user want to drill in further, they have that option on the search results page:
 

 
Go ahead and give our new search UI a test drive. Feel free to share your findings / thoughts in the comments. 😃 🔍 
---
As always, here's a list of updates and fixes made to the platform in the last seven days.
4.7.1 Beta 2 is out now. Release notes here.

See you in the comments. 
 

I'm treating the file as a static file and I cache it in cloudflare. The point is that this single used to extend page load by 1 second. Since I purge cloudflare cache almost daily I get a fresh copy every day.
 
Regards

I suggested it be an option in ACP, as I assumed there would be objections, as it happened.
This resource very rarely changes after its creation.
I have run expires time tests of 2 days, 3 to 6 days, but the only minimum expires time for this resource is 1 week is considered correct by several test servers - GtMetrix, WebPageTest and others.
If you decide that this exipres time should be fixed, then it should be 1 week.

I do not propose a fixed for 1 week - but the addition of an option in ACP with an expiration time at the discretion of the administrator.
When was the last time you modified your manifest file?

I know that. Therefore, the main idea of this topic is:
That's what I researched and wrote. On my site, an expiration time of 1 week is good.
If I make changes to this file, I can still turn on 0 seconds and make changes, once I see well-functioning new things, I will still include 1 week.
But if the cache expires time for this file exists as an option with values of 0 sec 1 day 1 week and 1 month, it will be easy and convenient for any administrator to make their choice.
 

What he's saying is that one week is quite a long while to cache something without a "cache buster" in the request URL. The cache buster is the string of random characters you see in the CSS and JS requests, and it is used to detect changes to the file. When a file changes, the cache buster changes, and it will thus look like a new file to those who have cached it.
The manifest file does not have that added to the URL, and with a week of cache time any changes to the manifest may take up to week to take effect.

With 1 week (604800) value is perfect.
I did a test with several test servers.

PHP can override this.

$cacheHeaders = ( \IPS\IN_DEV !== true AND \IPS\Theme::designersModeEnabled() !== true ) ? \IPS\Output::getCacheHeaders( time(), 86400 ) : array(); Line 174 applications/core/modules/front/system/metatags.php

That's how experts advise - not just on the site linked. Personally, I would try for a 1 month expiration time.

So it should never be cached at all? that's what those settings are.