After centralizing core - getThemeDirectory path errors in html.php
Permalink
Hi, I am new to c5 and have so far successfully installed version 5.5.2.1 on my Windows Web Server 2008.
Everything seemed to be working ok.
I followed the instruction to centralize the core here: (http://www.concrete5.org/documentation/how-tos/developers/setting-up-and-maintaining-a-centralized-concrete5-installation/)
which, after some teething troubles, seems to have gone ok except for one error I can't get to the bottom of...
I allowed the c5 installation to provide me with the basic 'Welcome to concrete5' example site using the newly centralized themes.
Now, when I click on the 'Blog' or 'Search' menu links I get the following errors:
I tracked the error down to the way 'getThemeDirectory()' returns the path.
It looks like this:
While trying to find a solution to this I found this thread:
(http://www.concrete5.org/developers/bugs/5405/file_exists-not-good-with-relative-paths-and-php-5-1-6/-/copyToCurrentDefault/)
Although it references an earlier version of PHP then I have installed, I applied the 'realpath()' function to the various 'file_exists()' checks in html.php between lines 63 and 70.
Incredibly, this fixed the problem by instead returning paths that look like this:
Much better!
However, although I can now access the Blog and Search pages on the default c5 site, the same error did then crop up when trying to edit pages. Clearly this is a hack rather than a 'fix'.
So, I deduced that this was obviously a bigger issue, the source of which was most likely elsewhere (and probably related to centralization because it wasn't happening before I split the core code off).
Anyone got any ideas what is going on or suggestions for a more suitable fix instead of this workaround which I really don't fancy applying to all instances of 'file_exists()' that there are in concrete5 source code.
Thanks for reading this ramble.
Matt.
Everything seemed to be working ok.
I followed the instruction to centralize the core here: (http://www.concrete5.org/documentation/how-tos/developers/setting-up-and-maintaining-a-centralized-concrete5-installation/)
which, after some teething troubles, seems to have gone ok except for one error I can't get to the bottom of...
I allowed the c5 installation to provide me with the basic 'Welcome to concrete5' example site using the newly centralized themes.
Now, when I click on the 'Blog' or 'Search' menu links I get the following errors:
PHP Warning: file_exists(): open_basedir restriction in effect. File(C:\inetpub\wwwroot\concrete5\concrete5.5.2.1\concrete\config/../themes/greek_yogurt/http://mysubdomain.mydomainname.co.uk/concrete/blocks/page_list/view.css) is not within the allowed path(s): (C:\inetpub\wwwroot;C:\php\pear\;C:\php\;C:\php\tmp\) in C:\inetpub\wwwroot\concrete5\concrete5.5.2.1\concrete\helpers\html.php on line 63 PHP Warning: file_exists(): open_basedir restriction in effect. File(C:\inetpub\wwwroot\c5/css/http://mysubdomain.mydomainname.co.uk/concrete/blocks/page_list/view.css) is not within the allowed path(s): (C:\inetpub\wwwroot;C:\php\pear\;C:\php\;C:\php\tmp\) in C:\inetpub\wwwroot\concrete5\concrete5.5.2.1\concrete\helpers\html.php on line 65 PHP Warning: file_exists(): open_basedir restriction in effect. File(C:\inetpub\wwwroot\concrete5\concrete5.5.2.1\concrete\config/../themes/greek_yogurt/http://mysubdomain.mydomainname.co.uk/concrete/blocks/tags/view.css) is not within the allowed path(s): (C:\inetpub\wwwroot;C:\php\pear\;C:\php\;C:\php\tmp\) in C:\inetpub\wwwroot\concrete5\concrete5.5.2.1\concrete\helpers\html.php on line 63 PHP Warning: file_exists(): open_basedir restriction in effect. File(C:\inetpub\wwwroot\c5/css/http://mysubdomain.mydomainname.co.uk/concrete/blocks/tags/view.css) is not within the allowed path(s): (C:\inetpub\wwwroot;C:\php\pear\;C:\php\;C:\php\tmp\)
Viewing 15 lines of 16 lines. View entire code block.
I tracked the error down to the way 'getThemeDirectory()' returns the path.
It looks like this:
C:\inetpub\wwwroot\concrete5\concrete5.5.2.1\concrete\config/../themes/greek_yogurt
While trying to find a solution to this I found this thread:
(http://www.concrete5.org/developers/bugs/5405/file_exists-not-good-with-relative-paths-and-php-5-1-6/-/copyToCurrentDefault/)
Although it references an earlier version of PHP then I have installed, I applied the 'realpath()' function to the various 'file_exists()' checks in html.php between lines 63 and 70.
Incredibly, this fixed the problem by instead returning paths that look like this:
C:\inetpub\wwwroot\concrete5\concrete5.5.2.1\concrete\themes\greek_yogurt
Much better!
However, although I can now access the Blog and Search pages on the default c5 site, the same error did then crop up when trying to edit pages. Clearly this is a hack rather than a 'fix'.
So, I deduced that this was obviously a bigger issue, the source of which was most likely elsewhere (and probably related to centralization because it wasn't happening before I split the core code off).
Anyone got any ideas what is going on or suggestions for a more suitable fix instead of this workaround which I really don't fancy applying to all instances of 'file_exists()' that there are in concrete5 source code.
Thanks for reading this ramble.
Matt.
Bug report published here:
http://www.concrete5.org/developers/bugs/5-5-2-1/file_exists-open_b...
if you would like to tick it up.
Thanks, Matt.
http://www.concrete5.org/developers/bugs/5-5-2-1/file_exists-open_b...
if you would like to tick it up.
Thanks, Matt.
I added tick, thanks.
It just manifests itself in a slightly different way for them.
Basically, if I switch 'open_basedir' off in php.ini it will clear the error. This, of course, is not ideal.
The other hack is wherever the 'file_exists()' function is used and may be fed a non-standard path (i.e. a relative path or something screwy like the one in my above post) to wrap the directory/file parameter in the 'realPath()' function.
this fixes the problem in isolation but unfortunately, this may need to be applied in many many places throughout concrete5's core code base.
Again, not ideal.
Does anyone have another idea of a better, more manageable and maintainable fix?
Thanks, Matt.