-- Cristian Bichis <cont...@zftutorials.com> wrote (on Tuesday, 16 March 2010, 10:29 PM +0200): > Please let me explain again the bug. > > The HeadLink plugin is searched through all the possible paths. This > includes also the: > > D:\_Work\myapp/application/modules\articles/views\helpers/HeadLink.php
But look at the path you reported in the issue -- it says "D:_". Is it possible you added the path incorrectly? Or that ZF stripped the backslash out? That's what I was trying to get at in the last email. > But since the file HeadLink.php of course that is not into > D:\_Work\myapp/application/modules\articles/views\helpers/ (but > rather into ZF library) the is_readable is of course returning > false... So the absolute path check is actually failing... > > Then you can imagine the rest... > > Is looking even on odd paths as: > > D:\wamp\frameworks\ZendFramework-1.10.2/D:_Work\myapp/application/modules\articles/views\helpers/HeadLink.php > > Which lead to a wrong open_basedir warning... > > The bug has nothing to do with open_basedir, is only related to the > way is_readable works for checking for absolute paths... Is actually > checking fine just for files which already exists into filesystem... > Not for plugin searches (when a plugin would be found in one - or > more - paths, but not into all)... > > > >-- Cristian Bichis<cont...@zftutorials.com> wrote > >(on Tuesday, 16 March 2010, 09:56 PM +0200): > >>Speaking of autoloading on 1.10.1+, anyone checked for a potential > >>better implementation/fix for this ? > >> > >>http://framework.zend.com/issues/browse/ZF-9306 > >> > >>Since is quite an annoying bug... > >Have you looked at the isReadable() implementation? > > > >The very first line is: > > > > if (is_readable($filename)) > > > >which will return true for an absolute path. > > > >Looking at your report, it looks like the issue is that you're working > >on a system where open_basedir is enabled, and that the file as > >specified does not live within the basedir as configured -- leading to > >the false negative. > > > > > >>>-- Mike A<mik...@hotmail.co.uk> wrote > >>>(on Monday, 15 March 2010, 07:41 PM -0800): > >>> > >>>>Asking this because I've researched for a week but remain unclear. I need > >>>>to > >>>>know not only for projects but to help newcomers in a book chapter > >>>>currently > >>>>under authorship. Before asking I have set up a test project having access > >>>>to two modules (default and admin) with a personalised library and two ZF > >>>>libraries (ZF1.0 and ZF 1.12) in a "libraries" folder (both ZF libraries > >>>>have a subdirectory "Zend" to conform) so a quick switch between versions > >>>>can be made in the application.php which calls Zend_Application and > >>>>Bootstrap.php. > >>>> > >>>Umm... don't mean to be contradictory from the outset, but can you > >>>clarify the version numbers you're using? ZF 1.12 does not exist, and I > >>>fail to see why you'd be using ZF 1.0 for any examples or test projects > >>>at this time as it's severely out-of-date. > >>> > >>>BTW, if you're using ZF 1.10 or above, you can actually switch between > >>>ZF versions fairly easily; see > >>> > >>> http://framework.zend.com/manual/en/zend.loader.autoloader.html > >>> > >>>under the heading "Selecting a Zend Framework version". > >>> > >>> > >>>>In all cases, an application.php "start up" file works fine in one > >>>>environment but will not transpose to another, especially Ubuntu (v9.10). > >>>>There are problems with autoloading unless I change the file to suit a > >>>>particular operating environment. This suggests there is something lacking > >>>>in the ZF approach to loader/autoloader methods. I mention this last point > >>>>on the basis that a stable framework should work across all intended > >>>>platforms once the environment is set up. > >>>> > >>>Honestly, I'm going to need a lot more detail than this -- full file > >>>hierarchy, the test script in question, etc. I use Ubuntu as my primary > >>>desktop and testing platform, and can assure you that autoloading works > >>>fine in that environment. Additionally, we test regularly on Mac and > >>>Windows -- the autoloader is designed to be OS-agnostic. If it's truly > >>>not working for you, my guess is that you are not defining your > >>>include_path well -- but without more information, I cannot verify that. > >>> > >>>The key to good bug reporting is providing good reproduce cases. More > >>>detail is always better -- but stick to the bare minimum of detail > >>>needed to reproduce the issue. > >>> > >>> > >>>>I've seen lots of references, tutorials and forum posts displaying > >>>>problems > >>>>with setting up a modular ZF project before asking. I recognise that > >>>>servers > >>>>can be set up in different ways but surely ZF should work in a shared > >>>>hosting environment with web root (htdocs) for public access and > >>>>none-public > >>>>folders for processing - and be capable of moving from one host to > >>>>another > >>>>without needing to change paths if the directory structure is kept intact. > >>>> > >>>Yes it can, and yes it does. We don't recommend the practice, as it's > >>>more secure to keep application files outside the web root -- but ZF can > >>>and does work fine in such environments. Again, it's simply a matter of > >>>include_path and application path configuration. > >>> > >>> > >>>>1. Is there a tutorial/reference that some kind soul somewhere can point > >>>>me > >>>>to which explains setting up a ZF project in the context mentioned? > >>>>References in ZF manual are somewhat basic/raw. > >>>> > >>>It's really easy: > >>> > >>> * Make sure your include_path includes an entry pointing to the > >>> directory above the "Zend/" subdirectory of your ZF install. > >>> > >>> * Make sure your APPLICATION_PATH constant points to your application/ > >>> directory, and that you specify an appropriate path to your > >>> application configuration file when instantiating Zend_Application. > >>> > >>>As an example, if you have the following directory layout: > >>> > >>> web_root/ > >>> |-- application/ > >>> | |-- Bootstrap.php > >>> | |-- configs/ > >>> | | |-- application.ini > >>> ... > >>> |-- library/ > >>> | |-- Zend/ > >>> |-- index.php > >>> > >>>then I'd create my index.php as follows: > >>> > >>> <?php > >>> // Define path to application directory > >>> defined('APPLICATION_PATH') > >>> || define('APPLICATION_PATH', realpath(dirname(__FILE__) . > >>> '/application')); > >>> > >>> // Define application environment > >>> defined('APPLICATION_ENV') > >>> || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? > >>> getenv('APPLICATION_ENV') : 'production')); > >>> > >>> // Ensure library/ is on include_path > >>> set_include_path(implode(PATH_SEPARATOR, array( > >>> realpath(APPLICATION_PATH . '/library'), > >>> get_include_path(), > >>> ))); > >>> > >>> /** Zend_Application */ > >>> require_once 'Zend/Application.php'; > >>> > >>> // Create application, bootstrap, and run > >>> $application = new Zend_Application( > >>> APPLICATION_ENV, > >>> APPLICATION_PATH . '/configs/application.ini' > >>> ); > >>> $application->bootstrap() > >>> ->run(); > >>> > >>>If you look carefully, it's not much different from the > >>>public/index.html that Zend_Tool creates -- the only real differences > >>>are that the paths specified for APPLICATION_PATH and the include_path > >>>do not include parent directory traversal as they're in the same > >>>relative location as the current directory. > >>> > >>> > >>>>2. Are there plans to simplify manual set-up and autoloading processes > >>>>(ie, > >>>>without using Zend Tool)? If so, references/when? > >>>> > >>>I'm really not sure what needs to be simplified. Can you elaborate on > >>>what you feel is too complex? > >>> > >>> > >>>>3. Appreciating always that I am/was not privy to the mindset and in-house > >>>>discussions bearing upon the mode of configuring paths and choice of > >>>>autoloading, can someone briefly describe the problems/issues leading to > >>>>adopting system path methods that do not work across platforms?* > >>>> > >>>You can configure the include_path within PHP scripts -- the index.php > >>>above does this. The only "gotchas" you need to worry about are ensuring > >>>that the various entries are separated by the OS-specific path > >>>separator. PHP makes this trivial by defining a PATH_SEPARATOR constant > >>>(also used above). > >>> > >>> > >>>>4. Is ZF development currently in a phase bridging<v1.10 with forthcoming > >>>>v2.0 and thus exposing a few niggles, like that of autoloading? If so, are > >>>>there other basic areas of the framework undergoing change that will > >>>>expose > >>>>cross-platform configuration issues. > >>>> > >>>First off, we're not going to bridge versions< 1.10 with 2.0. 2.0 is an > >>>evolutionary development that will be building off current revisions, > >>>while also introducing namespaces, lambdas, and some rewrites. > >>> > >>>Autoloading has been common in ZF for some time; in 1.8, we made it more > >>>"official" with the introduction of Zend_Application, which uses > >>>autoloading by default. The only changes we anticipate to the basic > >>>autoloading mechanism is ensuring support for PHP 5.3 namespaces as well > >>>as 5.2-style vendor prefixes (support for 5.3 namespaces is already > >>>available in ZF 1.10; differentiation between them and vendor prefixes > >>>is available on the development-2.0 branch). And, of course, 2.0 will > >>>require autoloading -- require_once statements will be gone from the > >>>library (except in a few select cases, primarily in the Zend\Loader > >>>tree). > >>> > >>>As noted, autoloading currently works and is tested across platforms -- > >>>unless you can provide me with a reproduce case that proves otherwise. > >>> > >>> > > > -- > Best regards, > Cristian Bichis > www.zftutorials.com | www.zfforums.com | www.zftalk.com | www.zflinks.com > -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
