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.

Started byThe Natural Philosopher <tnp@invalid.invalid>
First post2013-06-20 18:22 +0100
Last post2013-06-20 14:54 -0500
Articles 3 on this page of 23 — 8 participants

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 2 of 2 — ← Prev page 1 [2]

#9830

FromMarc van Lieshout <invalid@example.com>
Date2013-06-21 00:51 +0200
Message-ID<51C3876E.7020700@example.com>
In reply to#9826
On 20-06-13 23:38, The Natural Philosopher wrote:
> 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.
>
>
>

1. You can put files & videos in the web directory, and let your 
webserver handle them. That's the most efficient way.

2. If you want, you can put them outside the web directory and use

header('Content-type: image/jpeg')
readfile('/path/to/file.jpeg');

3. You can put them in the database and echo the contents. You'll need 
real hardware if it's a busy site.

PPH code in a database is simply executed by

    eval($row['code']);

If you're the only one that can fill this column, there's nothing wrong 
with eval. What do you think PHP calls when it executes your code?

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

#9841

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2013-06-21 07:54 +0100
Message-ID<kq0taa$rl$1@news.albasani.net>
In reply to#9830
On 20/06/13 23:51, Marc van Lieshout wrote:
> On 20-06-13 23:38, The Natural Philosopher wrote:
>> 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.
>>
>>
>>
>
> 1. You can put files & videos in the web directory, and let your 
> webserver handle them. That's the most efficient way.
>
> 2. If you want, you can put them outside the web directory and use
>
> header('Content-type: image/jpeg')
> readfile('/path/to/file.jpeg');
>
that is really little different to calling them up from the db.
The real issue is whether direct via apache, they get buffered into 
memory at all, or just streamed.
I think with the site in question, it is currently dying on its feet 
from lack of memory. Due to a combination of lack of it and overuse of 
large graphic objects and flash videos.
Obviously redesigning to use less of them is an approach, but efficient 
handling of them is an intrinsic part of it too.

> 3. You can put them in the database and echo the contents. You'll need 
> real hardware if it's a busy site.
>
That is the killer. How much extra CPU cycles and/or memory it would use.

Is there a simple pragmatic way to establish that?

> PPH code in a database is simply executed by
>
>    eval($row['code']);
>
> If you're the only one that can fill this column, there's nothing 
> wrong with eval. What do you think PHP calls when it executes your code?
>
Mmm. never really thought about it.

>
>
>
>
>
>
>
>
>
>
>
>
>
>


-- 
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]

#9820

From"Peter H. Coffin" <hellsop@ninehells.com>
Date2013-06-20 14:54 -0500
Message-ID<slrnks6ng2.msg.hellsop@nibelheim.ninehells.com>
In reply to#9805
On Thu, 20 Jun 2013 18:22:18 +0100, 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.

You describe almost exactly how mediawiki works. Why not start looking
at that to see how it does it?

-- 
14. The hero is not entitled to a last kiss, a last cigarette, or any 
   other form of last request.
        --Peter Anspach's list of things to do as an Evil Overlord

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web