We have created content on an AEM author server and published the pages. The content shows up correctly on the publish server. However, when we try to reach the pages "live" as served from the dispatcher, they are missing some images and all of the css formatting.
We have tried flushing the dispatcher, but that didn't seem to work. Any hints on how to proceed with fixing this?
Missing images, css, js could be due to blocked/misconfigured paths in your dispatcher. Check your dispatcher access logs for more details.
Thank you for the responses. In case it helps anyone else, the problem was that the dispatcher flush job wasn't actually working. We had to go in and manually delete the designs folder tree and force the dispatcher to rebuild files from publish.
A second problem was due to some file extensions not being allowed. We updated one of the config files to allow png and ttf files, so all the images and fonts would load successfully.
Related
So I'm having an issue and I think I know what's happening but I'm not sure.
I have a PWA being deployed in versions. Each version obviously some files change. My bundler hashes the files into files (eg, /assets/OnboardingIntro.89e181b7.css).
What was happening was that when there would be a new deployment pushed along with a new manifest/SW, sometimes, there would just be a blank screen. A refresh fixes the issue.
In the network tab, it would say something like 'text/html' is not a valid JavaScript MIME type.
I figured this was happening because new PWA assets would be pushed with different hashes (for good reason), and the old ones would be deleted (also desirable). And what was happening was that on this current load, the old SW was requesting revalidation of its files. Even the SW worker was being told to cache these files, perhaps there was some logic that was re-checking them. And because rewrites go to index.html, these JS files were then being recognised as HTML causing errors.
Upon further inspection I found this header in the JS file:
cache-control: public, max-age=0, must-revalidate
Which suggests that the reason this is happening could be because the browser is being told to revalidate the SW's cached files every time.
But I would like really understand the logic behind re-validating cached assets in service workers. Can I guarantee that an installed service worker would never update a cached file until a new SW/manifest has been initiated? Because that's the only I can see this issue being solved. Otherwise every time I make a new deployment there's a window in which an old service worker might ask for an old file that no longer exists.
What is the logic behind revalidating? Does the SW use the cache headers? Is it just a matter of setting the cache header to an insanely long time? Is there another setting in the service worker, or in WorkBox to do this?
Another question would be, if an old asset and new asset's filenames matched, and these cache headers were set to infinity, would the new SW force a single revalidation to grab the new file? Or would it fallback to the old one if it's cached in the browser?
Thanks!
I am upgrading Keycloak from 9.x to 12.x in a development environment. I initially copied some custom themes forward, and found that the styling was badly broken (no surprise). I reviewed my FTL files, copied some of the core changes into my theme, and things are much better - just some minor issues to adjust.
Now the problem. I've made the changes to my login.css file, but those changes aren't showing up in the browser. It continues to fetch an old version of my custom CSS file.
What I have tried (multiple times for most of these):
Clear browser cache
Restart Keycloak
Check ownership/permissions of theme files
Restart entire server
Load CSS file directly
Load CSS file directly with meaningless parameter added (trying to bypass any possible middleman caching)
Confirm new version of Keycloak is the one running
Load page in other browsers
I've also now grepped the entire Keycloak directory for some of the CSS rules I've removed, and I can't find any copies of the "old" css file anywhere that might be getting referenced by accident.
Also, there are no messages in the Keycloak log when loading the CSS file.
I want to figure out how to get Keycloak to deliver the updated CSS to the browser.
Blind guess, so please don't blame me if it doesn't work. (question should include minimal reproducible example):
Edit /opt/jboss/keycloak/standalone/configuration/standalone-ha.xml and update it as follows:
<theme>
<staticMaxAge>-1</staticMaxAge>
<cacheThemes>false</cacheThemes>
<cacheTemplates>false</cacheTemplates>
...
</theme>
For me it worked when changed this file
standalone.xml
like below way
<cacheThemes>false</cacheThemes>
<cacheTemplates>false</cacheTemplates>
I think it is because I am using single instance mode instead cluster ha mode.
Apart from disabling cache, as described above, you can also adjust the theme resource URLs, breaking the client-side cache. It's a bit of a hack, but you can directly modify the resource tag portion of the URL by adjusting the database migration_model.id value.
references:
https://github.com/keycloak/keycloak/blob/main/model/jpa/src/main/java/org/keycloak/models/jpa/MigrationModelAdapter.java
https://medium.com/#hokumski/how-to-drop-keycloak-theme-cache-without-clearing-browser-data-aebb499ae83b
You must delete the path keycloak-server\standalone\tmp\kc-gzip-cache\sbgwq or otherelse folder... and test in a browser in incognit mode.
I have a weird network request in my page, which refers to JavaScript files, which I removed from every html file earlier. Cache is cleared and there is no single reference to be found in the source html and the JavaScript files. For fixing that and also out of general curiosity I would like to know if there is a simple way to find out where a request was triggered, preferably using the chrome-devtools.
Update:
Thanks to jaredwilli I found the initator column under the network-tab. However this only shows Other. What I would like to know, is the (html or javascript) file where those Requests have been triggered.
On the Network panel, you can determine what the initiator of a request was by viewing the Initiator column. It gives you the file, line number and type of resource it was, either Script or something else.
All of a sudden one of our sites has developed an issue with TinyMCE, specifically it seems, in relation to the advimage plugin.
When trying to browse the image folder via TinyMCE I get an alert with one of these errors:
In Chrome I get:
2can't process ajax,TypeError: Cannot read property 'responseText' of null
In Firefox I get:
2can't process ajax,Invalid XML structure
Nothing has changed on this site for a good few months.
We have upgraded to PHP 5.4 very recently, but I don't see why that would be related.
This could be an issue with overly large images in the plugin's upload directory.
On each request, the advimage plugin scans the upload directory (set in your config) and generates thumbnails of any images it finds in there, then sends a list of images off to the client in the form of JSON or XML. If an image is too large to process, (low server memory or something), then the process quits and doesn't return any JSON/XML, hence the seemingly unrelated error message.
Prune any images over 1MB from the uploads directory. You may need to flush the cached thumbs as well. To stop your users/admins from uploading huge images, set an upload limit in the plugins config.
Can someone explain to me in simple term the concept of caching in GWT. I have read this in many places but may be due to my limited knowledge, i'm not being able to understand it.
Such as nocache.js, cache.js
or other things such as making the client cache files forever or how to make files cached by the client and then if file get changed on the server only then the client download these files again
Generally, there are 3 type of files -
Cache Forever
Cache for some time
Never Cache
Some files can never be cached, and will always fall in the "never cache" bucket. But the biggest performance wins comes from systematically converting files in the second bucket to files that can be cached forever. GWT makes it easy to do this in various ways.
The <md5>.cache.js files are safe to cache forever. If they ever change, GWT will rename the file, and so the browser will be forced to download it again.
The .nocache.js file should never be cached. This file is modified even if you change a single line of code and recompile. The nocache.js contains the links of the <md5>.cache.js, and therefore it is important that the browser always has the latest version of this file.
The third bucket contains images, css and any other static resources that are part of your application. CSS files are always changing, so you cannot tell the browser 'cache forever'. But if you use ClientBundle / CssResource, GWT will manage the file for you. Every time you change the CSS, GWT will rename the file, and therefore the browser will be forced to download it again. This lets you set strong cache headers to get the best performance.
In summary -
For anything that matches .cache., set a far-in-the-future expires header, effectively telling the browser to cache it forever.
For anything that matches .nocache., set cache headers that force the browser to re-validate the resource with the server.
For everything else, you should set a short expires header depending on how often you change resources.
Try to use ClientBundle / CssResource; this automatically renames your resources to *.cache bucket
This blog post has a good overview of the GWT bootstrapping process (and many other parts of the GWT system, incidentally), which has a lot to do with what gets cached and why.
Basically, the generated nocache.js file is a relatively small bit of JS whose sole purpose is to decide which generated permutation should be downloded.
Each individual permutation consists of the implementation of your app specific to the browser, language, etc., of the user. This is a lot more code than the simple bootstrapping code, and thus needs to be cached for your app to respond quickly. These are the cache.html files that get generated by the GWT compiler.
When you recompile and deploy your app, your users will download the nocache.js file as normal, but this will tell their browsers to download a new cache.html file with the app's new features. This will now be cached as well for the next time they load your app.