php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #48546 include/require callbacks
Submitted: 2009-06-14 03:34 UTC Modified: 2013-11-02 14:40 UTC
From: cory dot mawhorter at ephective dot com Assigned:
Status: Wont fix Package: *General Issues
PHP Version: 6CVS-2009-06-14 (CVS) OS: na
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: cory dot mawhorter at ephective dot com
New email:
PHP Version: OS:

 

 [2009-06-14 03:34 UTC] cory dot mawhorter at ephective dot com
Description:
------------
Two suggestions for include/require.

1) A callback function.
2) Custom include/require functions.

Reproduce code:
---------------
Callback function example:

function verify_path($absfile) {
   return (basename($absfile) == 'some-file.php');
}

set_include_cb('verify_path');
include 'some-file.php'; // cb returns true: file included
include 'some-other-file.php'; // cb returns false: warning
require 'some-other-file.php'; // cb returns false: fatal error

I could see this being useful in more situations than simply verifying the include path is correct.

An include/require replacement:

function my_custom_include($inc) {
    // of course, includes into the scope of the function
    include($inc); 

    // it'd be nice if you could tell it to include into 
    // the root scope or whatever... this might be difficult 
    // to do for security reasons... but i'm still throwing 
    // it out there
}

my_custom_include('some-file.php');


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-06-20 09:49 UTC] simon at stienen dot name
To be honest, I don't think either would be necessary, however while I can see some slight sense for 1), I don't see any need for 2) at all - if you want something like that: Just write such a function, but make sure to use $GLOBALS['foo'] instead of just $foo in your include file. Every other way to do this would mess with scoping. And believe me: If you don't want to do SOMETHING, it's messing with the scope.

Anyway, my two cents to 1):
Imo this feature (even if unnecessary in the first place) would be of much more use, if it would return false on failure (as stated), but the *actual* file name to be included on success. This way, you could extend the file naming scheme to, for example, have "mod:bla" include/require the "bla" script from your modules directory.
Additionally it might be nice to have a second parameter telling you whether it's an include or a require process (maybe even whether it's a _once), so you could decide to soften that error.

Anyway, as I said: This is nothing that couldn't be done without such a callback in the first place: You could just
   include sanitize('foo');
instead.
 [2013-11-02 14:40 UTC] krakjoe@php.net
-Status: Open +Status: Wont fix -Package: Feature/Change Request +Package: *General Issues
 [2013-11-02 14:40 UTC] krakjoe@php.net
As mentioned in the only reply, there is a trivial solution to this in userland, just wrap the argument to include construct in your function call and you have the same behaviour without changing anything.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat May 18 14:01:35 2024 UTC