Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #9805 > unrolled thread

Using a single php entry file for a whole site.

Back to article view | Back to comp.lang.php

Contents

  Using a single php entry file for a whole site. The Natural Philosopher <tnp@invalid.invalid> - 2013-06-20 18:22 +0100
    Re: Using a single php entry file for a whole site. Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-20 13:48 -0400
    Re: Using a single php entry file for a whole site. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-06-20 10:48 -0700
      Re: Using a single php entry file for a whole site. The Natural Philosopher <tnp@invalid.invalid> - 2013-06-20 19:18 +0100
    Re: Using a single php entry file for a whole site. Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2013-06-20 18:23 +0000
      Re: Using a single php entry file for a whole site. The Natural Philosopher <tnp@invalid.invalid> - 2013-06-20 20:06 +0100
    Re: Using a single php entry file for a whole site. Marc van Lieshout <invalid@example.com> - 2013-06-20 21:29 +0200
      Re: Using a single php entry file for a whole site. Marc van Lieshout <invalid@example.com> - 2013-06-20 21:38 +0200
        Re: Using a single php entry file for a whole site. Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-20 16:13 -0400
          Re: Using a single php entry file for a whole site. Marc van Lieshout <invalid@example.com> - 2013-06-21 00:33 +0200
            Re: Using a single php entry file for a whole site. Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-21 00:50 +0200
              Re: Using a single php entry file for a whole site. The Natural Philosopher <tnp@invalid.invalid> - 2013-06-21 07:45 +0100
                Re: Using a single php entry file for a whole site. Tim Streater <timstreater@greenbee.net> - 2013-06-21 10:08 +0100
                  Re: Using a single php entry file for a whole site. The Natural Philosopher <tnp@invalid.invalid> - 2013-06-21 11:21 +0100
                    Re: Using a single php entry file for a whole site. Christoph Michael Becker <cmbecker69@arcor.de> - 2013-07-15 01:15 +0200
            Re: Using a single php entry file for a whole site. Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-20 19:35 -0400
      Re: Using a single php entry file for a whole site. Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-20 21:44 +0200
      Re: Using a single php entry file for a whole site. The Natural Philosopher <tnp@invalid.invalid> - 2013-06-20 22:38 +0100
        Re: Using a single php entry file for a whole site. Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-21 00:34 +0200
          Re: Using a single php entry file for a whole site. Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-20 19:37 -0400
        Re: Using a single php entry file for a whole site. Marc van Lieshout <invalid@example.com> - 2013-06-21 00:51 +0200
          Re: Using a single php entry file for a whole site. The Natural Philosopher <tnp@invalid.invalid> - 2013-06-21 07:54 +0100
    Re: Using a single php entry file for a whole site. "Peter H. Coffin" <hellsop@ninehells.com> - 2013-06-20 14:54 -0500

Page 1 of 2  [1] 2  Next page →

#9805 — Using a single php entry file for a whole site.

What I would like to do, is the following.

ALL request to a site are redirected by apache rules to one single file. 
Let's call it index.php.
Index.php notes the URL the user wants and looks it up in a database, 
and if it exists, includes()  the actual PHP file for that page.
If it doesn't exist, a standard 'sorry, you are looking for a page that 
doesn't exist' is returned, if possible with the correct error code in 
the headers?
The php files themselves apart from index.php do NOT live under the web 
root. They might in fact live in the database. But that's stage 2.

Is this possible, and if so what if any are the downsides?

It seems to me that a user or robot level scrape of the site would not 
show anything of its true internal structure. But still show all the 
paths through it.

What I want to do is have stuff like

http:/mysite.com/news/Dog-Bites-Man

redirect to say

/var/private/newspage.php?id=3041

where there exists a mysql table with a name value pair of

news/Dog-Bites-Man: /var/private/newspage.php?id=3041
or
menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster

and so on.

And possible a field for keywords to search the site with.

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [next] | [standalone]

#9807

On 6/20/2013 1:22 PM, The Natural Philosopher wrote:
>
> What I would like to do, is the following.
>
> ALL request to a site are redirected by apache rules to one single file.
> Let's call it index.php.
> Index.php notes the URL the user wants and looks it up in a database,
> and if it exists, includes()  the actual PHP file for that page.
> If it doesn't exist, a standard 'sorry, you are looking for a page that
> doesn't exist' is returned, if possible with the correct error code in
> the headers?
> The php files themselves apart from index.php do NOT live under the web
> root. They might in fact live in the database. But that's stage 2.
>
> Is this possible, and if so what if any are the downsides?
>

Sure, it's possible.  Many CMS's do it.  The advantage is you don't have 
to upload files.  Disadvantage is higher complexity of the code and more 
processing required for each page.  Additionally, maintenance and 
troubleshooting will be much harder, and unless you are *VERY CAREFUL* 
you can be adding security risks.  CMS's go to great lengths to avoid 
the security problems, but the troubleshooting and maintenance is still 
a problem.

> It seems to me that a user or robot level scrape of the site would not
> show anything of its true internal structure. But still show all the
> paths through it.
>

Internal structure is immaterial to the external world.  All they do is 
request a URI and get a response.

> What I want to do is have stuff like
>
> http:/mysite.com/news/Dog-Bites-Man
>
> redirect to say
>
> /var/private/newspage.php?id=3041
>
> where there exists a mysql table with a name value pair of
>
> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
> or
> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>
> and so on.
>
> And possible a field for keywords to search the site with.
>

