In %TRIDION_HOME%\web\WebUI\WebRoot\Configuration\System.config we can increment the modification attribute's value to instruct the Content Manager to force a download of items.
The setting is mentioned on the PowerTools discussion but also on the Skinning the Content Manager Explorer topic on SDL Live Content.
<server version="6.1.0.55920" modification="7">
Alternatives to updating the CME include clearing browser cache (CTRL+Shift+Delete in Chrome) or setting cache settings per user.
Question
Should I use this for any CM-side changes such as GUI extensions, schema changes, or template linked schemas? Or does it only apply to certain parts of the Content Manager Explorer?
In other words, after a schema and template change, what's the best way to make users get the latest versions of components, schema drop-downs, and template selections?
The values of the modification and version attributes become part of the URL of every CSS and JavaScript file that the Tridion UI generates/merges and of many of the static (image) files too. So the URLs look like this edit_v.6.1.0.55920.7.aspx?mode=css. Since the browser sees this as a new URL, there is no way it can have the file in its cache yet. And thus it will always have to download the files from the server, instead of using (possibly outdated) files from the local cache.
This is a technique of injecting some version information into the URL is known as "URL fingerprinting". Google commonly embeds a hash-value of the file into the URL, ensuring that the fingerprinting happens without requiring the developers to increase a version number manually. But whichever way of fingerprinting is used, the technique is a pretty efficient way to ensure that all browsers download the latest version of your code.
If you are developing a GUI extension, you can indeed typically get the same effect by clearing your browser cache or even disabling it completely (for the Tridion domain). But once you roll out your extension to a non-development server, changing the modification attribute is the most certain way to ensure that all your users get the latest JavaScript/CSS changes without each of them having to clear their cache manually.
The URL fingerprinting in Tridion only affects CSS, JavaScript and image files. The actual CMS data (such as Schemas and Components) is loaded using XMLHttpRequests and thus not affected by the modification attribute.
As far as I know,
<server version="6.1.0.55920" modification="7">
This clears only JS and CSS related caching. When a User access the CM then CM loads all the files including latest copies.
Should I use this for any CM-side changes such as GUI extensions, schema changes, or template linked schemas? Or does it only apply to certain parts of the Content Manager Explorer?
For this line, answer is No. Since when ever user does any changes to schema, changes should refresh on all publications. Currently this is not happening on the browser.
Hopefully this might be fixed in on coming versions.
In other words, after a schema and template change, what's the best way to make users get the latest versions of components, schema drop-downs, and template selections?
Currently user should do a forceful refresh to get updated info on all publications.
The SDL Tridion CMS interface caches CMS Items in order to provide faster browsing and loading of its own interface. This does mean that sometimes:
Custom GUI extensions may not display latest versions of the files
Recently created or modified CMS items may not be shown, or show the latest version.
This is why sometimes a new keyword isn't shown within a component field, or a new component template isn't shown when trying to add a component page.
Incrementing the modification number in the node will cause all CMS items to show the latest versions to the CMS user(s). You'll see if uses this value to reference CSS and JS files used by the CMS GUI.
As a developer I also turn off my Firefox cache (I prefer firefox for the firebug extension which is great for working with GUI extensions) as this means you don't need to go and change this value, a simple browser refresh seems to always do the trick. Turning off cache is explained here : https://superuser.com/questions/23134/how-to-turn-off-the-firefox-cache
Related
We have an ASP MVC 5 applications. We use bundles with optimization enabled by default. But we have heard several times from users, that they get errors, that we think are caused by old versions of user scripts. Their browsers somehow take scripts from cache, despite the fact, that we have edited that script files and bundles should be updated. The worst part of the problem is that we can't imitate or recreate this problem. We don't know how. We already have tried to make test-changes to scripts like adding some "console.log('test')" lines in order to see, if the browser takes the cached version, but everything was ok, the hash in the end of <script src="....?v='hash'"> changed and the browser took the newest version from first time. I should mention, that our site is a single page application. Don't know, maybe its somehow related with the problem.
Have you faced this kind of problem?
There's not enough information here to give a definitive answer. The bundler detects changes in files and will regenerate the bundle along with the link to that bundle, which will include an updated query string param. Since the query string is part of the URI, it's considered a totally different resource at this point, and the browser should fetch it again, because there is technically no cache available. The only logical reason this would not occur is if the HTML with the link to the bundle is not being updated. This can happen if you're using OutputCache or otherwise caching the HTML document. It can also happen if the client's browser is aggressively caching the HTML document. Unfortunately, there's not much you can do about that, as the client browser ultimately has control over what is or is not cached and for how long.
That said, given that this is a single page app, it's very possible that it's also including a cache manifest. This manifest will very often include the HTML file itself, and the browser will not refetch any file in the manifest unless the manifest itself is updated.
Hey I'm working on a site that loads CSS and images that are generated server-side. Some times the images and CSS that is loaded in shows up as the incorrect template but with the correct images.
Since this template is created on the server and not on the actual page I was thinking that the web server that hosts the actual page may have a cached version of that page and may sometimes ignore the CSS and images that are generated from the main server.
In short:
Do webservers sometimes keep cached versions of page Styling?
I there an easy way to make it get the live version always?
Also this happens very infrequently and at random. It seems very hard to replicate. But I have seen it happen a few times.
Any other Ideas?
For the first answer, yes they do but only if setup that way. There is the CDN or varnish. These system are used for website with huge loads where content must be cached locally or on other server, allowing the user to visualize the cached content and not the one generated by the webserver at the moment the user requested.
Exclude this for your case then ;)
I always use chrome or firebug on firefox to debug a website.
Press F12 while in the page you want to check and, on chrome, go to "Network" tab and pin "Disable Cache".
This is incredibly handy if you refresh your page quite often and want the content not cached.
For the question itself, I don't think I/we can help you without seeing the code. But try my suggestion with F12 before.
There are two kinds of caches to think about. One of them is server cache. If you use server cache, then whenever CSS was modified, you need to empty the CSS cache if you have such a cache. If not, then you need to empty the cache, which might be painful.
As about browser cache, if you add a new parameter to your css file, then it will be loaded even if it was cached in the browser of a given user, therefore it is recommendable to add a parameter to your css file where you include it. This parameter should be either a version or a timestamp, or something uniquelly distinguishable from earlier versions. That value should be stored and you need to refresh (preferably) automatically whenever the CSS changes. The exact steps are up to you, since they differ greatly in different environments.
Good day.
So, here is my issue.
I'm currently using sharepoint 2010 for web applications, I am supposed to display pdf as part of a web page. Currently, the browser tends to download the pdf file instead of displaying it.
Content-disposition is already set to inline.
I've also used iframe, and src is pointing to custom httpHandler.
I've already added "application/pdf" MIME type in the list of AllowedInlineDownloadedMimeTypes as per the advice in this link http://www.pdfshareforms.com/sharepoint-2010-and-pdf-integration-series-part-1/.
However, the application still failed to display it, and it prompts the user to download the file instead.
I'm using mozilla firefox v12 and ie8 to test the application, they both exhibit the same behavior.
What else is missing? Thank you.
It's important to remember that not all browsers, especially older ones like Internet Explorer 8, have the ability to render PDF content inline. In these older browsers, this was generally accomplished through plug-ins like Adobe Reader or Foxit being installed on the client machine.
Basically, if you are using an older browser, your users will likely need one of these (or a similar) plug-in installed. Otherwise when the browser encounters a PDF file, it will serve it to the user, as it doesn't really know how to deal with it.
There is also a chance that this could be a permissions / settings issue similar to the one addressed in this related question. You may want to review over some of the discussions within that thread as well as this Sharepoint 2010 one, which details a a setting called "Browser File Handling" and how it's default value of "strict" can affect how PDFs and other files are accessed.
He came across the solution while looking at the "Web Application General Settings". There is a setting called Browser File Handling and by default it is set to strict.
So I am about to add another WP blog, but I'd like to keep it under version control. Then I started thinking, how would that affect my current WP workflow. Based on my limited xp in using WP, when an update is pushed from WP dev team, I see an indication in my admin control panel. From here I can simply click the button, and the changes are implemented behind the scene. This approach is great for a single WP instance outside of version control, but what about more nodes, and in version control?
Some of the WP updates include both code and schema changes, so I can't simply publish the code without also implementing the new schema changes. The best I can figure it is to do the following:
Localize current WP version stored in version control
Download latest (stable) wp files
Extract to local path (created in step 1)
Diff changes (optional)
Commit changes to version control
Log into each server
Put into maintenance mode
Pull latest changes
Implement new schema changes (????)
Test
Take out of maintenance mode
Step 9 is what is tripping me up. Do I do a schema dump from my local (freshly updated) schema, then import that schema for every server (or use provided schema change file if WP included id).
Is there a better approach to this?
---- EDIT 1.20.2014 ----
After further consideration, I wonder if setting up some type of mysql replication would be the way to go? Have one node access with read/write access so it can make changes which are restricted to database only (i.e. de-activating a widget), but have other servers serving up the blog content read from readonly mysql instances which are replicated to. This way only one server is making changes from which the others will pull. During my research I have noticed that some changes like alterations to child theme via functions.php or style.css can be tracked in version control, but other changes like activating/de-activating widgets are purely sql based, which would be impossible to track in version control.
Is there a better approach to this?
Don't touch WP core (do you really need it?)
OR
Hack core only once in order to replace default repository's URL of WP-core with your's and later use system auto-updater with your repository
A colleague set up an intranet application where the users can upload documents. These documents are displayed afterwards in an IFRAME using <IFRAME src="document.doc"></IFRAME> - of course this only works in IE. While this works with some users, others (including myself) do not see the document, but rather a download dialogue allowing them to download the document.
I vaguely remember that there was a recent security issue with displaying MS Office documents in IFRAMES, but could not find any information whether there was a security update blocking this. Anyone here who has a clue?
I am not looking for alternatives for the IFrame, I just want to know why some users are displayed the download box while other users see the inline document.
If you get a download dialogue instead of displaying the document inline in an iframe, then:
you probably haven't installed the Office Web Components. You can change the components Office has installed from its Add/Remove Programs entry in the Control Panel. But,
DON'T. There have been endless security holes in OWC. Installing a plugin means a great deal of new net-facing code and subsequently a great potential for exploitable bugs, especially in software that wasn't originally intended to be net-facing like Office.
Install the absolute minimum number of plugins you can get away with (these days usually just Flash). Don't install every plugin an application offers you, don't install a PDF plugin, and definitely don't install a load of plugins for Office documents.
Is viewing an Office document in a little annoying scrolly box tucked into a web page really compelling enough to justify the risk? I suggest that no, it's in fact much much less usable than just downloading the document to the desktop and opening it in a proper document editor/viewer.
You might consider an RTE like CKEditor. It allows the user to cut-and-paste from Word (I assume you are primarily concerned with Word docs given your problem description) and then to view and edit. CKEditor claims to be "compatible with all major browsers."