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

previewing PHP includes

mick

does anybody know if there is a way to get PHP files to preview and virtualise correctly when using include() and/or require() statements? e.g. we are using include() in our PHP files to include html code for the page headers/footers - the same header/footer code is inserted into html pages using SSI.

we're using TeamSite 5.0.2 running on Solaris.

i can make this work by inserting (using presentation template) some custom PHP code into every page that uses an include() but would rather not clutter pages with unnecessary code if there's a way around this.

mick :-)

Find more posts tagged with

Comments

Adam Stoller

I'm not all that familliar with PHP - but could you perhaps do something with iwproxy - under the [iwproxy_remap] or potentially the [iwproxy_plugin_remap] section (since you indicate that it is similar to SSI - or are you saying that the PHP include is *within* the SSI?

It might be informative if you run iwproxy in debug mode while trying to render the page within TeamSite (in the case of [iwproxy_plugin_remap] - I believe you have to put an entry in the iw.cfg file within that section: _debug=true) - a read through the Admin manual on iwproxy configuration and debugging would probably not go amiss here

--fish
(Interwoven Senior Technical Consultant)

laj1

Except that PHP wont hit the proxy to perform an include. It will do filesystem access to process the statement.
Our friend is stuck, most likely due to an expectation that header.php and footer.php will live in a particular place, but on teamsite,
that place is really a different branch.

Now, I do my TS work on Win2000, so I can't test this theory, but you might be able to make creative use of symbolic links from one work area into another inside your backing store.

It means creating a bunch of symlinks, but you can script that in perl real easily.

Len.

Len Jaffe
My Heart Is A Flower
Update your DevNet profile - let us know who you are!

Johnny

Maybe relative links instead of absolute might do the trick.

John Cuiuli
Sydney, Australia

mick

yep, i've been trying to figure out how to get the filesystem path to the header/footer using available env. variables - normally something like
$_SERVER["DOCUMENT_ROOT"]/web_root_relative_path_to_header.lib will work but with TeamSite using proxy to preview and virtualise files the DOCUMENT_ROOT is something like /var/apache/htdocs instead of the workarea path under /iwmnt

i'll try some sym. links. from /var/apache/htdocs - that should solve the problem.

thanks Len.

mick :-)

Migrateduser

I didn't follow this whole thread but would it be possible to read the docroot from a cookie? I think I remember it being stored in a cookie,

laj1

You bet.

if the symlinks don't work. You could consider using an env variable othet than DOCUMENT_ROOT, but you'd have to set it yourself, in a global way, so every server in the chain couls access it. The only time I could see that getting really sticky, is if you put multiple "sites" onto teamsite, where each needed a unique setting for the common files directory.

Len.

Len Jaffe
My Heart Is A Flower
Update your DevNet profile - let us know who you are!

mick

you got it spot on!

we've got multiple sites and also don't own the destination web servers - don't think our ITS support guys would really want to create a whole lot of custom env. vars for us.

i think i'll stick to sym. links on our TeamSite server - just have to make sure the name of the directories holding common files are different for each site - this has fallen out by itself so far in our site architecture design - hopefully any new sites will follow this trend.

mick :-)

laj1

Does this mean that the symlinks worked for you?

Len.

Len Jaffe
My Heart Is A Flower
Update your DevNet profile - let us know who you are!

mick

yes, the sym. links are working!
thanks Len.

we still have a problem when previewing a file that has used doc relative include() -- since the previewed file is not in the directory that the final generated file will be -- but this is a problem for all doc relative links not just a PHP thing.

At least now all the absolute path includes will work without the need to insert custom PHP code into every page.

mick :-)

laj1

we still have a problem when previewing a file that has used doc relative include() -- since the previewed file is not in the directory that the final generated file will be -- but this is a problem for all doc relative links not just a PHP thing.

I don't follow this in terms of PHP.
how do the dirs differ, and how does the "doc relative" include spoil you fun?

Len.

Len Jaffe
My Heart Is A Flower
Update your DevNet profile - let us know who you are!

mick

this is only a problem when previewing from a DCT.

because the temporary preview file is generated into a 'cmspreview' directory and not in the final generated file location, any doc relative paths will be pointing to the wrong place.

mick :-)

Johnny

Is this a generic template that could have many locations?

Maybe you could have the preview-dir point to same location as the generated page?

The tmp preview file can be a pain... especially when people like to use relative paths to images etc!!!

John Cuiuli

mick

yep, files generated from this template can be located pretty much anywhere within the whole web site -- so pointing 'preview-dir' to the same location as a generated page is not really an option :-(

mick :-)