The question begs - why?  Unless you're trying to build your own CMS 
(but there are a lot of good free ones out there), I see no good reason 
for it.

But then I also consider the source of the question...

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#9808

On 6/20/13 10:22 AM, The Natural Philosopher wrote:
>
> What I would like to do, is the following.
>
> ALL request to a site are redirected by apache rules to one single file.
> Let's call it index.php.
> Index.php notes the URL the user wants and looks it up in a database,
> and if it exists, includes()  the actual PHP file for that page.
> If it doesn't exist, a standard 'sorry, you are looking for a page that
> doesn't exist' is returned, if possible with the correct error code in
> the headers?
> The php files themselves apart from index.php do NOT live under the web
> root. They might in fact live in the database. But that's stage 2.
>
> Is this possible, and if so what if any are the downsides?
This is almost what Symfony2 does. Though its far more sophisticated 
than that as far as how it decides what PHP files to load and to use to 
render the response.  It is designed around MVC, rather than "Here's a 
script to render the page."

It has a useful routing mechanism to match URLs and forward to 
appropriate controllers, which then can decide actions to perform and 
views to render.

>
> It seems to me that a user or robot level scrape of the site would not
> show anything of its true internal structure. But still show all the
> paths through it.
>
> What I want to do is have stuff like
>
> http:/mysite.com/news/Dog-Bites-Man
>
> redirect to say
>
> /var/private/newspage.php?id=3041
>
> where there exists a mysql table with a name value pair of
>
> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
> or
> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>
> and so on.
What I've seen is that the web-server (nginx in my case, but Apache 
should work too) forwards (not redirects) the request to exactly one 
script "/path/to/my/site/web/index.php", which then does all the logic 
for deciding the routes. Once that is determined, all the logic to 
render that specific page is executed, and then the view is presented.
>
> And possible a field for keywords to search the site with.
Very doable.

Hope this helps,
Daniel.

[toc] | [prev] | [next] | [standalone]

#9810

On 20/06/13 18:48, Daniel Pitts wrote:
> On 6/20/13 10:22 AM, The Natural Philosopher wrote:
>>
>> What I would like to do, is the following.
>>
>> ALL request to a site are redirected by apache rules to one single file.
>> Let's call it index.php.
>> Index.php notes the URL the user wants and looks it up in a database,
>> and if it exists, includes()  the actual PHP file for that page.
>> If it doesn't exist, a standard 'sorry, you are looking for a page that
>> doesn't exist' is returned, if possible with the correct error code in
>> the headers?
>> The php files themselves apart from index.php do NOT live under the web
>> root. They might in fact live in the database. But that's stage 2.
>>
>> Is this possible, and if so what if any are the downsides?
> This is almost what Symfony2 does. Though its far more sophisticated 
> than that as far as how it decides what PHP files to load and to use 
> to render the response.  It is designed around MVC, rather than 
> "Here's a script to render the page."
>
> It has a useful routing mechanism to match URLs and forward to 
> appropriate controllers, which then can decide actions to perform and 
> views to render.
>
>>
>> It seems to me that a user or robot level scrape of the site would not
>> show anything of its true internal structure. But still show all the
>> paths through it.
>>
>> What I want to do is have stuff like
>>
>> http:/mysite.com/news/Dog-Bites-Man
>>
>> redirect to say
>>
>> /var/private/newspage.php?id=3041
>>
>> where there exists a mysql table with a name value pair of
>>
>> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
>> or
>> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>>
>> and so on.
> What I've seen is that the web-server (nginx in my case, but Apache 
> should work too) forwards (not redirects) the request to exactly one 
> script "/path/to/my/site/web/index.php", which then does all the logic 
> for deciding the routes. Once that is determined, all the logic to 
> render that specific page is executed, and then the view is presented.
>>
>> And possible a field for keywords to search the site with.
> Very doable.
>
> Hope this helps,
> Daniel.
>

It did a lot actually. in the time between posting and reading your 
reply I have stumbled through the rewrite rules  on apache and proved 
the basic stuff will in fact work. (after redirecting more than I 
bargained for)!
In short everything except two directories and various image types now 
gets redirected to /index.php.

What I had to in debian was  (as root)

# a2enmod rewrite

then restart the server

and then edit the apache2 config file for the domain like this

RewriteEngine on
RewriteRule ^(admin|downloads)($|/) - [L] # allows normal access to the 
admin and downloads dirs
RewriteRule !^(index.php)|.(js|ico|gif|jpg|png|css|mp3|xml|swf)$ 
/index.php [L]  # shoves everything else to index.php except index.php 
itself and anything ending with the listed extensions.

NOW I have to build the intelligence..back in PHP land.

I've got two $_SERVER variables that seem to hold the info I want.

One is ["REQUEST_URI"] and the other is ["REDIRECT_URL"]

any reason to prefer one over the other?

>
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#9812

On Thu, 20 Jun 2013 19:22:18 The Natural Philosopher wrote:
> ALL request to a site are redirected by apache rules to one single file.
> Let's call it index.php. Index.php notes the URL the user wants and looks
> it up in a database, and if it exists, includes()  the actual PHP file
> for that page.
[...] 
> Is this possible, and if so what if any are the downsides?

