Now that the Java plugin is gone in Firefox and soon to be gone in other browsers what is the plan for Teamsite and the way it uses Java? particularly things like version compare, local files and settings?
What version are you on? I know there is a patch for 7.5 version already.
Yea there is a patch available for 7.4, 7.4 8.1 and 8.2 Check the support site.
To follow up, it uses HTML upload/download. There is no local file storage, you manage that. There is a built in editor which you configure in ui_custom.xml (or application_custom.xml). Version compare works for certain types of files. Over all I do not like it nearly as much as the Java applet but not much OT can do.
BTW, make certain you have a good backup, I have had issues when I applied the patch to 8.2, got an NPE related to the DB for some reason.
cool, thank you. Missed seeing that. currently 7.5.0.2
You'll need to upgrade to 7.5.0.4
Also, see https://knowledge.opentext.com/knowledge/cs.dll/kcs/kbarticle/view/KB4096677 which has all the links you'll need to grab those QSU and patches (for 7.5, just download and install 7.5.0.4 which has what you'd need). Version compare and in browser edit will work for certain types of files OOTB, but you can add other extensions per the UI Customization Guide (for 8201, not certain the others have these instructions, on page 29).
Thank you.
I followed the instructions in the UI Customization Guide for adding file extensions so that we can utilize the built-in non-Java editor. That works fine. However...if I want to view the source (Action -> View Source) of a DCR (no file extension), which we do a lot, how do I configure that in application_custom.xml so that files with no extension will appear inline and it won't ask me to open it in an external editor? We tried () but that didn't work.
@David Smith said: I followed the instructions in the UI Customization Guide for adding file extensions so that we can utilize the built-in non-Java editor. That works fine. However...if I want to view the source (Action -> View Source) of a DCR (no file extension), which we do a lot, how do I configure that in application_custom.xml so that files with no extension will appear inline and it won't ask me to open it in an external editor? We tried () but that didn't work.
Really freaking bad idea to have DCRs with no extension. I hate when people have the .dcr extension. Not certain if what you wantt is even possible.
Well now you tell me. That's what they've always done here from when I started. I blame it on the consultants. I never used templating until I came here. It's their fault. Regardless, that's what we have. So I would still think there's be a solution to this in a regexical way....
Hope you opened a ticket asking support.
I do agree we should blame Ghoti
I opened a ticket but I have a feeling just based on the syntax of the solution that they didn't think of this...
I suspect you are correct, I will play with it if I get a chance.
@Andy Knipp said: Really freaking bad idea to have DCRs with no extension. I hate when people have the .dcr extension. Not certain if what you wantt is even possible.
Out of curiosity why is it a bad idea to not have an extension? It's how it was set up initially by Interwoven back in 2002 (before I joined the department). The only issue I can think of is the occasional conflict if you want to have a sub folder of the same name as a file that used to exist in that folder.
Because the browser can be set up to know what to do with that extension. Now you are correct, back in the 2005 and before, time frame, many people didn't have extensions on DCRs, even though they were XML. Smitty's implementation was circa 2009 and there is no excuse for not having one.
Even with an extension of .dcr (which is pretty common) you can define a MIME type so the browser can do the work.
okay, might look at changing it for when we create new sites. Out of curiosity what extension do you use since you don't like dcr
@Brett Sargeant said: okay, might look at changing it for when we create new sites. Out of curiosity what extension do you use since you don't like dcr
The files are XML. Take a guuess.
@Andy Knipp said: I do agree we should blame Ghoti
Hey! I was not responsible for their templating - my focus was primarily on their failover and disaster recovery process and proofreading poorly written "design" documents by certain people who I would prefer not to name.
@Andy Knipp said: @Brett Sargeant said: okay, might look at changing it for when we create new sites. Out of curiosity what extension do you use since you don't like dcr The files are XML. Take a guuess.
@Andy Knipp said:
makes sense
Found another issue - what I consider a bug, but is considered a "feature" by OT - with the new in-browser Edit. Since there is no built-in search for their Editing tool, you would think would work as expected to find text within the edited files, but it appears to only find the requested search string in the visible context of the displayed page. If the text you're searching for is outside the visible field, it won't find it. There is a "feature request" for it and it's slated to be fixed in a future version of 8.2, apparently. But not sure if they are going to put out a patch for 7.5 yet. I've asked but haven't got an answer back yet. Theoretically, 7.5 should still be supported till 2018, so they should supply a patch for this. We shall see...seems like a fairly important feature since there seems no other obvious way to be able to search for text while editing, unless you download and edit with your own editing tool.
Found another interesting byproduct of the new in-browser editor and it's not very desirable when you're using Linux as your TeamSite backend. When you edit files in-browser, and deploy to the TeamSite filesystem - we do this for many config files - it appears to save the files in dos format on the Linux server and has embedded "^M" dos carriage return characters, which can mess up things in Unix. This did not happen with the Java applet editing sessions. This is causing us headaches because we use config files to manage substitution strings for jobspecs and other files, and if the substitution strings have these ^M characters, this will wreak havoc. I will be opening a support case for this.
In the meantime, I will probably need to create a DNR script or something to run dos2unix on every file pre-deployment. Not sure if that is the best solution, but it's a start. I'm open to other ideas. PITA
Ouch, had not noticed that. Certainly file a bug, we need to be able to set the editor file format (or it should read and remember the EOL mar
Ouch, had not noticed that. Certainly file a bug, we need to be able to set the editor file format (or it should read and remember the EOL marker for the existing file)
@David Smith said: In the meantime, I will probably need to create a DNR script or something to run dos2unix on every file pre-deployment. Not sure if that is the best solution, but it's a start. I'm open to other ideas. PITA
@David Smith said:
I tend to download and drag and drop in. I like my editors.
Just opened a support ticket. Hopefully they understand the issue and address it quickly. I really don't want to have to handle this myself - it's not something I want to have to handle myself - dealing with it for our backend configs is one thing - dealing it with user content is another.
Understanding the issue should be trivial. Acting on it may be another thing. I am hoping there is a config somewhere that you missed.
Sorry for the duplicate posts, browser is acting funny when it autosaves.
What do you mean you're hoping there's a config somewhere that I missed?
Oh do you mean in configuring the in-browser editor? All Heather mentioned was the config to add new extensions - that's the only config I'm aware of. And that's in a version 8 doc. If there is more documentation for more config options, hopefully she will let me know in the support case. She should be the one handling it. I'll let you know what she says.
