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; } } }

Regenerate Button

mfritsky

When running iwregen from the command line, any STDERR will be displayed directly in the window. Is there any way to get this STDERR to show up when regenerating a page through the regenerate page in the TeamSite GUI? Generally, I'm looking for a way to indicate to a user that a problem was found in the TPL.

Find more posts tagged with

Comments

gzevin

I don't think there is a way - and - in many cases, TPLs give some warnings just because Jon **** doesn't 'use strict' Smiley Happy

- are you sure these messages will give some sensible info to the user?

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

> When running iwregen from the command line, any STDERR will be displayed directly in the window. Is there any way to
> get this STDERR to show up when regenerating a page through the regenerate page in the TeamSite GUI?
> Generally, I'm looking for a way to indicate to a user that a problem was found in the TPL.

Write a custom menu item to regenerate (call iwpt_compile.ipl and show the results). Then rewrite it with each significant TeamSite release.

It would be VERY nice if all Interwoven modules would use strict; all of my modules do so I don't see what the problem is.

Just had a very serious problem with these types of PT bugs using the default regenerate menu item - when an individual file was regenerated it would always work, but under certain conditions when regenerating multiple files, after a certain number of bugs were hit the iwperl process would just hang, and the regeneration window would never show the results. For some reason a custom regenerate would never show this.

I believe any output from iwpt_compile.ipl should be considered a bug in the presentation template (useless use of variable in null context, variable definition masks variable of same name in same scope, use of uninitialized value, etc.).

mfritsky

There are times when we can detect a user error when regenerating a page. Normally, these errors can be detected when the DCR is created/modified, and shown immediately to the user. However, there are cases when a referenced file is changed (e.g. a shared DCR) that causes a problem. If a user just regenerates the page that referenced the file, all they see is a success message. We can print the error out to the output file, but sometimes the users don't check these as they should.

We've found that any CGI's that create too much STDERR will freeze. In our custom CGI's, we always capture the STDERR of any calls so it's not a problem. However, the regenerate menu item does not do this. If you try to regenerate a bunch of files at once, and each one is spitting out a bit of STDERR, the whole operation will eventually freeze. This has been a problem since TS 5.0 was introduced and I'm not aware of any solution.

Migrateduser

Right but if you remove the default regenerate and replace it with a custom one that calls iwpt_compile.ipl and redirects stderr and stdout then you can present the error to the user (and possibly delete the output file). I also call iwpt_compile.ipl in workflow scripts (though this can make the last modified user show as SYSTEM) and transition to the error control task if it generates any output. Something like:

my ${cmd} = "${perl_binary} ${iwhome}/bin/iwpt_compile.ipl" . <options>;

my ${output} = `${cmd} 2>&1`;

if ( length( ${output} ) > 1 )
{
<handle error>
}

Actually this raised another issue. When a user in the local admin group on Windows uses the regenerate custom menu item the generated file shows last modified by their user ID. When a user not in this group uses the same menu item the file shows last modified by SYSTEM. Any ideas? TeamSite 5.5.2 on Windows 2000.

Actually there are no backticks in my code, that's in a module (because workflow externaltasks don't handle stderr properly on Windows so I set an environment variable at the top of the script that causes the subroutine that calls command lines to redirect STDOUT and STDERR to a file and then read the file if that environment variable is set).

The more you dig the more bugs you find.