Definitely, yes. I do it quite similar with the only difference that I
do not include() the desired page, but rather each page is a class derived
of an abstract parent class. This opens some nice possibilities to define
page title, access rights and things like that and it makes it possible
to construct an object hierarchy with similar pages grouped together.

Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Worauf man sich verlassen kann - Stefan: riechen, welch eifriges Erwarten!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#9815

On 20/06/13 19:23, Stefan Froehlich wrote:
> On Thu, 20 Jun 2013 19:22:18 The Natural Philosopher wrote:
>> ALL request to a site are redirected by apache rules to one single file.
>> Let's call it index.php. Index.php notes the URL the user wants and looks
>> it up in a database, and if it exists, includes()  the actual PHP file
>> for that page.
> [...]
>> Is this possible, and if so what if any are the downsides?
> Definitely, yes. I do it quite similar with the only difference that I
> do not include() the desired page, but rather each page is a class derived
> of an abstract parent class. This opens some nice possibilities to define
> page title, access rights and things like that and it makes it possible
> to construct an object hierarchy with similar pages grouped together.
>
> Stefan
>

Nice approach. I don't like objective code, but I do write code in an 
object oriented way.

Typically by having include files that contain essentially private data 
accessible by predetermined functions.

It may turn out that 'going OO' is a good idea, but I'll wait till the 
ideas develop.
In many ways I'd rather do that level of abstraction in the database as 
well.

Still: food for thought.

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#9816

On 20-06-13 19:22, The Natural Philosopher wrote:
>
> What I would like to do, is the following.
>
> ALL request to a site are redirected by apache rules to one single file.
> Let's call it index.php.
> Index.php notes the URL the user wants and looks it up in a database,
> and if it exists, includes()  the actual PHP file for that page.
> If it doesn't exist, a standard 'sorry, you are looking for a page that
> doesn't exist' is returned, if possible with the correct error code in
> the headers?
> The php files themselves apart from index.php do NOT live under the web
> root. They might in fact live in the database. But that's stage 2.
>
> Is this possible, and if so what if any are the downsides?
>
> It seems to me that a user or robot level scrape of the site would not
> show anything of its true internal structure. But still show all the
> paths through it.
>
> What I want to do is have stuff like
>
> http:/mysite.com/news/Dog-Bites-Man
>
> redirect to say
>
> /var/private/newspage.php?id=3041
>
> where there exists a mysql table with a name value pair of
>
> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
> or
> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>
> and so on.
>
> And possible a field for keywords to search the site with.
>

That looks indeed like a small framework. Some remarks:

1. You don't need apache rewriting you can use $_SERVER['PATH_INFO'] and 
use url's like:

http:/mysite.com/index.php/news/Dog-Bites-Man

or a page controller:

http:/mysite.com/index.php?site=%2Fnews%2FDog-Bites-Man


2. For the sake of security, put the part that accesses the DB outside 
of index.php. It contains an uid and a password.


The scheme will be like this:

in index.php:
include "/path/ouside/webroot/dispatcher.php"

in dispatcher.php:
$conn = new PDO(....);
$stmnt = $conn->prepare(
    'SELECT target from dispatch WHERE source = :src');
$stmnt->execute(':src' => $_SERVER['PATH_INFO']);
$row = $stmnt->fetch(PDO::FETCH_ASSOC);

if ($row === false)
    // dispatch to 404
    ;
else
    include('/path/outside/webroot/' . $row['target']);


That's all.

[toc] | [prev] | [next] | [standalone]

#9817

On 20-06-13 21:29, Marc van Lieshout wrote:
> On 20-06-13 19:22, The Natural Philosopher wrote:
>>
>> What I would like to do, is the following.
>>
>> ALL request to a site are redirected by apache rules to one single file.
>> Let's call it index.php.
>> Index.php notes the URL the user wants and looks it up in a database,
>> and if it exists, includes()  the actual PHP file for that page.
>> If it doesn't exist, a standard 'sorry, you are looking for a page that
>> doesn't exist' is returned, if possible with the correct error code in
>> the headers?
>> The php files themselves apart from index.php do NOT live under the web
>> root. They might in fact live in the database. But that's stage 2.
>>
>> Is this possible, and if so what if any are the downsides?
>>
>> It seems to me that a user or robot level scrape of the site would not
>> show anything of its true internal structure. But still show all the
>> paths through it.
>>
>> What I want to do is have stuff like
>>
>> http:/mysite.com/news/Dog-Bites-Man
>>
>> redirect to say
>>
>> /var/private/newspage.php?id=3041
>>
>> where there exists a mysql table with a name value pair of
>>
>> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
>> or
>> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>>
>> and so on.
>>
>> And possible a field for keywords to search the site with.
>>
>
> That looks indeed like a small framework. Some remarks:
>
> 1. You don't need apache rewriting you can use $_SERVER['PATH_INFO'] and
> use url's like:
>
> http:/mysite.com/index.php/news/Dog-Bites-Man
>
> or a page controller:
>
> http:/mysite.com/index.php?site=%2Fnews%2FDog-Bites-Man
>
>
> 2. For the sake of security, put the part that accesses the DB outside
> of index.php. It contains an uid and a password.
>
>
> The scheme will be like this:
>
> in index.php:
> include "/path/ouside/webroot/dispatcher.php"
>
> in dispatcher.php:
> $conn = new PDO(....);
> $stmnt = $conn->prepare(
>     'SELECT target from dispatch WHERE source = :src');
> $stmnt->execute(':src' => $_SERVER['PATH_INFO']);
> $row = $stmnt->fetch(PDO::FETCH_ASSOC);
>
> if ($row === false)
>     // dispatch to 404
>     ;
> else
>     include('/path/outside/webroot/' . $row['target']);
>
>
> That's all.
>

