[PHP] Site structure and sessions
I am contemplating the structure for a new site. I would like to organize the site with sub domains as in domain.com subdomain1.domain.com subdomain2.domain.com subdomain3.domain.com I understand that sessions are not passed from domain to domain or domain to subdomain. I did some searching and found out a few things. There doesn't seem to be much on the subject. There is a setting in php.ini called session.cookie_domain. It is normally left set to . However, you can set it to your domain and php will use that domain to store all sessions. This allows you to use sessions across domains. This is fine if your domains are the only domains using php on the server. I happen to use an ISP so changing the ISPs php.ini file is not an option for me. I can use ini_set() and temporarily modify the value of session.cookie_domain for the life of the script as in: ini_set(session.cookie_domain, .domain.com); The . before domain.com is needed so that it is available to subdomains as well. This line needs to be called before session_start(). I could put this in an include file and call it from each page that uses a session. I also read that ini_set() can be used in an .htaccess in the root directory of each domain, subdomain and directory where pages may use sessions. It would look something like: php_value session.cookie_domain .domain.com Setting the value in an .htaccess would be a lot easier than including ini_set(session.cookie_domain, .domain.com); on each page that uses sessions. I have not tested any of these options as I am now gathering info in order to make a decision. I would appreciate any feedback on organizing the site, using subdomains, and passing session values from domain to domain. Is this more trouble than it is worth? Should I just use directories to organize the site? Thanks in advance, Blaine -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Site structure and sessions
* Thus wrote Blaine ([EMAIL PROTECTED]): I also read that ini_set() can be used in an .htaccess in the root directory of each domain, subdomain and directory where pages may use sessions. It would look something like: php_value session.cookie_domain .domain.com Setting the value in an .htaccess would be a lot easier than including ini_set(session.cookie_domain, .domain.com); on each page that uses sessions. Yes, this is a wiser choice vs. setting it system wide. You do have another alternative which would be to use the 5th argument in set cookie: bool setcookie ( string name [, string value [, int expire [, string path [, string domain [, int secure]) I have not tested any of these options as I am now gathering info in order to make a decision. I would appreciate any feedback on organizing the site, using subdomains, and passing session values from domain to domain. Is this more trouble than it is worth? Should I just use directories to organize the site? In general allowing subdomains (.yourdomain.com) is safe. But as a hosting company you might perhaps allow that cookie to be modified by other people if say you set up a simple hosting site for a user: user.yourdomain.com/ or yourdomain.com/~user/ But from what it looks like you arn't planing on using that methodology, for users. I tend to stay away from directories and use subdomains to distinguish between different aspects of the site as per some examples: domain.com main web pages for domain www.domain.com main web pages for domain dbadmin.domain.com Database interface logs.domain.com View my logs. Now going back to your cookie issue, you really dont want dbadmin and logs to be using the same cookie namespace. The only namespace you would want to share would be the www.domain.com and domain.com, because they are pointing to the same place. You could also opt out of using the cookie method of passing session id around and use the php SID query paramater. But you then have to be careful at which domains you going to pass your SID too. On the other hand you have more control and it is expected to work even if the user refuses your cookies. HTH, Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Site Structure
G'day all, I thought I'd mention how I developed my last project and got
around some of these problems, bear with me it can be quite complicated.
===
In the development we had to develop on many different servers, mine at
home, my partners at his place then two different ones at work. Here's the
site structure (Red Hat 7):
/var/www/api/ -- all my code outside of the web tree
config/-- where all the API's config files go (*.cfg)
0.1/ -- version 0.1 of my API
modules/ -- all of my 0.1 version modules (*.lib)
0.2/ -- version 0.2 of my API
modules/ -- all of my 0.2 version modules (*.lib)
/var/www/html/v1/ -- version 1 of the site (/html is Red Hat 7's name
for
/htdocs)
/var/www/html/v2/ -- version 2
---
[in PHP.INI]include_path = .:/var/www/api/config:/var/www/api/modules
In each /HTML/?? directory there is a file - api_connect.cfg
[in api_connect.cfg]include 'api01.cfg'
This basically says use version 0.1 of the API for this website. This way as
I experiment and change my source code I can make an entire new version
branch of my source code (i.e., make /var/www/api/0.3/modules) and change
the 'api_connect.cfg' file to suit.
* How to access in a PHP and/or HTML-hybrid file?
Easy! ?php include 'api_connect.cfg'; ? at the top of your document.
--For-example--
My index file has a login form, therefore my index.html has the code
?php include 'api_connect.cfg';
// do other processing here, since that code sets up my API connection I
can use all my objects
$dbase = new ApiDbaseConn(); //etc, etc, etc
?
HTML
!-- blah, blah, blah --
/HTML
The include process would look like:--I-- Includes
/var/www/html/v1/index.html --I--
/var/www/html/v1/api_connect.cfg --I-- /var/www/api/config/api01.cfg
^
** NOTE: This link takes advantage of the /var/www/api/config entry in the
PHP.INI include_path directive **
==Now=What??===What=does=API??.CFG=do?==
===
This is where the fun starts ;) Below is a *censored ;)* API04.CFG file:
[API04.CFG]
---
//--begin-file-guard--
$included_flag='__API_CONFIG_'.basename(__FILE__);
if(defined($included_flag)) {return true;} define($included_flag,TRUE);
//--end-file-guard---
/***
***/
/*==FRAMEWORK===CONSTANTS===
==*/
/***
***/
define('API_VERSION', '0.4');
//==[SITE-DETAILS]==
define('API_DEBUG_ON', 0); // 0 - off; 1 - on
define('API_ERROR_ON', 0); // 0 - off; 1 - on
$czServerName = 'vandyk';
switch ($czServerName)
{
case 'vandyk': define('SLASH', '/');
define('API_PATH', '/var/www/api'.SLASH);
define('API_DBASE_PRIMARY','***CENSORED***');
define('API_DBASE_SECONDARY','***CENSORED***');
define('API_DBASE_DBASENAME','***CENSORED***');
define('API_DBASE_PASSWORD','***CENSORED***');
define('API_DBASE_DBASENAME','***CENSORED***');
$bIsUnix = TRUE;
break;
//---
case 'enki':define('SLASH', '\\');
define('API_PATH', 'C:\apache\api'.SLASH);
define('API_DBASE_PRIMARY','***CENSORED***');
define('API_DBASE_SECONDARY','***CENSORED***');
define('API_DBASE_DBASENAME','***CENSORED***');
define('API_DBASE_PASSWORD','***CENSORED***');
define('API_DBASE_DBASENAME','***CENSORED***');
$bIsUnix = FALSE;
break;
//---
RE: [PHP] Site Structure
This guy is proof that PHP programmers are a functional clever bunch and PHP
does not box us in with too many limits.
-Original Message-
From: Matthew M. Boulter [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 24, 2001 9:16 AM
To: Steve Werby; Toby Miller; indrek siitan
Cc: PHP General Mailing List
Subject: RE: [PHP] Site Structure
G'day all, I thought I'd mention how I developed my last project and got
around some of these problems, bear with me it can be quite complicated.
==
==
===
In the development we had to develop on many different servers, mine at
home, my partners at his place then two different ones at work. Here's the
site structure (Red Hat 7):
/var/www/api/ -- all my code outside of the web tree
config/-- where all the API's config
files go (*.cfg)
0.1/ -- version 0.1 of my API
modules/ -- all of my 0.1 version modules (*.lib)
0.2/ -- version 0.2 of my API
modules/ -- all of my 0.2 version modules (*.lib)
/var/www/html/v1/ -- version 1 of the site (/html is
Red Hat 7's name for
/htdocs)
/var/www/html/v2/ -- version 2
---
[in PHP.INI] include_path =
.:/var/www/api/config:/var/www/api/modules
In each /HTML/?? directory there is a file - api_connect.cfg
[in api_connect.cfg] include 'api01.cfg'
This basically says use version 0.1 of the API for this website.
This way as
I experiment and change my source code I can make an entire new version
branch of my source code (i.e., make /var/www/api/0.3/modules) and change
the 'api_connect.cfg' file to suit.
* How to access in a PHP and/or HTML-hybrid file?
Easy! ?php include 'api_connect.cfg'; ? at the top of your document.
--For-example--
My index file has a login form, therefore my index.html has the code
?php include 'api_connect.cfg';
// do other processing here, since that code sets up my API
connection I
can use all my objects
$dbase = new ApiDbaseConn(); //etc, etc, etc
?
HTML
!-- blah, blah, blah --
/HTML
The include process would look like: --I-- Includes
/var/www/html/v1/index.html --I--
/var/www/html/v1/api_connect.cfg --I-- /var/www/api/config/api01.cfg
^
** NOTE: This link takes advantage of the /var/www/api/config
entry in the
PHP.INI include_path directive **
==Now=What??===What=does=API??.CFG=do?
==
===
This is where the fun starts ;) Below is a *censored ;)* API04.CFG file:
[API04.CFG]
--
--
---
//--begin-file-guard--
$included_flag='__API_CONFIG_'.basename(__FILE__);
if(defined($included_flag)) {return true;} define($included_flag,TRUE);
//--end-file-guard---
/*
**
***/
/*==FRAMEWORK===CONSTANTS=
==
==*/
/*
**
***/
define('API_VERSION', '0.4');
//==[SITE-DETAILS]
==
define('API_DEBUG_ON', 0);//
0 - off; 1 - on
define('API_ERROR_ON', 0);//
0 - off; 1 - on
$czServerName = 'vandyk';
switch ($czServerName)
{
case 'vandyk': define('SLASH', '/');
define('API_PATH', '/var/www/api'.SLASH);
define('API_DBASE_PRIMARY','***CENSORED***');
define('API_DBASE_SECONDARY','***CENSORED***');
define('API_DBASE_DBASENAME','***CENSORED***');
define('API_DBASE_PASSWORD','***CENSORED***');
define('API_DBASE_DBASENAME','***CENSORED***');
$bIsUnix = TRUE;
break;
//---
case 'enki':define('SLASH', '\\');
define('API_PATH',
'C:\apache\api'.SLASH);
define('API_DBASE_PRIMARY','***CENSORED***');
define('API_DBASE_SECONDARY','***CENSORED***');
define('API_DBASE_DBASENAME','***CENSORED***');
define('API_DBASE_PASSWORD','***CENSORED***');
define('API_DBASE_DBASENAME','***CENSORED***');
$bIsUnix = FALSE;
break;
//---
case 'fontaine':// you get the idea
//---
case 'morillo':
// you get the idea
//---
case 'oakenfold': // you get the idea
}
//==[LOCATIONS
[PHP] Site Structure
Hi,
I have a site structure like:
- root
--- includes
--- admin
--- images
I'm using headers and footers and they are in the includes directory. My
pages in the root directory include the files like:
include('includes/header.inc');
Thats woprks fine, but i want to be able ti use the same headers and footers
in the admin directory but, of course, the paths are going to be wrong.
How can i get around this?
Any ideas,
Jord
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Site Structure
try
include('../includes/header.inc');
Sebastián Renzi
Consultoría Desarrollo de Sistemas.
CODES S.A
-Mensaje original-
De: Jordan Elver [SMTP:[EMAIL PROTECTED]]
Enviado el: lunes 23 de abril de 2001 11:56
Para: PHP General Mailing List
Asunto: [PHP] Site Structure
Hi,
I have a site structure like:
- root
--- includes
--- admin
--- images
I'm using headers and footers and they are in the includes directory. My
pages in the root directory include the files like:
include('includes/header.inc');
Thats woprks fine, but i want to be able ti use the same headers and
footers
in the admin directory but, of course, the paths are going to be wrong.
How can i get around this?
Any ideas,
Jord
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Site Structure
Or better yet:
include( $DOCUMENT_ROOT/includes/header.inc );
Martin Gottlieb
-Original Message-
From: Renzi, Sebastian [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 10:56 AM
To: 'Jordan Elver'; PHP General Mailing List
Subject: RE: [PHP] Site Structure
try
include('../includes/header.inc');
Sebastián Renzi
Consultoría Desarrollo de Sistemas.
CODES S.A
-Mensaje original-
De: Jordan Elver [SMTP:[EMAIL PROTECTED]]
Enviado el: lunes 23 de abril de 2001 11:56
Para: PHP General Mailing List
Asunto: [PHP] Site Structure
Hi,
I have a site structure like:
- root
--- includes
--- admin
--- images
I'm using headers and footers and they are in the includes directory. My
pages in the root directory include the files like:
include('includes/header.inc');
Thats woprks fine, but i want to be able ti use the same headers and
footers
in the admin directory but, of course, the paths are going to be wrong.
How can i get around this?
Any ideas,
Jord
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Site Structure
Hi, Thanks for the reply. I can do that but then the images will not be in the correct location? Jordan On Monday 23 April 2001 15:58, you wrote: give the include() function a complete path: include '/apache/htdocs/include/yourfile.inc.php'; -- Ben Cairns - Head Of Technical Operations intasept.COM Tel: 01332 365333 Fax: 01332 346010 E-Mail: [EMAIL PROTECTED] Web: http://www.intasept.com MAKING sense of the INFORMATION TECHNOLOGY age @ WORK.. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Site Structure
I would suggest putting your includes out of the web tree.
/.../website/htdocs/admin
/.../website/htdocs/images
/.../website/includes
This may be totally inappropriate for now, but is a good habit to get into.
Call the includes with the full pathname. I know this stinks, but is a good
solution if you define most of your path with a variable.
-Original Message-
From: Jordan Elver [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 10:56 AM
To: PHP General Mailing List
Subject: [PHP] Site Structure
Hi,
I have a site structure like:
- root
--- includes
--- admin
--- images
I'm using headers and footers and they are in the includes directory. My
pages in the root directory include the files like:
include('includes/header.inc');
Thats woprks fine, but i want to be able ti use the same headers
and footers
in the admin directory but, of course, the paths are going to be wrong.
How can i get around this?
Any ideas,
Jord
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Site Structure
Jordan, Not true. If you make your PHP includes look like this: include($DOCUMENT_ROOT/includes/header.inc); Then you can make your image calls with an absolute URL like this: img src=/images/image.gif width=10 height=10 border=0 Also, it's not a good idea to use the .inc extension unless you've associated it with PHP. The reason is if I type the URL directly to /includes/header.inc I will get the source code for that file in text format. However, if you named it header.inc.php it will still follow an intelligent naming convention, but will still get interpreted if someone tries to access it directly. This will most likely result in an error or will just display a blank page depending on what your header file does. Either way it doesn't open your source code up to anonymous users. This is why Martin is suggesting you to store your include files outside of the root web directory so people can't directly access your source code. So either do what I've suggested or do what Martin suggested, but it is definitely worth the effort to do one of the two. --Toby - Original Message - From: Jordan Elver [EMAIL PROTECTED] To: Ben Cairns [EMAIL PROTECTED] Cc: PHP General Mailing List [EMAIL PROTECTED] Sent: Monday, April 23, 2001 11:28 AM Subject: Re: [PHP] Site Structure Hi, Thanks for the reply. I can do that but then the images will not be in the correct location? Jordan On Monday 23 April 2001 15:58, you wrote: give the include() function a complete path: include '/apache/htdocs/include/yourfile.inc.php'; -- Ben Cairns - Head Of Technical Operations intasept.COM Tel: 01332 365333 Fax: 01332 346010 E-Mail: [EMAIL PROTECTED] Web: http://www.intasept.com MAKING sense of the INFORMATION TECHNOLOGY age @ WORK.. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Site Structure
Hi, Also, it's not a good idea to use the .inc extension unless you've associated it with PHP. The reason is if I type the URL directly to /includes/header.inc I will get the source code for that file in text format. you don't have to keep your .inc files in the web server document root folder at all... Rgds, Tfr --== [EMAIL PROTECTED] == MySQL development team == Tallinn / Estonia ==-- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Site Structure
At 01:12 PM 4/23/2001, Toby Miller wrote: personally i deny all access to my .inc files. with this Apache config... works really good :-) in httpd.conf # The following prevents .inc file from being read by web clients Files ~ .inc Order allow,deny Deny from all /Files ~kurth Jordan, Not true. If you make your PHP includes look like this: include($DOCUMENT_ROOT/includes/header.inc); Then you can make your image calls with an absolute URL like this: img src=/images/image.gif width=10 height=10 border=0 Also, it's not a good idea to use the .inc extension unless you've associated it with PHP. The reason is if I type the URL directly to /includes/header.inc I will get the source code for that file in text format. However, if you named it header.inc.php it will still follow an intelligent naming convention, but will still get interpreted if someone tries to access it directly. This will most likely result in an error or will just display a blank page depending on what your header file does. Either way it doesn't open your source code up to anonymous users. This is why Martin is suggesting you to store your include files outside of the root web directory so people can't directly access your source code. So either do what I've suggested or do what Martin suggested, but it is definitely worth the effort to do one of the two. --Toby - Original Message - From: Jordan Elver [EMAIL PROTECTED] To: Ben Cairns [EMAIL PROTECTED] Cc: PHP General Mailing List [EMAIL PROTECTED] Sent: Monday, April 23, 2001 11:28 AM Subject: Re: [PHP] Site Structure Hi, Thanks for the reply. I can do that but then the images will not be in the correct location? Jordan On Monday 23 April 2001 15:58, you wrote: give the include() function a complete path: include '/apache/htdocs/include/yourfile.inc.php'; -- Ben Cairns - Head Of Technical Operations intasept.COM Tel: 01332 365333 Fax: 01332 346010 E-Mail: [EMAIL PROTECTED] Web: http://www.intasept.com MAKING sense of the INFORMATION TECHNOLOGY age @ WORK.. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Site Structure
This is true and I do this in .htaccess or in the main Apache config file when possible. However, for those who do not have control over the main config file, you are at the mercy of the system operator. They could turn off looking at your .htaccess files and not have the Files directive to hide the .inc files and then your code you thought private is not private at all. The moral of this is to always assume the worst and put those .inc files anywhere, but the web tree. However, do this only if you care about protecting the contents. Caveat Emptor -Original Message- From: Kurth Bemis [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 1:24 PM To: Toby Miller; Jordan Elver Cc: PHP General Mailing List Subject: Re: [PHP] Site Structure At 01:12 PM 4/23/2001, Toby Miller wrote: personally i deny all access to my .inc files. with this Apache config... works really good :-) in httpd.conf # The following prevents .inc file from being read by web clients Files ~ .inc Order allow,deny Deny from all /Files -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Site Structure
While it is true that you don't have to put your files in the web directory at all and it is a more secure option there is still one very large inconvenience that prevents me from going with that option. You lose the usefulness of just including $DOCUMENT_ROOT/yourfolder/yourfilename. This is the main reason that I do put my files in the root web directory. So how do you tell all of your files where your included content is? Do you hard code the path in every page? If so, do you also have development, stage, and live environments that mimic the exact same directory structures? If not, do you always change the include strings by hand every time you move from one environment to another? Do you run into these problems? What kind of solutions/workarounds have you implemented? I have always used this style of including documents because it enables me to do my mockup ideas on my Windows machine with PWS. Then I can move onto my Linux test box and try the site in my home account. Then I can push the exact same code to the dev server which uses www as the root web directory. Then I can push the exact same code to the staging server for clients to see which has wwwroot as the root web directory and the live environment mimics the stage environment so that move makes little to no difference. Now if someone else was working on the same project and checked the files out of CVS they would have to tweak their copy to work in their special environment instead of just running and developing the files. This just seems like a whole lot of extra work to me. Correct me if I'm wrong, but the only way anyone can see the source code of a php file if the extension is associated with the PHP interpreter is if you provide a phps file that they can see or if someone uninstalls the PHP interpreter (which bypasses the situation because the first condition is no longer being met). I'm really curious to see how other developers handle these kind of development situations. - Original Message - From: indrek siitan [EMAIL PROTECTED] To: Toby Miller [EMAIL PROTECTED]; Jordan Elver [EMAIL PROTECTED] Cc: PHP General Mailing List [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:22 PM Subject: RE: [PHP] Site Structure Hi, Also, it's not a good idea to use the .inc extension unless you've associated it with PHP. The reason is if I type the URL directly to /includes/header.inc I will get the source code for that file in text format. you don't have to keep your .inc files in the web server document root folder at all... Rgds, Tfr --== [EMAIL PROTECTED] == MySQL development team == Tallinn / Estonia ==-- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Site Structure
Hmm... Is there any way to set something like include_path on the fly, so you just define all your possible direcories at once in what is essential a 'site environment' variable, and then you can include/require your files without putting any path info in? regards, jaxon -Original Message- From: Toby Miller [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 3:44 PM To: indrek siitan Cc: PHP General Mailing List Subject: Re: [PHP] Site Structure While it is true that you don't have to put your files in the web directory at all and it is a more secure option there is still one very large inconvenience that prevents me from going with that option. You lose the usefulness of just including $DOCUMENT_ROOT/yourfolder/yourfilename. This is the main reason that I do put my files in the root web directory. So how do you tell all of your files where your included content is? Do you hard code the path in every page? If so, do you also have development, stage, and live environments that mimic the exact same directory structures? If not, do you always change the include strings by hand every time you move from one environment to another? Do you run into these problems? What kind of solutions/workarounds have you implemented? I have always used this style of including documents because it enables me to do my mockup ideas on my Windows machine with PWS. Then I can move onto my Linux test box and try the site in my home account. Then I can push the exact same code to the dev server which uses www as the root web directory. Then I can push the exact same code to the staging server for clients to see which has wwwroot as the root web directory and the live environment mimics the stage environment so that move makes little to no difference. Now if someone else was working on the same project and checked the files out of CVS they would have to tweak their copy to work in their special environment instead of just running and developing the files. This just seems like a whole lot of extra work to me. Correct me if I'm wrong, but the only way anyone can see the source code of a php file if the extension is associated with the PHP interpreter is if you provide a phps file that they can see or if someone uninstalls the PHP interpreter (which bypasses the situation because the first condition is no longer being met). I'm really curious to see how other developers handle these kind of development situations. - Original Message - From: indrek siitan [EMAIL PROTECTED] To: Toby Miller [EMAIL PROTECTED]; Jordan Elver [EMAIL PROTECTED] Cc: PHP General Mailing List [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:22 PM Subject: RE: [PHP] Site Structure Hi, Also, it's not a good idea to use the .inc extension unless you've associated it with PHP. The reason is if I type the URL directly to /includes/header.inc I will get the source code for that file in text format. you don't have to keep your .inc files in the web server document root folder at all... Rgds, Tfr --== [EMAIL PROTECTED] == MySQL development team == Tallinn / Estonia ==-- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Site Structure
You could always: include( $DOCUMENT_ROOT/../includes/whatever.inc ); or better yet, define include_path and then just: include( whatever.inc ); This give you the best of both worlds. You never need to worry about different dir. structures on dev, staging, and production servers, AND you can keep your includes out of a web server accessible directory. Martin Gottlieb -Original Message- From: Toby Miller [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 3:44 PM To: indrek siitan Cc: PHP General Mailing List Subject: Re: [PHP] Site Structure While it is true that you don't have to put your files in the web directory at all and it is a more secure option there is still one very large inconvenience that prevents me from going with that option. You lose the usefulness of just including $DOCUMENT_ROOT/yourfolder/yourfilename. This is the main reason that I do put my files in the root web directory. So how do you tell all of your files where your included content is? Do you hard code the path in every page? If so, do you also have development, stage, and live environments that mimic the exact same directory structures? If not, do you always change the include strings by hand every time you move from one environment to another? Do you run into these problems? What kind of solutions/workarounds have you implemented? I have always used this style of including documents because it enables me to do my mockup ideas on my Windows machine with PWS. Then I can move onto my Linux test box and try the site in my home account. Then I can push the exact same code to the dev server which uses www as the root web directory. Then I can push the exact same code to the staging server for clients to see which has wwwroot as the root web directory and the live environment mimics the stage environment so that move makes little to no difference. Now if someone else was working on the same project and checked the files out of CVS they would have to tweak their copy to work in their special environment instead of just running and developing the files. This just seems like a whole lot of extra work to me. Correct me if I'm wrong, but the only way anyone can see the source code of a php file if the extension is associated with the PHP interpreter is if you provide a phps file that they can see or if someone uninstalls the PHP interpreter (which bypasses the situation because the first condition is no longer being met). I'm really curious to see how other developers handle these kind of development situations. - Original Message - From: indrek siitan [EMAIL PROTECTED] To: Toby Miller [EMAIL PROTECTED]; Jordan Elver [EMAIL PROTECTED] Cc: PHP General Mailing List [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:22 PM Subject: RE: [PHP] Site Structure Hi, Also, it's not a good idea to use the .inc extension unless you've associated it with PHP. The reason is if I type the URL directly to /includes/header.inc I will get the source code for that file in text format. you don't have to keep your .inc files in the web server document root folder at all... Rgds, Tfr --== [EMAIL PROTECTED] == MySQL development team == Tallinn / Estonia ==-- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Site Structure
On Monday 23 April 2001 22:47, Jaxon wrote: Hmm... Is there any way to set something like include_path on the fly, so you just define all your possible direcories at once in what is essential a 'site environment' variable, and then you can include/require your files without putting any path info in? regards, jaxon Sure you can, set the include_path in your php.ini file. -- Meir Kriheli There's someone in my head, but it's not me - Pink Floyd -Original Message- From: Toby Miller [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 3:44 PM To: indrek siitan Cc: PHP General Mailing List Subject: Re: [PHP] Site Structure While it is true that you don't have to put your files in the web directory at all and it is a more secure option there is still one very large inconvenience that prevents me from going with that option. You lose the usefulness of just including $DOCUMENT_ROOT/yourfolder/yourfilename. This is the main reason that I do put my files in the root web directory. So how do you tell all of your files where your included content is? Do you hard code the path in every page? If so, do you also have development, stage, and live environments that mimic the exact same directory structures? If not, do you always change the include strings by hand every time you move from one environment to another? Do you run into these problems? What kind of solutions/workarounds have you implemented? I have always used this style of including documents because it enables me to do my mockup ideas on my Windows machine with PWS. Then I can move onto my Linux test box and try the site in my home account. Then I can push the exact same code to the dev server which uses www as the root web directory. Then I can push the exact same code to the staging server for clients to see which has wwwroot as the root web directory and the live environment mimics the stage environment so that move makes little to no difference. Now if someone else was working on the same project and checked the files out of CVS they would have to tweak their copy to work in their special environment instead of just running and developing the files. This just seems like a whole lot of extra work to me. Correct me if I'm wrong, but the only way anyone can see the source code of a php file if the extension is associated with the PHP interpreter is if you provide a phps file that they can see or if someone uninstalls the PHP interpreter (which bypasses the situation because the first condition is no longer being met). I'm really curious to see how other developers handle these kind of development situations. - Original Message - From: indrek siitan [EMAIL PROTECTED] To: Toby Miller [EMAIL PROTECTED]; Jordan Elver [EMAIL PROTECTED] Cc: PHP General Mailing List [EMAIL PROTECTED] Sent: Monday, April 23, 2001 1:22 PM Subject: RE: [PHP] Site Structure Hi, Also, it's not a good idea to use the .inc extension unless you've associated it with PHP. The reason is if I type the URL directly to /includes/header.inc I will get the source code for that file in text format. you don't have to keep your .inc files in the web server document root folder at all... Rgds, Tfr --== [EMAIL PROTECTED] == MySQL development team == Tallinn / Estonia ==-- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Site Structure
Toby Miller [EMAIL PROTECTED] wrote: While it is true that you don't have to put your files in the web directory at all and it is a more secure option there is still one very large inconvenience that prevents me from going with that option. You lose the usefulness of just including $DOCUMENT_ROOT/yourfolder/yourfilename. This is the main reason that I do put my files in the root web directory. So how do you tell all of your files where your included content is? Do you hard code the path in every page? If so, do you also have development, stage, and live environments that mimic the exact same directory structures? If not, do you always change the include strings by hand every time you move from one environment to another? Do you run into these problems? What kind of solutions/workarounds have you implemented? Here's a solution I've used with a lot of success. I concocted it myself a year or so ago after trying a number of other alternatives. // Set INC_PATH. ereg( '(.*)htdocs.*', $SCRIPT_FILENAME, $regs ); define( 'INC_PATH', $regs[1] . 'inc/' ); // Include files. include( INC_PATH . inc_common.php ); ... include( INC_PATH . inc_db.php ); Nearly all of the sites I design are controlled from a single PHP file using some Apache AliasMatch magic so I usually only have to set the INC_PATH constant in one file and include the main include files in the same place. So the include directory (inc) is parallel to my web docs directory. The parent of both is a directory called 'production', which has directories parallel to it called 'development' and 'staging' which allows me to run 3 versions of the site, each on 3 separate ports and copy code from one version to the other and run them with no modifications. -- Steve Werby President, Befriend Internet Services LLC http://www.befriend.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
