We love includes (or SSI) !!!

[richsky]

Hi there,

I'm currently posting this message to help and motive Macromedia developpers
team and people who are working with php includes or server side includes.

Why use them? To repeat elements through a website and change them from a
single file.

Can I use them? In php if your host have it or in SSI if not.

How to use them? When working with php use the include command <?php
include('http://www.mysite.com/myincludefolder/myincludefile.php); ?> that you
place in your Template.
Create a php file with the html code (and no more than that) you want to
appear in all your pages and place it in [url]http://www.mysite.com/myincludefolder/[/url]
naming it myincludefile.php

All your pages then should have the .php extension (don't forget to create a
..php template .php.dwt and to set .php for all new files dreated in Contirubte
(see admin, new files).

It's more or less the same with SSI, use .shml extension for files (your
includes can be .html). To include file use the command: <!--#include virtual=
"http://www.mysite.com/myincludefolder/myincludefile.html" -->

For your Contribute users, they have to manually browse to
[url]http://www.mysite.com/myincludefolder/myincludefile.xxx[/url] (or follow links you
provided on a page).

Now the bad:

Since Contribute allow you to use the specified CSS in your head tag, you
won't see your style in these includes file (remember they only contain the
portion of code you want to appear everywhere in pages that already contain
html, head, body etc. tags.

Even more bad:

Included files may contain images, and because includes file could be included
in pages anywhere in the website, the image path must, like the include be
absolute eg:
([url]http://www.mysite.com/pagesfolder/specificeimagefolder/myimage.jpg[/url])
If your include files contain images and you set up images files to be
relative to documents (images/) edited by Contribute Users (in admin, edit user
role, file placement). Contribute users that might change images will create a
relative path instead of an absolute path (cause you set images to be in
images/ for exemple).

Macromedia recently reported this problem without explaining it completly and
without bringing any Contribute side solution (yet, I said "yet" didn't I?):

Site root-relative image tags are rewritten as document relative links
topic update: September 16, 2005

Issue
When using images in server side includes or other documents that would
require a site root-relative reference, Contribute is rewriting the path to be
document relative when editing the server side include. Here is an example of
the code:

Desired site root path for the image (site root-relative)
/images/my_photo.jpg

Code that Contribute saves (document relative)
../images.my_photo.jpg
Solution

Here are a couple of suggested workarounds.

* Use Dreamweaver or another tool for editing the file.
* Define the path as an absolute path (this option is not fully effective
in all situations)
" [url]http://www.mysite.com/images/my_photo.jpg[/url] "
Includes are part of effective, non database driven websites (and I guess more
than 95% of the actual published websites are not using any database). But if
you intend to make them editable by Contibute Users (change a menu, banners
repeated on every page, etc...) take care.

I wish we are all about to find a quick solution, since this problem seemed to
occur only last week ; )
So any idea?

Note: I'm not a php guru, nor a developper, I mean who received coding
education. Dreamweaver is helpful (I started aslo hand coding, but who cares)
as is Contribute since we'd like "normal" humans being to easly publish their
content on the web.

[aliencosmo]

I also like to use SSI and have designed a number of sites that use SSI, ASP,
or PHP for this. I have been working around the problems with Contribute and
SSI by using Dreamweaver-style templates instead of includes.

Template have their own problem. If I need to change something on a template,
I have to update ALL of the pages in the website that use that template. That
means downloading the ENTIRE website, updating the templates for all the files,
checking them all out in the process and then saving them back to the server.

Now if I had used a server-side include, I would have simply been able to make
the change on the included file and only save ONE file back to the server --
all the other pages in the site would pick up the most recent version of the
included file as the page is being sent to the browser.

My understanding is that SSI is efficient in terms of using server resources,
as well. It takes about the same amount of server processing power as including
an image in an HTML page.

It would be very nice to (in Dreamweaver or Contribute) be able to
double-click on an included file from the enclosing page and be able to edit it
with the styles from the enclosing page being intact.

[PerfectShot]

Just a thought: wouldn't it be smarter to use root relative paths instead of
absolute paths?
eg. /inc/ instead of [url]www.mysite.com/inc/[/url] ?
That way its much easier to migrate a site to a different address and it can
be worked on life from any off-line station...


One question: if you use includes in html files, shouldn't the site use shtml
extensions?

I can change the httpd.conf to tell the server to look inside html for include
statements but that doesn't seem smart (I didn't create the site btw).