A simple addition:

You can get rid of the boring <html><head></head> ... stuff by changing 
the above setup like:

ob_start();
if ($row === false)
    // dispatch to 404
    ;
else
    include('/path/outside/webroot/' . $row['target']);
$contents = ob_get_clean();
include "mytemplate.php"


Where mytemplate can put an <?php echo $contents; ?> in the right place.
All major frameworks use this trick.

[toc] | [prev] | [next] | [standalone]

#9821

On 6/20/2013 3:38 PM, Marc van Lieshout wrote:
> On 20-06-13 21:29, Marc van Lieshout wrote:
>> On 20-06-13 19:22, The Natural Philosopher wrote:
>>>
>>> What I would like to do, is the following.
>>>
>>> ALL request to a site are redirected by apache rules to one single file.
>>> Let's call it index.php.
>>> Index.php notes the URL the user wants and looks it up in a database,
>>> and if it exists, includes()  the actual PHP file for that page.
>>> If it doesn't exist, a standard 'sorry, you are looking for a page that
>>> doesn't exist' is returned, if possible with the correct error code in
>>> the headers?
>>> The php files themselves apart from index.php do NOT live under the web
>>> root. They might in fact live in the database. But that's stage 2.
>>>
>>> Is this possible, and if so what if any are the downsides?
>>>
>>> It seems to me that a user or robot level scrape of the site would not
>>> show anything of its true internal structure. But still show all the
>>> paths through it.
>>>
>>> What I want to do is have stuff like
>>>
>>> http:/mysite.com/news/Dog-Bites-Man
>>>
>>> redirect to say
>>>
>>> /var/private/newspage.php?id=3041
>>>
>>> where there exists a mysql table with a name value pair of
>>>
>>> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
>>> or
>>> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>>>
>>> and so on.
>>>
>>> And possible a field for keywords to search the site with.
>>>
>>
>> That looks indeed like a small framework. Some remarks:
>>
>> 1. You don't need apache rewriting you can use $_SERVER['PATH_INFO'] and
>> use url's like:
>>
>> http:/mysite.com/index.php/news/Dog-Bites-Man
>>
>> or a page controller:
>>
>> http:/mysite.com/index.php?site=%2Fnews%2FDog-Bites-Man
>>
>>
>> 2. For the sake of security, put the part that accesses the DB outside
>> of index.php. It contains an uid and a password.
>>
>>
>> The scheme will be like this:
>>
>> in index.php:
>> include "/path/ouside/webroot/dispatcher.php"
>>
>> in dispatcher.php:
>> $conn = new PDO(....);
>> $stmnt = $conn->prepare(
>>     'SELECT target from dispatch WHERE source = :src');
>> $stmnt->execute(':src' => $_SERVER['PATH_INFO']);
>> $row = $stmnt->fetch(PDO::FETCH_ASSOC);
>>
>> if ($row === false)
>>     // dispatch to 404
>>     ;
>> else
>>     include('/path/outside/webroot/' . $row['target']);
>>
>>
>> That's all.
>>
>
> A simple addition:
>
> You can get rid of the boring <html><head></head> ... stuff by changing
> the above setup like:
>
> ob_start();
> if ($row === false)
>     // dispatch to 404
>     ;
> else
>     include('/path/outside/webroot/' . $row['target']);
> $contents = ob_get_clean();
> include "mytemplate.php"
>
>
> Where mytemplate can put an <?php echo $contents; ?> in the right place.
> All major frameworks use this trick.
>

What is the need for the ob_start()?  Unless you have a very good reason 
for needing it, using it is poor programming.

For instance, if you're just using it to bypass the "Headers already 
sent" message, you have a problem in your design.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#9827

