| Using a single php entry file for a whole site. [message #181854] |
Thu, 20 June 2013 17:22  |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181856 is a reply to message #181854] |
Thu, 20 June 2013 17:48  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181857 is a reply to message #181854] |
Thu, 20 June 2013 17:48 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181859 is a reply to message #181857] |
Thu, 20 June 2013 18:18 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181861 is a reply to message #181854] |
Thu, 20 June 2013 18:23 |
Stefan+Usenet
Messages: 3
Registered: June 2013
Karma: 0
|
Junior Member |
|
|
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)
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181864 is a reply to message #181861] |
Thu, 20 June 2013 19:06 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181865 is a reply to message #181854] |
Thu, 20 June 2013 19:29 |
Marc van Lieshout
Messages: 10
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181866 is a reply to message #181865] |
Thu, 20 June 2013 19:38 |
Marc van Lieshout
Messages: 10
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181869 is a reply to message #181854] |
Thu, 20 June 2013 19:54 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181870 is a reply to message #181866] |
Thu, 20 June 2013 20:13 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181875 is a reply to message #181865] |
Thu, 20 June 2013 21:38 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181876 is a reply to message #181870] |
Thu, 20 June 2013 22:33 |
Marc van Lieshout
Messages: 10
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181877 is a reply to message #181875] |
Thu, 20 June 2013 22:34 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181878 is a reply to message #181876] |
Thu, 20 June 2013 22:50 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181879 is a reply to message #181875] |
Thu, 20 June 2013 22:51 |
Marc van Lieshout
Messages: 10
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
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?
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181883 is a reply to message #181876] |
Thu, 20 June 2013 23:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181884 is a reply to message #181877] |
Thu, 20 June 2013 23:37 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181889 is a reply to message #181878] |
Fri, 21 June 2013 06:45 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181890 is a reply to message #181879] |
Fri, 21 June 2013 06:54 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181892 is a reply to message #181889] |
Fri, 21 June 2013 09:08 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <kq0sqh$vlb$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)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
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #181895 is a reply to message #181892] |
Fri, 21 June 2013 10:21 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21/06/13 10:08, Tim Streater wrote:
> In article <kq0sqh$vlb$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)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.
|
|
|
|
| Re: Using a single php entry file for a whole site. [message #182159 is a reply to message #181895] |
Sun, 14 July 2013 23:15 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]