FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Using a single php entry file for a whole site.
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
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 Go to previous messageGo to previous message
Marc van Lieshout is currently offline  Marc van Lieshout
Messages: 10
Registered: March 2011
Karma:
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?
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Updating old PHP code
Next Topic: Komodo Edit
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri Nov 22 07:34:16 GMT 2024

Total time taken to generate the page: 0.05211 seconds