On 20-06-13 22:13, Jerry Stuckle wrote:
> On 6/20/2013 3:38 PM, Marc van Lieshout wrote:
>> On 20-06-13 21:29, Marc van Lieshout wrote:
>>> On 20-06-13 19:22, The Natural Philosopher wrote:
>>>>
>>>> What I would like to do, is the following.
>>>>
>>>> ALL request to a site are redirected by apache rules to one single
>>>> file.
>>>> Let's call it index.php.
>>>> Index.php notes the URL the user wants and looks it up in a database,
>>>> and if it exists, includes()  the actual PHP file for that page.
>>>> If it doesn't exist, a standard 'sorry, you are looking for a page that
>>>> doesn't exist' is returned, if possible with the correct error code in
>>>> the headers?
>>>> The php files themselves apart from index.php do NOT live under the web
>>>> root. They might in fact live in the database. But that's stage 2.
>>>>
>>>> Is this possible, and if so what if any are the downsides?
>>>>
>>>> It seems to me that a user or robot level scrape of the site would not
>>>> show anything of its true internal structure. But still show all the
>>>> paths through it.
>>>>
>>>> What I want to do is have stuff like
>>>>
>>>> http:/mysite.com/news/Dog-Bites-Man
>>>>
>>>> redirect to say
>>>>
>>>> /var/private/newspage.php?id=3041
>>>>
>>>> where there exists a mysql table with a name value pair of
>>>>
>>>> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
>>>> or
>>>> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>>>>
>>>> and so on.
>>>>
>>>> And possible a field for keywords to search the site with.
>>>>
>>>
>>> That looks indeed like a small framework. Some remarks:
>>>
>>> 1. You don't need apache rewriting you can use $_SERVER['PATH_INFO'] and
>>> use url's like:
>>>
>>> http:/mysite.com/index.php/news/Dog-Bites-Man
>>>
>>> or a page controller:
>>>
>>> http:/mysite.com/index.php?site=%2Fnews%2FDog-Bites-Man
>>>
>>>
>>> 2. For the sake of security, put the part that accesses the DB outside
>>> of index.php. It contains an uid and a password.
>>>
>>>
>>> The scheme will be like this:
>>>
>>> in index.php:
>>> include "/path/ouside/webroot/dispatcher.php"
>>>
>>> in dispatcher.php:
>>> $conn = new PDO(....);
>>> $stmnt = $conn->prepare(
>>>     'SELECT target from dispatch WHERE source = :src');
>>> $stmnt->execute(':src' => $_SERVER['PATH_INFO']);
>>> $row = $stmnt->fetch(PDO::FETCH_ASSOC);
>>>
>>> if ($row === false)
>>>     // dispatch to 404
>>>     ;
>>> else
>>>     include('/path/outside/webroot/' . $row['target']);
>>>
>>>
>>> That's all.
>>>
>>
>> A simple addition:
>>
>> You can get rid of the boring <html><head></head> ... stuff by changing
>> the above setup like:
>>
>> ob_start();
>> if ($row === false)
>>     // dispatch to 404
>>     ;
>> else
>>     include('/path/outside/webroot/' . $row['target']);
>> $contents = ob_get_clean();
>> include "mytemplate.php"
>>
>>
>> Where mytemplate can put an <?php echo $contents; ?> in the right place.
>> All major frameworks use this trick.
>>
>
> What is the need for the ob_start()?  Unless you have a very good reason
> for needing it, using it is poor programming.
>
> For instance, if you're just using it to bypass the "Headers already
> sent" message, you have a problem in your design.
>

Why is using ob_start() poor programming?
The pair ob_start/ob_get_clean captures the contents of the page in the 
$contents variable. Your template would look something like:

<html>
   <head>
     ... stuff that is the same for every page ...
   </head>
   <body>
     ... layout stuff ...
     <div class="contents">
<?php echo $contents; ?>
     </div>
     ...
   </body>
</html>

If you do it this way, you don't have to repeat this stuff in every 
actual page.

[toc] | [prev] | [next] | [standalone]

#9829

Am 21.06.2013 00:33, schrieb Marc van Lieshout:
> Why is using ob_start() poor programming?
> The pair ob_start/ob_get_clean captures the contents of the page in the
> $contents variable.

This discussion may well end in a flame war.  What is faster: echoing
with output buffering vs. concatening strings with the dot operator?

ISTM all depends on the implementation.  AFAIK string concatenation is a
very cheap operation in Python, for instance, as the string is not
actually built (merely a "pseudo" string containing links to the
concatenated strings).  In other languages such as PHP, the characters
have to be copied over to a new string, AFAIK.  This probably makes
output buffering faster, but the performance difference may be
neglectable for typical cases.  And one never knows, if the
implementation might change in the future.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9840

On 20/06/13 23:50, Christoph Michael Becker wrote:
> Am 21.06.2013 00:33, schrieb Marc van Lieshout:
>> Why is using ob_start() poor programming?
>> The pair ob_start/ob_get_clean captures the contents of the page in the
>> $contents variable.
> This discussion may well end in a flame war.  What is faster: echoing
> with output buffering vs. concatening strings with the dot operator?
>
> ISTM all depends on the implementation.  AFAIK string concatenation is a
> very cheap operation in Python, for instance, as the string is not
> actually built (merely a "pseudo" string containing links to the
> concatenated strings).  In other languages such as PHP, the characters
> have to be copied over to a new string, AFAIK.  This probably makes
> output buffering faster, but the performance difference may be
> neglectable for typical cases.  And one never knows, if the
> implementation might change in the future.
>
And the killer point, it is in terms of the overall site, the least of 
ones worries.

By far and away the biggest performance killer is accessing and 
streaming large objects. Generally graphics and videos.

or downloading massive JavaScript includes.

I've got one site which auto refreshes a page, I expected it to be 
massively hungry as its pretty popular, but somehow if the images 
haven't changed or the page hasn't changed it manages  to only send the 
bits that have changed.

That has implications for sites that have a common 'frame' around them. 
do you explicitly use an Iframe for the bit that moves (or a frame) or 
rely on browser caching to not send the bits they have already?


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#9843

