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

Page Generation Error

matty_mouse

Greetings all,

I have a custom page generation system that I'm developing here, and I've run into an error I was hoping someone here would be able to help me out with.

I have a PT, and that PT calls various functions from a custom perl module to generate HTML output. Currently the PT generates 3 pages via ostream; the default page (which is just a dummy page that links to the other 2 generated pages; it only exists because I need a 'main' file), the English HTML page and the French HTML page.

The PT loops over an array of languages (English + French currently) and for each language it automatically creates the required htdocs subfolders for all pages to be generated, assembles the HTML output, generates the page, and then sets some extended attributes on the generated page.

Everything seems to be working except one thing: When I try to generate the page manually from the DCR (ie: Actions, Generate Page) and enter the relative path from the WORKAREA (ie: htdocs/eng-fra/index-index.html) and then click Ok, I get this error: "You cannot write in the area-level directories.". If I SSH into the machine and use iwpt_compile, I'm able to generate the 2 language pages without issue, but the dummy page isn't generated.

Does anyone know what may be causing this? Is it possible that something in my PT is overwriting the value of the "Select an Output File" field in the "Generate Options" form? The problem seems to be related to one of the folders that is created automatically (htdocs/eng-fra); if I create that folder in advance, it generates manually (and via iwpt_compile) without issue.

I can attach the PT and related perl module should someone want to look through them (but they are still a work in progress, so I'll only attach my mess of code if it's needed/requested).

Thanks in advance to any who take the time to look at this, and a BIG thanks in advance to those who post potential suggestions/solutions. The problem is summarized below (in case anyone is like me; I find a summary helpful after reading a bunch of text).

Cheers,
Matt

(TS 6.7.2 SP 1 on RH Linux)

In summary:

Problem:
- Manual generation chokes with error "You cannot write in the area-level directories."

DCR: /default/main/prod/public/microsite/WORKAREA/microsite/templatedata/common/generic/data/eng-fra/index-index

Creates folders:
- /default/main/prod/public/microsite/WORKAREA/microsite/htdocs/eng-fra/
- /default/main/prod/public/microsite/WORKAREA/microsite/htdocs/eng/
- /default/main/prod/public/microsite/WORKAREA/microsite/htdocs/fra/

Generates:
- htdocs/eng-fra/index-index.html (dummy file)
- htdocs/eng/index.html
- htdocs/fra/index.html

Find more posts tagged with

Comments

Rick Poulin

I'd like to see how you're redirecting the output with the ostream. I find it unlikely that you're overriding the target path you put in the dialog, but you might be reading that value and/or applying it in a way that doesn't work in all situations or is otherwise "unsafe". Perhaps you could post just those parts of your PT in a quick code block. My gut feeling is that the directory isn't being created automatically under a certain set of circumstances, and your ostream is somehow interpreting that as having no path at all, instead trying to conjure up a directory that's not writable.

matty_mouse

Hi Rick,

Thanks for your time, and your response. I've attached the entire TPL, and relevant subs in the PM. Pardon the mess; this is my first Perl module and I'd just like to get everything working before I clean up the code.

I have a hard time believing I'm overriding the dialogue box value, but I've built something very similar (something that generates the same 3 files; the only difference is that this is calling functions in a Perl module because I'm trying to centralize the common code) and it works just fine. I've gone through them both many, many times to try to find my mistake, but to no avail. The default page is (should) be created using a plain old iw_ostream tag, so I'm at a loss.

Thanks again for having a look at this; it's caused some grief the last couple of days!!

Cheers,
Matt

Adam Stoller

If the issue only occurs when the output directory path does not yet exist, that would seem to indicate either:

- and then run the PT both from the command line with iwpt_compile.ipl and from the GUI - and compare the results.

matty_mouse

Thanks for your response, Adam. I added some UID and GID logging to the PT, and generation attempts from both the shell and the GUI use my UID and GID.

I am using the File: Smiley Tongue ath module to create the directory if it doesn't exist, ie:
if(!-d $mkdir_eng) {
umask(002);
mkpath($mkdir_eng, {error => \my $err, verbose => 0, mode => 02775});
}

Of particular note is the fact that I can generate (via the GUI) just fine if I do not use the htdocs folder in the path. For example, my normal "Select Output Path" value when generating from the GUI would be "htdocs/eng-fra/index-index.html" (which fails with the aforementioned error - "You cannot write in the area-level directories."). But if I use just "eng-fra/index-index.html" or something else at the same level ("english-french/index-index.html") then it works.

The htdocs folder has the same permissions and owner as its parent:

[mousem@deucalion microsite]$ pwd
/default/main/prod/public/microsite/WORKAREA/microsite
[mousem@mousey microsite]$ ls -la
total 3
drwxrwxr-x 5 mousem mousem 512 Jul 12 15:57 .
dr-xr-xr-x 3 mousem mousem 512 May 26 14:48 ..
drwxrwxr-x 2 mousem mousem 512 Jul 12 15:57 htdocs
-rwxrwxr-x 1 mousem mousem 92 Jul 12 15:21 log.txt
drwxrwxr-x 2 mousem mousem 512 May 26 14:48 perl
drwxrwxr-x 3 mousem mousem 512 May 26 14:49 templatedata

[mousemmousem htdocs]$ pwd
/default/main/prod/public/microsite/WORKAREA/microsite/htdocs
[mousemmousem htdocs]$ ls -la
total 3
drwxrwxr-x 2 mousem mousem 512 Jul 12 15:57 .
drwxrwxr-x 5 mousem mousem 512 Jul 12 15:57 ..
lrwxrwxrwx 1 mousem mousem 73 Jun 17 16:07 css -> /default/main/production/oneweb/mousem/WORKAREA/mousem/htdocs/wet/css
lrwxrwxrwx 1 mousem mousem 76 Jun 17 16:07 images -> /default/main/production/oneweb/mousem/WORKAREA/mousem/htdocs/wet/images
lrwxrwxrwx 1 mousem mousem 78 Jun 17 16:07 includes -> /default/main/production/oneweb/mousem/WORKAREA/mousem/htdocs/wet/includes
lrwxrwxrwx 1 mousem mousem 72 Jun 17 16:07 js -> /default/main/production/oneweb/mousem/WORKAREA/mousem/htdocs/wet/js

I'm really at a loss here. If anyone has any other suggestions, I'd appreciate them. Regardless, thanks for taking the time to read this.

Cheers,
Matt

Adam Stoller

Hmm - looks like reasonable coding.

You might try adding:

use CGI::Carp qw(fatalsToBrowser);

in an iw_perl block in your PT - not sure if will help, but you might get better diagnostics when trying to run it from within the GUI (if not, remove it)

For the sake of trying to narrow down the issue - try changing the mode on your mkpath call from 02755 to just 755 - perhaps the problem is coming from setting the sticky bit on the directory?

Also - add to your debugging output the value of '$mkdir_eng' - to make sure that it's what you believe it should be (specifically when generating from the GUI) - perhaps somehow you're not getting the full path you expect to be getting and the permission problem is because you're trying to create a directory where you cannot --- and do the same with the other path-related variables, specifically with whatever you use for the output file name.

matty_mouse

It must have been some kind of problem with the folder itself; I deleted the symbolic links within htdocs, then htdocs itself, recreated them all, and it's working fine now. I don't like blindly stumbling upon a solution without understanding why ti was necessary in the first place (so I am not entirely happy with this 'cheap fix'), but time is money, I guess.

Thanks very much for your help, advice, and time. I just wish I had something positive to close this with (ie: the cause).

Have a terrific day.

Cheers,
Matt

Grill KPI.rptdesign