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.
Related
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.
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
I've found that some of my ASP.Net web apps prompt the browser to load plugins that I'm not explicitely using and certainly haven't deliberately referenced in the project settings.
Two that come to mind are for MS MediaPlayer and the "SVG Viewer for Netscape".
The only commonality I've determined so far is that the two sites/apps affected both use Master pages (nested in some cases).
We don't use SVG file types (just the normal mix of jpg/gif/png) and no video/audio (not yet anyway).
Can anyone provide a hint as to where the references for these might be creeping in? e.g. Is it a server-level include? Or a .Net runtime default when using master pages?
Does anyone else even experience this, or is it just me?
No urgency, I'd just like to remove it if possible.
Thanks.
Al
If you look at the page source in your browser, you should see what's in the page that requires a plugin. If you load external Javascript, you will have to look at that too. Do you have ads on the site that include 3rd party code?
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."
I work in an area where the business users heavily depend on bookmarks to access their work-related web applications. Our standard browser is Internet Explorer v6. We have a new Flex application - when you add the site to Internet Explorer Favorites, then later try to access the site with the Favorites link, we get the following error message: "internet explorer cannot open the internet site http://our url. Operation aborted". If we then bring up the properties for the link and remove the trailing "#' from the url, the link works.
What is this trailing "#", and can it be removed? Is there a way to have Internet Explorer bookmarking to work for this site (other than manually editing the bookmark)? The problem doesn't occur in Firefox (but not everyone has access to that browser).
The trailing # is used to provide information to your client-side framework. It was originally meant to provide the ability to link to anchor points in an HTML document. It has been "hijacked" by JavaScript frameworks to provide state information to Flash and Flex applications.
The primary benefit of using # to navigate is that the browser doesn't navigate off the current page - meaning you only need to load your framework once. Traditional URLs would force an entire page reload.
Most likely you can't remove it. You should be able to provide a means for a secondary URL scheme that encodes what you need in a query string (?foobar=1).
You will need to configure server-side processing to either redirect the user to the hash URL or load the necessary information via a JavaScript hook to your Flex framework.
You might also look into the new Google Chrome plugin for IE.
You can turn this off in the compiler parameters in Flex Builder. Go into the project settings, then in "Flex Compiler" uncheck the box that says "Enable integration with browser navigation".