In article <kq0sqh$vlb$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 20/06/13 23:50, Christoph Michael Becker wrote:
> > Am 21.06.2013 00:33, schrieb Marc van Lieshout:
> >> Why is using ob_start() poor programming?
> >> The pair ob_start/ob_get_clean captures the contents of the page in the
> >> $contents variable.
> > This discussion may well end in a flame war.  What is faster: echoing
> > with output buffering vs. concatening strings with the dot operator?
> >
> > ISTM all depends on the implementation.  AFAIK string concatenation is a
> > very cheap operation in Python, for instance, as the string is not
> > actually built (merely a "pseudo" string containing links to the
> > concatenated strings).  In other languages such as PHP, the characters
> > have to be copied over to a new string, AFAIK.  This probably makes
> > output buffering faster, but the performance difference may be
> > neglectable for typical cases.  And one never knows, if the
> > implementation might change in the future.
> >
> And the killer point, it is in terms of the overall site, the least of 
> ones worries.
> 
> By far and away the biggest performance killer is accessing and 
> streaming large objects. Generally graphics and videos.
> 
> or downloading massive JavaScript includes.
> 
> I've got one site which auto refreshes a page, I expected it to be 
> massively hungry as its pretty popular, but somehow if the images 
> haven't changed or the page hasn't changed it manages  to only send the 
> bits that have changed.

Isn't that just my browser caching stuff? If I've restarted Safari or 
rebooted (less likely) or just cleared the cache by hand it's gonna need 
to get it all next time I have a look.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#9846

On 21/06/13 10:08, Tim Streater wrote:
> In article <kq0sqh$vlb$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 20/06/13 23:50, Christoph Michael Becker wrote:
>> > Am 21.06.2013 00:33, schrieb Marc van Lieshout:
>> >> Why is using ob_start() poor programming?
>> >> The pair ob_start/ob_get_clean captures the contents of the page 
>> in the
>> >> $contents variable.
>> > This discussion may well end in a flame war.  What is faster: echoing
>> > with output buffering vs. concatening strings with the dot operator?
>> >
>> > ISTM all depends on the implementation.  AFAIK string concatenation 
>> is a
>> > very cheap operation in Python, for instance, as the string is not
>> > actually built (merely a "pseudo" string containing links to the
>> > concatenated strings).  In other languages such as PHP, the characters
>> > have to be copied over to a new string, AFAIK.  This probably makes
>> > output buffering faster, but the performance difference may be
>> > neglectable for typical cases.  And one never knows, if the
>> > implementation might change in the future.
>> >
>> And the killer point, it is in terms of the overall site, the least 
>> of ones worries.
>>
>> By far and away the biggest performance killer is accessing and 
>> streaming large objects. Generally graphics and videos.
>>
>> or downloading massive JavaScript includes.
>>
>> I've got one site which auto refreshes a page, I expected it to be 
>> massively hungry as its pretty popular, but somehow if the images 
>> haven't changed or the page hasn't changed it manages  to only send 
>> the bits that have changed.
>
> Isn't that just my browser caching stuff? If I've restarted Safari or 
> rebooted (less likely) or just cleared the cache by hand it's gonna 
> need to get it all next time I have a look.
>
the odd thing is Tim (and I know you know which site it is) that how 
does the browser know when its time to fetch the updated copy?

In the logs apache mixes 200 responses with 304 responses.

Vis:


      304 Not Modified

If the client has performed a conditional GET request and access is 
allowed, but the document has not been modified, the server SHOULD 
respond with this status code. The 304 response MUST NOT contain a 
message-body, and thus is always terminated by the first empty line 
after the header fields.

The response MUST include the following header fields:

       - Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and clients 
add their own Date to any response received without one (as already 
specified by [RFC 2068], section 14.19 
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19>), 
caches will operate correctly.

       - ETag and/or Content-Location, if the header would have been sent
         in a 200 response to the same request

       - Expires, Cache-Control, and/or Vary, if the field-value might
         differ from that sent in any previous response for the same
         variant

If the conditional GET used a strong cache validator (see section 
13.3.3), the response SHOULD NOT include other entity-headers. Otherwise 
(i.e., the conditional GET used a weak validator), the response MUST NOT 
include other entity-headers; this prevents inconsistencies between 
cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the 
cache MUST disregard the response and repeat the request without the 
conditional.

If a cache uses a received 304 response to update a cache entry, the 
cache MUST update the entry to reflect any new field values given in the 
response.

-------------

OK all fair and good, but how in fact does apache know that the data has 
not been modified since that particular client last accessed it?

Its working like a dream for sure -  99% of all the hits are 304's - but 
how can I make sure it always does?


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10111

The Natural Philosopher wrote:

> OK all fair and good, but how in fact does apache know that the data has
> not been modified since that particular client last accessed it?

The client may send an "If-Modified-Since" header, so Apache knows which
is the last version the client has cached.  However, there are several
other headers related to cache-control.

> Its working like a dream for sure -  99% of all the hits are 304's - but
> how can I make sure it always does?

You can't.  At least the content has to be delivered *once*.  Then it's
up to the client to cache it and to send appropriate request headers.

Anyway, a 304 does mainly save the transmission of the response's
*payload* only.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9834

