c5 in subfolder manages files on Root when Pretty URL's enabled
Permalink
I have concrete5 installed in a subfolder (eg.:http://www.example.com/test) with Pretty URLS enabled and an auto-generated .htaccess file on this subfolder. For some reason, concrete5 is managing (controlling, don't know the right term) some files that I have on another folder in the root. I noticed this when I was editing some .shtml files on a folder in the Root and forgot to adjust the addresses of some includes. Wherever the includes were supposed to go there was a c5 message that said: "Page Not Found - No page could be found at this address."
I'm not much of an expert when it comes .htaccess files and mod_rewrites but it's my understanding (someone correct me if I'm wrong) that an .htaccess file only manages calls made to the folder where the .htaccess is located.
It seems that, even though concrete5 is installed in a subdirectory beneath the Root folder, it "monitors" calls made to other folders in the Root folder when Pretty URLs are enabled.
Am I wrong, or is this a normal behavior of Pretty URLS? Could this cause problems to other installations in the root folder, say, a Wordpress installed on a subfolder named "blog"?
I'm not much of an expert when it comes .htaccess files and mod_rewrites but it's my understanding (someone correct me if I'm wrong) that an .htaccess file only manages calls made to the folder where the .htaccess is located.
It seems that, even though concrete5 is installed in a subdirectory beneath the Root folder, it "monitors" calls made to other folders in the Root folder when Pretty URLs are enabled.
Am I wrong, or is this a normal behavior of Pretty URLS? Could this cause problems to other installations in the root folder, say, a Wordpress installed on a subfolder named "blog"?
Thanks for the quick response.
Here's what I have in my .htaccess file:
To answer your second question, I don't have an .htaccess file in my web root. The permissions for the .htaccess file in the subfolder is 644. I suppose this should be enough, right?
What do you think about the behavior I'm experiencing? That is, c5 managing errors and stuff in the web root, where it's not even installed and where it seems to me that the .htaccess file in the subfolder shouldn't have any effect. When I disable Pretty URLs (therefore removing the .htaccess file from the subfolder) the php error messages go back to normal.
Is this a normal behavior of Pretty URLs? If so, could this affect other installations on other subfolders or in the web root?
Thanks again for responding.
yadielar
Here's what I have in my .htaccess file:
# -- concrete5 urls start -- <IfModule mod_rewrite.c> RewriteEngine On RewriteBase /test/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php/$1 [L] </IfModule> # -- concrete5 urls end --
To answer your second question, I don't have an .htaccess file in my web root. The permissions for the .htaccess file in the subfolder is 644. I suppose this should be enough, right?
What do you think about the behavior I'm experiencing? That is, c5 managing errors and stuff in the web root, where it's not even installed and where it seems to me that the .htaccess file in the subfolder shouldn't have any effect. When I disable Pretty URLs (therefore removing the .htaccess file from the subfolder) the php error messages go back to normal.
Is this a normal behavior of Pretty URLs? If so, could this affect other installations on other subfolders or in the web root?
Thanks again for responding.
yadielar
The file permissions 644 should work just fine. Perhaps a phpinfo() would shed some light. Also, who is your web host?
I'm doing this website for a client and he already had a hosting contract with Hostmonster (which is just kind of average to me).
I attached the phpinfo().
I suppose by your questions that this is not a normal behavior, right? Has this happened to you before?
By the way, Pretty URLs are working just fine. I'm just curious of this "strange" behavior. I really didn't expect concrete5 to take control of other pages in directories outside the one c5 is installed on.
I attached the phpinfo().
I suppose by your questions that this is not a normal behavior, right? Has this happened to you before?
By the way, Pretty URLs are working just fine. I'm just curious of this "strange" behavior. I really didn't expect concrete5 to take control of other pages in directories outside the one c5 is installed on.
I can not open your phpinfo.png file :(
Something is definately amiss. I have several development servers that I run c5 in a sub-directory off of web root and have not seen anything like you are describing.
Something is definately amiss. I have several development servers that I run c5 in a sub-directory off of web root and have not seen anything like you are describing.
Sorry. Looks that my connection went down while I was uploading. Now I'm having problems uploading it again.
Here are some temporary download links of the file:
HTML File
http://dl.dropbox.com/u/5211376/php_info.html...
Screen Capture
http://dl.dropbox.com/u/5211376/phpinfo.png...
Thanks again for helping me out. What things may shed some light in the phpinfo?
Here are some temporary download links of the file:
HTML File
http://dl.dropbox.com/u/5211376/php_info.html...
Screen Capture
http://dl.dropbox.com/u/5211376/phpinfo.png...
Thanks again for helping me out. What things may shed some light in the phpinfo?
A couple of things. For one, your are using:
Server API CGI/FastCGI - this may have something to do with it (let me think on that one a little). FastCGI has some security features that I am not all that familiar with.
Secondly:
include_path .:/usr/lib64/php:/usr/lib/php
Which says that you can only include files from current directory, /usr/lib64/php and /usr/lib/php (unless your complete path is specified).
Server API CGI/FastCGI - this may have something to do with it (let me think on that one a little). FastCGI has some security features that I am not all that familiar with.
Secondly:
include_path .:/usr/lib64/php:/usr/lib/php
Which says that you can only include files from current directory, /usr/lib64/php and /usr/lib/php (unless your complete path is specified).
OK, so it seems that the second one you mentioned may have something to do with it, if I'm judging correctly, cause it has something to do with server-side includes. The errors that concrete5 is handling are related to not finding the includes location.
What path should I specify that would give me less problems?
Still though, I don't get why c5 should meddle with a folder where it's not even installed on.
Well, if you don't have much time to answer all this (sorry for asking so much) don't worry, I'll be googling these things you mentioned. Thank you so much for taking the time to analyze the phpinfo(). You've definitively being of much help.
;-)
What path should I specify that would give me less problems?
Still though, I don't get why c5 should meddle with a folder where it's not even installed on.
Well, if you don't have much time to answer all this (sorry for asking so much) don't worry, I'll be googling these things you mentioned. Thank you so much for taking the time to analyze the phpinfo(). You've definitively being of much help.
;-)
i think its somthing with path_info as iv had other tools and cms's do the same thing to me,
I've found out what was causing it. It was merely a very uncommon coincidence.
At first, when I saw that the includes locations were incorrect, I went and quickly corrected the incorrect locations and saved it. After that, there were obviously no more errors, but the fact that I had received c5's error page was puzzling me. There were a couple of pages with the wrong include paths and I just had corrected the most important ones.
I then started to check the .htaccess file and disabling Pretty URLs and that seemed to somehow correct the mysterious behavior in the other pages.
But it was nothing about that. The thing is that the incorrect include paths were actually directing to the folder were concrete5 was installed. It seems that my client had coincidentally created a folder with same name as the one I just created to install c5, where he stored the includes. Later he changed it to the actual one.
I should have looked more closely at the incorrect paths. Sorry for that but thank you so much for trying to help me out. People like you really make this community so great.
At first, when I saw that the includes locations were incorrect, I went and quickly corrected the incorrect locations and saved it. After that, there were obviously no more errors, but the fact that I had received c5's error page was puzzling me. There were a couple of pages with the wrong include paths and I just had corrected the most important ones.
I then started to check the .htaccess file and disabling Pretty URLs and that seemed to somehow correct the mysterious behavior in the other pages.
But it was nothing about that. The thing is that the incorrect include paths were actually directing to the folder were concrete5 was installed. It seems that my client had coincidentally created a folder with same name as the one I just created to install c5, where he stored the includes. Later he changed it to the actual one.
I should have looked more closely at the incorrect paths. Sorry for that but thank you so much for trying to help me out. People like you really make this community so great.
Mnkras:
Still what you said interests me, since it seems that it COULD happen. Have you found out the reason? What would be the best path to assign to the include_path option?
Still what you said interests me, since it seems that it COULD happen. Have you found out the reason? What would be the best path to assign to the include_path option?
I usually set up a common place to put my all my includes. Someplace safe outside of my web space, like in your case /home/username/include. Then set your include_path via the php.ini using something like:
include_path = .:/usr/lib64/php:/usr/lib/php:/home/username/include
This way you don't have to worry about any relative filename paths getting confused based on the calling directory. Just call your include and PHP will go find it in the /home/username/include direcoty. Hope this helps :)
include_path = .:/usr/lib64/php:/usr/lib/php:/home/username/include
This way you don't have to worry about any relative filename paths getting confused based on the calling directory. Just call your include and PHP will go find it in the /home/username/include direcoty. Hope this helps :)
Awesome, thank you! I'll start doing what you mentioned from now on.
You've definitively being of much help.
You've definitively being of much help.
Your very welcome :) I'm always glad to help our a fellow c5'er. Let me know if you have any more questions.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /test/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
Do you have a .htaccess file in your web root? Also, your .htaccess files must have Global Read permissions for Apache to see them.