[richsky]

In php it seems that you have to use
"http://www.mysite.com/includefolder/include.php" but for SSI <!--#include
virtual= "/myincludefolder/myincludefile.html" --> work just fine and provide a
more portable website.

And yes, your site must have shtml extension if you use SSI.

It's more or less the same with SSI, use .shml extension for files (your
includes can be .html). To include file use the command: <!--#include virtual=
"http://www.mysite.com/myincludefolder/myincludefile.html" -->

[Crow_Song]

As an administrator, I don't WANT my users to have access (by way of
double-clicking) to most of the includes for editing. I DO, however, want them
to edit their side menu, which is an include. And they can. They simply click
the CHOOSE button, and select the include. Edit Page. Done. As long as you make
that include straight HTML, they can edit it.

[Crow_Song]

Here's a BIG problem with includes in PHP and Contribute. I don't know what to
do with this one:
My 100+ users use Contribute to edit their pages, which I've set up for them
with a side menu that is an include file. I've told them how to edit this file
(see above, using the Choose button), but - just like the image problem -
Contribute makes all of the links that they create in the side menus relative
to the current directory, instead of the root. This is really not good - and
makes no sense at all. This means that only the pages in the directory with the
index page have working links in their side menu. Every other page that
includes the side menu will have broken links.

Using included files for navigation in this manner is pretty standard
practice. Why would Contribute's behaviour be to use relative links, instead of
root-relative? I even tried to edit the link properties and insert manually the
root path, but Contribute overwrote it with the relative path instead. This is
BAD. I don't know what to do. My users are getting very frustrated. Any
suggestions?

[Alexander Ross]

untried/untested suggestion:

make your links like this:

<a href="<?=$_SERVER['DOCUMENT_ROOT']?>/dir/subdir/file.html"> ... </a>

It ain't pretty, and you may need to chunk off some funky server directory
structure, but that wouldn't be too hard. UGLY, but it should work.

--
Alex



"Crow_Song" <webforumsuser@macromedia.com> wrote in message
news:dhc8c6$cup$1@forums.macromedia.com...

> Here's a BIG problem with includes in PHP and Contribute. I don't know
> what to
> do with this one:
> My 100+ users use Contribute to edit their pages, which I've set up for
> them
> with a side menu that is an include file. I've told them how to edit this
> file
> (see above, using the Choose button), but - just like the image problem -
> Contribute makes all of the links that they create in the side menus
> relative
> to the current directory, instead of the root. This is really not good -
> and
> makes no sense at all. This means that only the pages in the directory
> with the
> index page have working links in their side menu. Every other page that
> includes the side menu will have broken links.
>
> Using included files for navigation in this manner is pretty standard
> practice. Why would Contribute's behaviour be to use relative links,
> instead of
> root-relative? I even tried to edit the link properties and insert
> manually the
> root path, but Contribute overwrote it with the relative path instead.
> This is
> BAD. I don't know what to do. My users are getting very frustrated. Any
> suggestions?
>

[Crow_Song]

> make your links like this:

> <a href="<?=$_SERVER['DOCUMENT_ROOT']?>/dir/subdir/file.html"> ... </a>
> It ain't pretty, and you may need to chunk off some funky server directory
> structure, but that wouldn't be too hard. UGLY, but it should work.

Thanks for the suggestion. I don't think I can ask my users to do that,
though. These are not particularly computer-literate users, and I put them onto
Contribute for that reason. I need easy - and that isn't easy. I'm somewhat
disappointed in Contribute for this. I've had to manually "fix" their side
menus after they've created links in them.
:frown;

[richsky]

Hi,

Thanks Alex, but where looking for Contribute Users to change includes.

For simple links, problem can be fix by Contribute Users themselves. We
suppose our include is in a folder in the root level and our page we want to
link to is an other folder in the root level too). What's going Contribute to
write?

Something like ../mypagesfolder/mypageIlinkto.php for exemple... If you use
this include to naviguate, the page containing this include may be two or three
level below the root, the link is going to be wrong because it should be
.../../mypagesfolder/mypageIlinkto.php or
.../../../mypagesfolder/mypageIlinkto.php, etc...