On 6/20/2013 6:33 PM, Marc van Lieshout wrote:
> On 20-06-13 22:13, Jerry Stuckle wrote:
>> On 6/20/2013 3:38 PM, Marc van Lieshout wrote:
>>> On 20-06-13 21:29, Marc van Lieshout wrote:
>>>> On 20-06-13 19:22, The Natural Philosopher wrote:
>>>>>
>>>>> What I would like to do, is the following.
>>>>>
>>>>> ALL request to a site are redirected by apache rules to one single
>>>>> file.
>>>>> Let's call it index.php.
>>>>> Index.php notes the URL the user wants and looks it up in a database,
>>>>> and if it exists, includes()  the actual PHP file for that page.
>>>>> If it doesn't exist, a standard 'sorry, you are looking for a page
>>>>> that
>>>>> doesn't exist' is returned, if possible with the correct error code in
>>>>> the headers?
>>>>> The php files themselves apart from index.php do NOT live under the
>>>>> web
>>>>> root. They might in fact live in the database. But that's stage 2.
>>>>>
>>>>> Is this possible, and if so what if any are the downsides?
>>>>>
>>>>> It seems to me that a user or robot level scrape of the site would not
>>>>> show anything of its true internal structure. But still show all the
>>>>> paths through it.
>>>>>
>>>>> What I want to do is have stuff like
>>>>>
>>>>> http:/mysite.com/news/Dog-Bites-Man
>>>>>
>>>>> redirect to say
>>>>>
>>>>> /var/private/newspage.php?id=3041
>>>>>
>>>>> where there exists a mysql table with a name value pair of
>>>>>
>>>>> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
>>>>> or
>>>>> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>>>>>
>>>>> and so on.
>>>>>
>>>>> And possible a field for keywords to search the site with.
>>>>>
>>>>
>>>> That looks indeed like a small framework. Some remarks:
>>>>
>>>> 1. You don't need apache rewriting you can use $_SERVER['PATH_INFO']
>>>> and
>>>> use url's like:
>>>>
>>>> http:/mysite.com/index.php/news/Dog-Bites-Man
>>>>
>>>> or a page controller:
>>>>
>>>> http:/mysite.com/index.php?site=%2Fnews%2FDog-Bites-Man
>>>>
>>>>
>>>> 2. For the sake of security, put the part that accesses the DB outside
>>>> of index.php. It contains an uid and a password.
>>>>
>>>>
>>>> The scheme will be like this:
>>>>
>>>> in index.php:
>>>> include "/path/ouside/webroot/dispatcher.php"
>>>>
>>>> in dispatcher.php:
>>>> $conn = new PDO(....);
>>>> $stmnt = $conn->prepare(
>>>>     'SELECT target from dispatch WHERE source = :src');
>>>> $stmnt->execute(':src' => $_SERVER['PATH_INFO']);
>>>> $row = $stmnt->fetch(PDO::FETCH_ASSOC);
>>>>
>>>> if ($row === false)
>>>>     // dispatch to 404
>>>>     ;
>>>> else
>>>>     include('/path/outside/webroot/' . $row['target']);
>>>>
>>>>
>>>> That's all.
>>>>
>>>
>>> A simple addition:
>>>
>>> You can get rid of the boring <html><head></head> ... stuff by changing
>>> the above setup like:
>>>
>>> ob_start();
>>> if ($row === false)
>>>     // dispatch to 404
>>>     ;
>>> else
>>>     include('/path/outside/webroot/' . $row['target']);
>>> $contents = ob_get_clean();
>>> include "mytemplate.php"
>>>
>>>
>>> Where mytemplate can put an <?php echo $contents; ?> in the right place.
>>> All major frameworks use this trick.
>>>
>>
>> What is the need for the ob_start()?  Unless you have a very good reason
>> for needing it, using it is poor programming.
>>
>> For instance, if you're just using it to bypass the "Headers already
>> sent" message, you have a problem in your design.
>>
>
> Why is using ob_start() poor programming?
> The pair ob_start/ob_get_clean captures the contents of the page in the
> $contents variable. Your template would look something like:
>
> <html>
>    <head>
>      ... stuff that is the same for every page ...
>    </head>
>    <body>
>      ... layout stuff ...
>      <div class="contents">
> <?php echo $contents; ?>
>      </div>
>      ...
>    </body>
> </html>
>
> If you do it this way, you don't have to repeat this stuff in every
> actual page.
>

ob_start() doesn't magically create all of this.  And if it's the same 
for every page (it really should NOT be - things like <title> and 
various <meta> tags should match their respective pages), a simple 
include will suffice.

ob_start() will add extra unnecessary processing overhead and can hide 
errors.  It is not recommended as a general programming practice.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#9818

Am 20.06.2013 21:29, schrieb Marc van Lieshout:
> 1. You don't need apache rewriting you can use $_SERVER['PATH_INFO'] and
> use url's like:
> 
> http:/mysite.com/index.php/news/Dog-Bites-Man
> 
> or a page controller:
> 
> http:/mysite.com/index.php?site=%2Fnews%2FDog-Bites-Man

Or one can use mod_rewrite to rewrite

  http://example.com/news/dog-bites-man

to

  http://example.com/?page=news/dog-bites-man

This way one can simply use $_GET['page'] instead of dissecting
$_SERVER['REQUEST_URI'] and still have "clean URLs".

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9826

