Apologies for the late reply.
On 4/14/07, Alan in Toronto <Alantoronto@xxxxxxxxxxxxxxx> wrote:
> On Fri, April 13, 2007 8:52 pm, Paul Lesniewski wrote:
> > On 4/13/07, Alan in Toronto <Alantoronto@xxxxxxxxxxxxxxx> wrote:
> >> Currently I'm working on a site that is located in a sub-directory of my web
> >> hosting
> >> account. When it's complete, I'll move it to the server of the non-profit group
> >> I'm
> >> doing this for, where presumably it will live at the web root (directly under the
> >> domain name). Ideally I'd like to have to change some central variable rather than
> >> have to change paths on every page or in every script.
>
> > Much of this depends on WHAT you are working on.
>
> It's a script to enable the site navigation menu to live in a separate HTML file,
> currently Menu.htm. I want to keep most of the PHP in a separate file or files, such
> as currently in Menu.php. That way the content web pages are mostly straight HTML
> with just a small amount of PHP at the top such as the includes.
>
> Each web page will ultimately grab Menu.htm via PHP include. This enables easier
> maintenance of the navigation menu, as only that one file needs editing when new
> pages are added or links changed. When the file is included, PHP will also identify
> the currently-viewed page by writing an attribute into the Anchor of the nav menu
> link to that currently-viewed page.
FWIW, have a look at SM's php_self() function to see how we try to get
the current page request in a reliable manner. That value is useful
when you need to do things like indicate what page is currently being
viewed.
> > It also depends where you are needing to use this kind of code.
>
> The include is inserted in each content web page where I want the navigation menu to
> appear. It would be good to do this in such a way that the include_once statement
> always uses the same path, so that it doesn't need to be different for web pages
> calling the include from varying levels of nested directories. IOW, the site will
> have content pages in directories and sub-directories and it would simplify site
> creation and addititions if the include_once line were always the same and did not
> have to change depending upon what directory level the content web page resides in.
Each page request is stateless, so you always have to make some sort
of determination as to where other files are that you need for every
page requested. That's, in the SM world, the determination of SM_PATH
near the beginning of each page request.
> Using your "home" directory variable idea, at the top of each content web page
> (before the doctype declaration) I have this (yes, I realize I can name SM_PATH
> whatever I want, but for now that makes it obvious to me what I'm doing and that it
> was your suggestion):
>
> <?php
> define('SM_PATH','../');
Right. This has to, of course, be maintained on a per-file basis
unless you do something more complex like SM 1.5.x does.
> $file_name = basename($_SERVER['PHP_SELF']);
If you don't need to worry about portability, this is fine, but see my
comment about php_self(). I'd also recommend a better variable name.
> include_once(SM_PATH . 'CSSetc/Menu.php');
> ?>
>
> Later in the page, where I want the menu to appear, I have this:
>
> <?php echo $nav; ?>
>
> Menu.php contains, in addition to other code, this line:
> $nav = file_get_contents("CSSetc/Menu.htm");
>
> Menu.htm is just the navigation menu, HTML only.
Then there is no reason to go round-about by reading the file into a
variable and echoing it. Remove all this stuff and simply use one
line where the menu should be output:
<?php require(SM_PATH . 'CSSetc/Menu.htm'); ?>
If the menu needs any dynamic stuff, make it a php file.
> > define your own "home" directory variable (constant is better)
> > and use it EVERYWHERE you refer to a file in PHP.
>
> > here is how SM does it. Look at /src/compose.php:
> > First thing it does is define the relative path to the main
> > application directory. After that, all files are included using that
> > constant.
>
> /src/compose.php contains:
> define('SM_PATH','../');
>
> /plugins/newmail/newmail.php contains:
> define('SM_PATH','../../');
>
> Thanks, I've now added something similar to my pages, and it works, so that's one
> issue you've solved. So, I need to ensure that in that "define" line I add another
> "../" each time a page is in a lower-level sub-directory. I'm not missing something,
> that there's some automated way to accomplish that, am I? I assume that when adding
> that "define" line to each page that you must first know how many directory levels
> deep the page will be, so as to add the right number of "../"
Yup.
> > if you have things like links and image tags in plain HTML, then just
> > make sure all the files those point to are done with RELATIVE links.
>
> Yes, that's what I always do. e.g. I always use references such as
> link rel="stylesheet" href="../../CSSetc/Mainsite.css"
> That's fine for linking a stylesheet or images, but is a problem in the Menu.htm
> because it gets included into content web pages that live in varying directory
> levels. So a relative link in Menu.htm that works from one directory deep doesn't
> work from two directories deep. Your sqm_baseuri() idea might be that way to deal
> with that.
Yes. Although in a simple environment, you can actually just use
SM_PATH (or whatever you choose to call it) - that makes it pretty
easy.
> > If you need to calculate hrefs and things like that in the PHP code,
> > it can be a little more complicated, but doesn't have to be for simple
> > sites. See how SM calculates $base_uri in the sqm_baseuri() function
> > in strings.php in STABLE (note that $PHP_SELF is constructed in the
> > function php_self()). In most simple cases, you can simply include a
> > "startup" file (after you define the constant pointing to your main
> > app dir per above), and in that startup file, just set another
> > constant that contains the base URI for use in hrefs and such things
> > throughout the code. Then you only have to change that value when you
> > move the site.
>
> Sorry, could you spell that out a little more step-by-step? I think I understand the
> concept, of specifying a base location in one single file and then having that value
> written into each content page. I'm just not clear on what I need to do to create
> all that.
In one (each) of the requested pages:
<?php
define('SM_PATH', '../../');
require(SM_PATH . 'startup.php');
?>
.... rest of HTML here....
In startup.php, which resides in the main site directory:
<?php
global $base_path = SM_PATH;
$base_path = SM_PATH;
....
Back in the HTML in any of the requested pages:
For more info, <a href="<?php echo $base_path;
?>CSSetc/Mainsite.css">click here</a>.
> I had wondered about using BASE HREF in each web page's HTML head.
This could be even more graceful (less PHP intrusion into the HTML)
than the above idea, but still very much the same thing.
> To avoid having
> to change the BASE HREF in each file once the site is complete and is moved, I
> wondered if there's a way to use PHP to write the BASE HREF into each file by
> getting the value from a central location. Then when the site moves, I'd only have
> to change that value in the one file, and PHP would insert it automatically into the
> content pages. For instance, maybe something like this?:
> <base href="<?php echo $site_base ?>">
>
> Perhaps that's what you're doing too, but being such a PHP newbie I couldn't figure
> out what specifically to write and do to execute your suggestion.
>
>
> Also, is there a reason why PHP comments in SM files begin with slash and two
> asterisks?
One-liners start with //
Multiple-line comments start with /* and end with */
> I know there's some difference between single quotes versus double quotes, but in
> many PHP examples they seem to be used interchangeably. For instance, I was using
> this include line:
> include_once("CSSetc/Menu.php");
> But I see that you use single quotes instead. Would it be better for me to change
> such references to single quotes?
Double quotes are interpolated. That is, if you put a variable name
in the quoted string, it is changed to the variable value with the
string is output. Single quotes echo the string as is, so the dollar
sign would have no special meaning. There is thought by some to be a
performance difference due to saving the interpolation cycles when the
string is processed, but it seems that real-world testing doesn't bear
much difference... it's more of a stylistic and clean-code thing.
> Thanks for your help. I'm already further ahead thanks to you, as usual.
np
-paul
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
squirrelmail-users mailing list
Posting Guidelines: http://www.squirrelmail.org/wiki/MailingListPostingGuidelines
List Address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx
List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