But this problem has an issue, you just fix the link manually in Contribute in
the insert link panel. Change the HREF so it's:
/mypagefolder/mypageIlinkto.php, an absolute link (a bug here, in order to make
it accepted by Contribute, click in a drop down (like the ancor section or the
taget frame before clicking OK).

So here's the way to set links in Contribute when Contribute users udates
includes.

But as I said in the very first post, it's the image linking from includes
that is a problem since I can fix the link manualy.

So a part problems, any solution?

[Alexander Ross]

gotcha .... I was thinking about your users changing other content in that
section (not necessarily the links) and then when they save (even though
they hadn't touched the links) the links break. But if your having the users
create their own links then you're right, this ain't gonna fly...



"richsky" <webforumsuser@macromedia.com> wrote in message
news:dhe9c9$ck4$1@forums.macromedia.com...

> Hi,
>
> Thanks Alex, but where looking for Contribute Users to change includes.
>
> For simple links, problem can be fix by Contribute Users themselves. We
> suppose our include is in a folder in the root level and our page we want
> to
> link to is an other folder in the root level too). What's going Contribute
> to
> write?
>
> Something like ../mypagesfolder/mypageIlinkto.php for exemple... If you
> use
> this include to naviguate, the page containing this include may be two or
> three
> level below the root, the link is going to be wrong because it should be
> ../../mypagesfolder/mypageIlinkto.php or
> ../../../mypagesfolder/mypageIlinkto.php, etc...
>
> But this problem has an issue, you just fix the link manually in
> Contribute in
> the insert link panel. Change the HREF so it's:
> /mypagefolder/mypageIlinkto.php, an absolute link (a bug here, in order to
> make
> it accepted by Contribute, click in a drop down (like the ancor section or
> the
> taget frame before clicking OK).
>
> So here's the way to set links in Contribute when Contribute users udates
> includes.
>
> But as I said in the very first post, it's the image linking from includes
> that is a problem since I can fix the link manualy.
>
> So a part problems, any solution?
>
>
>

[shawnrhod2]

Not sure if this helps, but I?m having a problems with Contribute mapping the
temporary (draft) documents. I use includes and .net user controls.

Initially when I would make a change and send for review the page would break
upon preview from my side or the recipient?s side. After a little investigation
I saw Contribute holds these files in a temp folder for review. Therefore any
files referencing the includes, CSS, user controls or images are looking in the
relative path and are breaking the page. Dot.Net has a feature that
automatically remaps all files using the ?~? to the parent directory of the web
server. I don?t think it works with other development environments. I?m looking
for something that will work right in the html (not wrapped in a .Net server
control). The map can be to the web site root or the parent IIS directory.
Anyone whom has code for this seemingly basic feature please advise.

Using the ?~? all server files will start being mapped from the IIS web
directory, no matter where that file is initially called from. For instance, if
you were referencing the user control (which acts like an include in this case)
called myUserControl.ascx, it would be mapped as such:

Relative Path - this works as a normal web site mapping, however breaks when
previewing in Contribute:
controls/myUserControl.ascx

Contribute?s temporary path for the edited/pending web page itself ? when you
send the draft the web page is saved somewhere for review before publishing.
Obviously there is no way the relative path will work with the web page in such
an obscure folder:
MMWIP/3214ccce5ac6c007/847c22db2e5f7b7a.aspx

You could use the web sites absolute path ? but this is no good when reviewing
or moving files from directories or web sites.
[url]http://www.website.com/controls/myUserControl.ascx[/url]

A dot.net work around ? there maybe a better way, but this works.
~/website/controls/myUserControl.ascx

Explanation:
~ (puts you way up in the wwwroot directory)/website(folder the specific web
site sites in)/controls(folder the control you are calling sits
in)/myUserControl.ascx(actual control being called.

Actual code:
<%@ Register TagPrefix="uc1" TagName="globalNav"
Src="~/website/controls/globalNav.ascx" %>

If anyone has comments or suggestions, please advise. I just started to use
contribute and want to deploy ASAP. This is my main issue thus far. It seems so
basic but I haven?t seen anything in the help file or forums so far.

Shawn