On 20/06/13 20:29, Marc van Lieshout wrote:
> On 20-06-13 19:22, The Natural Philosopher wrote:
>>
>> What I would like to do, is the following.
>>
>> ALL request to a site are redirected by apache rules to one single file.
>> Let's call it index.php.
>> Index.php notes the URL the user wants and looks it up in a database,
>> and if it exists, includes()  the actual PHP file for that page.
>> If it doesn't exist, a standard 'sorry, you are looking for a page that
>> doesn't exist' is returned, if possible with the correct error code in
>> the headers?
>> The php files themselves apart from index.php do NOT live under the web
>> root. They might in fact live in the database. But that's stage 2.
>>
>> Is this possible, and if so what if any are the downsides?
>>
>> It seems to me that a user or robot level scrape of the site would not
>> show anything of its true internal structure. But still show all the
>> paths through it.
>>
>> What I want to do is have stuff like
>>
>> http:/mysite.com/news/Dog-Bites-Man
>>
>> redirect to say
>>
>> /var/private/newspage.php?id=3041
>>
>> where there exists a mysql table with a name value pair of
>>
>> news/Dog-Bites-Man: /var/private/newspage.php?id=3041
>> or
>> menu/Contact-the-webmaster: /var/private/contact.php?target=webmaster
>>
>> and so on.
>>
>> And possible a field for keywords to search the site with.
>>
>
> That looks indeed like a small framework. Some remarks:
>
> 1. You don't need apache rewriting you can use $_SERVER['PATH_INFO'] 
> and use url's like:
>
> http:/mysite.com/index.php/news/Dog-Bites-Man
>
> or a page controller:
>
> http:/mysite.com/index.php?site=%2Fnews%2FDog-Bites-Man
>
I could, but this is something I am prototyping to mimic an existing 
server.  So I need absolute freedom to say 'link on new server behaves 
exactly like link on old server' (or even seamlessly redirects there)

>
> 2. For the sake of security, put the part that accesses the DB outside 
> of index.php. It contains an uid and a password.
>
Well ahead of you there mate :-)

include file in a directory that is password protected and may actually 
be moved out of the document root tree altogether. If PHP include can be 
something like

include('/etc/websites/locales/this_site.php' )

Performance, security and backwards compatibility are the three issues I 
want to understand, because I may need to..for reasons I won't go into 
here.

Because it would be built on a vps, everything is configurable to those ends



>
> The scheme will be like this:
>
> in index.php:
> include "/path/ouside/webroot/dispatcher.php"
>
Ah! you imply  that works. excellent!


> in dispatcher.php:
> $conn = new PDO(....);
> $stmnt = $conn->prepare(
>    'SELECT target from dispatch WHERE source = :src');
> $stmnt->execute(':src' => $_SERVER['PATH_INFO']);
> $row = $stmnt->fetch(PDO::FETCH_ASSOC);
>
> if ($row === false)
>    // dispatch to 404
>    ;
> else
>    include('/path/outside/webroot/' . $row['target']);
>
>
> That's all.

yep. Pretty much the same algo. I am using except I don't do OO :-)

If this comes to anything, I may need to have code maintained by old 
duffers who cut their teeth on assembler, rather than bushy tailed kids 
who do all this new fangled OO stuff.

Look, many thinks for that. Its is always nice to have questions 
answered before you ask, and have the general idea confirmed as well.

I think the general ideas of how to do it is now pretty clear, but there 
are some detail issues as to how much can and should go IN the database.

I think anything small can, but big images and videos? Hmm.

Can you execute PHP code stored in a database??

I suppose in the limit you could write it to a file, and once written 
include() it?

is there a better way? eval()?  It comes with health warnings..

..select page from code_table where id='12345'..eval (page)...hmm.

I guess its as secure as the database would be. No one who got access to 
the web area would be able to compromise it..

And there wont be much if any user input  into INTO the database, and 
that might be to a different database anyway..under a different 
name/password


And since its  PM here in Europe, I think time for an ebook in bed, and 
mull it over.



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#9828

Am 20.06.2013 23:38, schrieb The Natural Philosopher:
> I think the general ideas of how to do it is now pretty clear, but there
> are some detail issues as to how much can and should go IN the database.
> 
> I think anything small can, but big images and videos? Hmm.

Why do you want to put images and video files in the database?

> Can you execute PHP code stored in a database??
> 
> I suppose in the limit you could write it to a file, and once written
> include() it?
> 
> is there a better way? eval()?  It comes with health warnings..
> 
> ..select page from code_table where id='12345'..eval (page)...hmm.

Writing PHP code stored into a database to a file and including it is
not safer than eval()ing it in the first place, IMO.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9835

On 6/20/2013 6:34 PM, Christoph Michael Becker wrote:
> Am 20.06.2013 23:38, schrieb The Natural Philosopher:
>> I think the general ideas of how to do it is now pretty clear, but there
>> are some detail issues as to how much can and should go IN the database.
>>
>> I think anything small can, but big images and videos? Hmm.
>
> Why do you want to put images and video files in the database?
>

Nothing wrong with it.  Amongst other things, it makes things easier to 
back up.  You can also better sure integrity of your site because it's 
impossible to delete an image in use if your foreign keys are set up 
properly.

>> Can you execute PHP code stored in a database??
>>
>> I suppose in the limit you could write it to a file, and once written
>> include() it?
>>
>> is there a better way? eval()?  It comes with health warnings..
>>
>> ..select page from code_table where id='12345'..eval (page)...hmm.
>
> Writing PHP code stored into a database to a file and including it is
> not safer than eval()ing it in the first place, IMO.
>

I agree here.  Neither is safe, but necessary if you're writing a CMS.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web