I need to publish out a large XML file (~8MB = ~28,000 lines) from Tridion (2011 SP1 HR1) on to the web sever(s).
I have done this in the past with similar sized XML documents by uploading the XML file in to a Multimedia Component in Tridion and then having a simple Component Template to render the contents of the file at publish time. However, in the Tridion implementation in which I am working there is already a mechanism for publishing out content to the site using a very simple 'Code' Content (not Multimedia) Component which has a single plain text field for the 'code'.
The problem that I am having is that the browser becomes unresponsive/crashes when I try to paste such a large amount of content in to the 'Code' Component. Does anyone know of a way (either in the browser or in Tridion) to make this possible? I do have the option of adding a Component Template to process this as a Multimedia Component, but I would be reluctant to do this if I could get the existing mechanism working.
I have tried this in IE, Chrome and Firefox. I have also tried uploading this using WebDav without success too. We have already increased the HTTP Upload size on the server to 0.5GB to accommodate large binary files.
Thanks,
Jonathan
The first thing that comes to mind is the WCF size restrictions in the CoreService configuration.
These are set in the Web.Config of the CME, under (by default): C:\Program Files (x86)\Tridion\web\WebUI\WebRoot
Related
How to pick multiple files at once using JSF 1.2.
I am able to upload multiple files using rich faces(only one file selection at once), but can't pick multiple files at once. Prime faces provides support for multi file upload but to work with Prime Faces, JSF2.x version is required. We are stick to JSF 1.2.
In rich faces <rich:fileUpload/> tag has an attribute allowFlash, if we make this value as true it allows us to select multiple files, but after selecting multiple files its throwing an error saying
ContentTypeList does not contain a supported content type: text/*
After throwing error, even the upload button dissapears
Even I referred few other libraries like blue imp jquery multi file upload but I have zero knowledge on jquery and I don't find any example related to JSF1.x file upload.
Can anybody knows the solution?.
If your application runs on a JavaEE 6 application server or on a (with JSF 2.x configured) servlet container, take a look at Primefaces file upload component. It supports multiple file selection for a modern browsers. You could set file pattern to be accepted only *.zip files from browser's file selection dialog, using:
<p:fileUpload fileUploadListener="#{bean.listenerMethod}" mode="advanced" multiple="true" allowTypes="/(\.|\/)(zip)$/" />
For a legacy JSF 1.2 environment you could use Primefaces <= 2.1 or as mentioned #VasilLukach RichFaces 3.3.3 file upload component. Both of them support only single file selection (in order to upload several files, user have to click on a file selection button several times).
See more examples and/or documentation in linked showcases above.
Regardless of the used component library, your use case mentioned in comment:
I need to select all the three zip files from browser , then extract individual zip files and upload them into server
seems to be wrong. Usually user choose one or several files to be uploaded and then they are processed after transmission by your application on the server-side (unzip, persist or whatever else).
We have a Tridion use case related to curated content where we are creating multimedia components for images associated with our content which are pointing to External resource types instead of uploaded resource types.
One of the issues we have run into with this use case is that despite explicitly setting the Multimedia Type for the resource, if the URL of the image has either a query string in it: http://cdn.hw.net/UploadService/1c8b7f28-bb12-4e02-b888-388fdff5836e.jpg?w=160&h=120&mode=crop&404=default or uses a ‘friendly url’: http://www.somewhere.com/images/myimage/ when we save the component, Tridion barfs with error messages similar to : ‘Invalid value for property 'Filename'. Unexpected file extension: jpg?w=160&h=120&mode=crop&404=default. Expecting: jpg,jpeg,jpe.’
So far, the only way we’ve been able to figure out to potentially get around this issue is to do something hacky like appending an extra query string parameter to the very end of the urls which end with the expected file extension: http://cdn.hw.net/UploadService/1c8b7f28-bb12-4e02-b888-388fdff5836e.jpg?w=160&h=120&mode=crop&404=default&ext=.jpg Obviously, this is not the best solution and in fact may not work for some images if the site they are being served from strictly validates the requested URL.
Does anyone have any ideas on how we can work around this issue?
Unfortunately I can't really think of an easy solution to this, since Tridion "detects" the Mime type by checking the file extension.
You could perhaps add it while saving and remove it when reading (via Event System)? Definitely a worthwhile enhancement request, to my knowledge this behavior has not been changed for the soon-coming Tridion 2013... See comment below, it has been changed for 2013.
+1 for Nuno's answer. Recognizing that the title of your question is specific to multimedia components, you may want to consider another approach which is to use normal Components, not Multimedia Components. You can create a normal component schema called something like "External Image" that has an External Url field to store your extentionless url.
Content authors will then include these images via regular component linking mechanisms in the Tridion GUI.
You will then need a custom link resolver TBB that will parse the Output item (via Regex) looking for any Tridion anchor tags <a tridion:href="tcm:x-y-z"> and for each one replace them with an <img src=...> tag where the src path would come from this linked component.
For an example of a similar approach, but with videos, and sample code for a custom link resolver TBB have a look at the code in the following post: http://www.tridiondeveloper.com/integration-sdl-tridion-jw-media-player.
I'm really stuck. I'm working on an integration project where I'm creating a html fragment using ASP.NET. This fragment will be included as part of another site. The html fragment is created using a simple ASP.NET page with a minimal code behind file.
Te site that will include this html fragment is running PHP. The developer there is complaining that my code is sending the byte order mark as part of the html fragment and this is making his life difficult.
I'm using Visual Studio 2010 for development. I've saved the relevant aspx and aspx.cs files as UTF-8 without signature. However, this doesn't seem to have made a difference and now I'm pretty much out of ideas. The rest of the site is set to use UTF-8 as standard (defined in web.config).
Where should I be looking to alter the BOM behaviour for my aspx file?
If you save the file in Visual Studio I believe it will keep adding the BOM. You need to use a different editor to remove the marker such as NotePad++.
Actually in the advanced save as dialog in Visual Studio there is also an option to save UTF-8 without signature. Have you tried this?
It's confirmed in this question.
You can also use plain old NotePad to save with a different encoding.
Save As...Encoding DropDown.
I am supporting a site for a client on the intranet. The site contains links to xml files. These xml files have a unique extension and are intended to be opened by a specific application. Using IE 8, we could support this by setting the option ‘Open files based on content, not file extension’ in Internet Options -> Security -> Custom Level. In IE 9, this option has been removed. Now these files open a new tab and display the xml.
Ideally, I’d like the file to just download through the download manager, but opening file in the application on the client machine would be acceptable as well. What is the best way to do this in IE 9? Is there a setting that I should adjust? Server side, I have tried adjusting the MIME type, but it seems that if I sent it to something unknown (e.g. application/octet-stream) IE determines the content. The last option I could think of would be to adjust the links such that they call an asp.net page that loads the contents of the xml into the response object but changes the header to contain Content-Disposition:"attachment;filename=file.ext”.
Any advice on the best way to solve this problem?
Content-Disposition:attachment is what you are looking for, yes. That is how you instruct browsers to download the file separately, and not try to display it.
You could use routing or rewriting to keep your file URLs, but have an ASHX handle the file so it can set that header. (don't use an ASPX; it's more than you need to just set some headers)
I think the work around that I was looking for was the fact that the 'Open files based on content, not file extension' option in IE8 was renamed, 'Enable MIME Sniffing' in IE9. But Andrew Barber's answer is the correct solution.
I found out that some websites use css tag like style.css?ver=1. What is this?
What is purpose of ?ver=1?
How do I do it in code?
To avoid caching of CSS.
If the website updates their CSS they update the ver to a higher number, therefore browser is forced to get a new file and not use cached previous version.
Otherwise a browser may get a new HTML code and old CSS and some elements of the website may look broken.
Adding '?ver=1' makes the HTTP request look like a GET query with parameters, and well-behaved browsers (and proxies) will refuse to cache parameterized queries. Of course well-behaved browsers (and proxies) should also pay attention to the 'Cache-control: no-cache', 'Expires', 'Last-Modified', and 'ETag' response headers (all of which were added to HTTP to specify correct caching behavior).
The '?ver=1' method is an expensive way to force behavior when the site developer doesn't know how (or is too lazy) to implement the correct response headers. In particular, it means that every page request is going to force requesting that CSS file, even though, in practice, CSS files change rarely, if at all.
My recommendation? Don't do it.
The purpose of the ?ver=1 is to parameterize the css file, so when they publish a new style.css file they up the version and it forces the client to download the new file, instead of pulling from the cached version.
If you are developing a web application in HTML and CSS or any other technology, and you are using some external CSS or JS files, you might notice one thing that in some cases if you made any changes to your existing .css or .js files then the browsers are not reflecting the changes immediately.
What happens in that case is that the browser do not download a fresh copy of the latest version of the .css and .js files, instead it uses those files stored in your local cache. As a result the changes you made recently are not visible to you.
<link rel="stylesheet" href="style.css?v=1.1">
The above case when you load the web page the browser will treat "style.css" as a different file along with "?v=1.1". Hence the browser is forced to download a fresh copy if the stylesheet or the script file.
I think that ?ver=1 is for the version no. of the web app. Every time a new build is created, the app can update the ver to the new version. This is so that the browser will load the new CSS file and not use the cached one (both use different file names).
You can refer to this site: http://www.knowlegezone.com/36/article/Technology/Software/JavaScript/CSS-Caching-Hack----javascript-as-well
IMO a better way to do this would be to include a hash generated off of the file size or a checksum based on the file contents or last-modified date. That way you don't have to update some version number and just let the number be driven off of the file's changing properties.