nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practice for file management

LooseCannon

Environment:
TS 671 SP1 / Linux

I have a question on how to best manage artifacts (html, images, etc.) for non templated sites in TS on Unix/Linux?

As a developer I think the best method for file management is with a FTP client of the developers choice. WS_FTP Pro, Cute FTP, whatever… Launchpad is a joke and I wouldn’t force any user to use it.

BUT there’s a problem with managing files with a FTP client – only the file owner is granted write access (unless the default OS perms are changed), because OS permissions get applied instead of TS permissions as defined in iw.cfg. (Actually this is only a problem when more then one person maintains a site, which is the case 99% of the time).

How are others running on Unix/Linux handling this?

The best I can come up with is having separate “private” workareas per developer (this makes the permissions issue a moot point), with changes being integrating in staging. But with this approach how does the developer know he’s working with the “latest” version of a file? He would always have to do a Get Latest before making any changes, right? Asking a developer to do a Get Latest before every update doesn’t seem practical. Too time consuming…

I’m sure there’s a simple solution that I’m over looking…

Thoughts?

Find more posts tagged with

Comments

nipper

Samba to provide local file access. If you use different workareas per person, then *carefully* write the WF to use the updatetask to avoid requiring get latest.

LooseCannon

Samba to provide local file access. If you use different workareas per person, then *carefully* write the WF to use the updatetask to avoid requiring get latest.

Thanks for the feedback.

I haven't used Samba, so I'm not sure how or if it would work. Our branches and workareas are private to TS groups, so would enforced access be as if they logged on to the server? Also, wouldn’t OS permissions and not TS permissions be applied to files? If so, touching files via Samba would offer the same problem as with FTP. Guess I need to educate myself on Samba…

Concerning the update task, asking a developer to initiate a synchronization task (workflow/update task or get latest) prior to file edits doesn’t seem practical. Developers are accustomed to using HTML editors to interface with file edits. Incorporating a sync task would force them to first login to TS, run the task, and then go back to Dreamweaver to make the edits. It would work but I wouldn’t want to use it.

Maybe I’m looking at this all wrong and TeamSite shouldn't be used to manage HTML files, but rather be a step in the publishing process? Meaning sites get stored locally or on a network drive. When ready to deploy to test or prod, the modified files get FTP’d into a workarea, submitted for versioning, and then deployed. The submit and deploy could be wrapped in a workflow or script called from the menu. The files in the workarea would still need the permissions corrected but this could be done with submit.cfg.

Admittedly I’ll have a hard time selling this to management. There response will be, “WHAT? You want sites managed on a network drive when we own an Enterprise Web Content Management System?”

nipper

A couple points, first about Samba, groups & permissions are going to be OS groups. Yes the issues are similar to FTP but you can use the TS GUI and act as if the file is local (by configuring launchpad) rather than running outside TS.

The updatetask runs as part of the workflow and will be used to automatically propagate changes from Staging to various workareas when a submit happens. So it is part of the original WF and keeps the workareas up to date with Staging automatically.

Adam Stoller

...
Maybe I’m looking at this all wrong and TeamSite shouldn't be used to manage HTML files, but rather be a step in the publishing process? Meaning sites get stored locally or on a network drive. When ready to deploy to test or prod, the modified files get FTP’d into a workarea, submitted for versioning, and then deployed. The submit and deploy could be wrapped in a workflow or script called from the menu. The files in the workarea would still need the permissions corrected but this could be done with submit.cfg.
...

What I think you're looking at wrong here is trying to use TeamSite to manage HTML files created outside of TeamSite. That's what FormsPublisher is for - you provide forms for users to insert content into and then use PTs to process the DCRs that were created to produce HTML.

You seem to be trying to use TeamSite (a CMS system) as if it were just a version management system (like CVS, PVCS, etc.) - in which case you're using a sledgehammer to turn a screw.

I'd suggest learning more about the functionality that TeamSite provides so you can understand how it can (and should) be used.

SameColorsForCategoriesInSeparateCharts.rptdesign

LooseCannon

The updatetask runs as part of the workflow and will be used to automatically propagate changes from Staging to various workareas when a submit happens. So it is part of the original WF and keeps the workareas up to date with Staging automatically.

I hadn't thought about kicking off the sync process via a submit workflow. That just might work. Thanks.

LooseCannon

What I think you're looking at wrong here is trying to use TeamSite to manage HTML files created outside of TeamSite. That's what FormsPublisher is for - you provide forms for users to insert content into and then use PTs to process the DCRs that were created to produce HTML.

You seem to be trying to use TeamSite (a CMS system) as if it were just a version management system (like CVS, PVCS, etc.) - in which case you're using a sledgehammer to turn a screw.

I'd suggest learning more about the functionality that TeamSite provides so you can understand how it can (and should) be used.

Wrong. I completely understand that TeamSite is intended to be used to centrally manage site artifacts. Problem is it doesn’t provide an intuitive interface for interacting with files, which is why over the past 6 years we have only implemented templated sites. LP File Manager sucks and we are on Linux so I’m looking for a workaround.

Do you have anything useful to contribute?

nipper

Problem is it doesn’t provide an intuitive interface for interacting with files, which is why over the past 6 years we have only implemented templated sites.

That certainly is your opinion. I happen to disagree. I have implemented TS in a number of non-templated sites and used it as a SCM system, without any trouble. Your developers may not like the GUI, fine. But the functionality is there without using FTP. You can go ahead and use a network share, CVS, or whatever you want.

You still have not explained why you think TS is lacking in functionality for this application. The only place there I have seen issues is the branch promotion model that is popular, moving data transparently (and accurately) from a dev branch to integration to production certainly can be done but is not trivial.

prac1.rptdesign

LooseCannon

That certainly is your opinion. I happen to disagree. I have implemented TS in a number of non-templated sites and used it as a SCM system, without any trouble. Your developers may not like the GUI, fine. But the functionality is there without using FTP. You can go ahead and use a network share, CVS, or whatever you want.

You still have not explained why you think TS is lacking in functionality for this application. The only place there I have seen issues is the branch promotion model that is popular, moving data transparently (and accurately) from a dev branch to integration to production certainly can be done but is not trivial.

Using LP is a step back and counterproductive to Web developers.

How would developers manage links for sites in TS? How would they do global search and replace?

For instance, for just one file that’s moved, renamed or deleted the entire site (all 70 dir and 5,000 html files) would need downloaded (which would take 10 mins ) and then found under the branch tree where the site gets stored locally (I actually doubt it would get this far because LP comes to a crawl at about 2,000 files). Then move the file with automatic link management enabled, save the updated files, go back to LP sort by Modified (this will take 20 mins because LP also has files for the other 20 sites I maintain), select the files and FINALLY upload!!!

I think it’s safe to say that initiating edits from TS with LP as the interface is not a natural flow for Web development.

Do you guys running windows have any permission issues when FTP’ing files?

nipper

Yes, I agree. I never use launchpad. I use a SMB share. That make life *much* easier. If you have a Unix server you can use a samba share and put launchpad in local mode.

Adam Stoller

Using LP is a step back and counterproductive to Web developers.

How would developers manage links for sites in TS? How would they do global search and replace?

For instance, for just one file that’s moved, renamed or deleted the entire site (all 70 dir and 5,000 html files) would need downloaded (which would take 10 mins ) and then found under the branch tree where the site gets stored locally (I actually doubt it would get this far because LP comes to a crawl at about 2,000 files). Then move the file with automatic link management enabled, save the updated files, go back to LP sort by Modified (this will take 20 mins because LP also has files for the other 20 sites I maintain), select the files and FINALLY upload!!!

I think it’s safe to say that initiating edits from TS with LP as the interface is not a natural flow for Web development.

Do you guys running windows have any permission issues when FTP’ing files?

I tend to do most of my work in TeamSite through the file system interface - with the exception of templates - so as long as my local OS provides good tools for things like search and replace - I'm generally good to go without using LaunchPad at all.

If my OS doesn't provide good tools for that - then I create Perl scripts that I can run from the command line on the TS server to take care of such things.

Is it a great solution? Perhaps not, but for what it's worth - I believe global Search & Replace is coming in a future version of TeamSite, so it may not be needed for that long a time as a work-around.

pdasarat

You can use TeamSite FrontOffice Briefcase. No Samba, it's through port 80 and it's locally mapped to c:\iwtemp folder. You can use your own tools to manage content from briefcase and do a bulk submission. It's does allow to "get latest" via "refresh" menu. Try it out. The model is simple, but gets your work done.

Pradeep