When I enable pretty urls, I get a pretty bland page stating 'No input file specified'
A minimal amount of research has led me to believe that PHP running as a CGI on Dreamhost mixed together with mod_rewrite has somehow created a cocktail that makes it so the PHP CGI binary doesn't know where the file it's being told to load is (index.php).
One thing I noticed fairly quickly is that phpinfo() isn't printing environment variables on the boostfoundation.org site, but it is on jeremeclaussen.com.
Not sure if this is an indicator that they need to be there for it to run, or if they are even actually missing.
I've added dumps of the $_SERVER hash to the top of both sites for debugging purposes...
I've fixed all my rewrite problems starting with this:
1. call a phpinfo file with info.php/pathinfo. Sometimes not even this works!
2. try adding [R] at the end of the rule, this way you can see what url apache (and isapi_rewrite too!) are generating. easier to test the rules this way.
because I remember having the exact same problem at Godaddy hosting and doing nothing...and yet the problem has rectified itself (i.e. - I can use pretty URLs on Godaddy).
I do believe you're correct in that .htaccess is causing requests to not even make it to the right file.
Thanks for the instructions, they work. I just barely did this with my pretty URL setup on DreamHost. In cast it isn't clear to other readers, you have to follow all of the steps outlined in the wiki
- copy the php.ini file
- create the script wrapper
- set permissions
- set up .htacces (with your rewrite rule after the php-cgi stuff)
Not sure if anybody is still seeing this thread, but a really easy solution that worked for me was simply adding a ? after the target file in the .htaccess text.
So in the case of concrete5 on dreamhost, you'd take this line
RewriteRule ^(.*)$ index.php/$1[L]
and change it to
RewriteRule ^(.*)$ index.php?/$1[L]
That worked for me without any additional changes.
There is a certain optional behaviour of PHP where it takes everything past the ".php" in a url and treats it as if it were a "querystring" (all the stuff after a question mark in a url). C5 uses this to determine what the path is of the page that's being requested (for example,http://example.com/about-us gets rewritten by htaccess tohttp://example.com/index.php/about-us,... then C5 sees that what follows "index.php" is "/about-us", and looks up the page based on that path).
Now, the problem is that some servers for whatever reason are configured to not treat the stuff that follows ".php" in the URL in this way, so basically C5 doesn't receive that path that follows index.php in the rewritten url. Apparently this is the case with Dreamhost (sometimes, because other time it just works fine I believe -- weird).
So I think putting the question mark after that forces it to see what follows as a "querystring" (because recognizing the question mark is standard across every server configuration in the universe), and hence pass the path along to C5 so it knows which page to serve.
I'm just guessing though -- I don't know for sure.
After failing at this left and right, I finally arrived at a half-way semi acceptable solution. It's obvious DH has an issue on some of their servers and not on others.
The solution is to follow the directions for running a custom php.ini, however there's one exception.
Right now we're really adding to our FAQs - to the point where pretty soon our current solution of just listing them all is going to need some tweaking. ;-) However, this is definitely going in there. Thanks for putting in the work to figure this out.
Heh, and regarding that PHP page on their wiki: wow! A little bit complicated, eh? ;)
What gets me is that they claim there is no issue. But when I re-implement their php5-cgi with seemingly no changes it works.
But hey, it's free non-profit hosting I guess.
I could always grab a phpinfo from the wrapper version and a phpinfo from normal and try to spot the fly on the wall. However, they don't seem to give a crap.
Plus, the site is non-profit and we're not paying, so why would they give a crap?
It appears that the php.ini needs to be inside your site directory as outlined in these steps in order for the .htaccess to accomplish it's function. So, follow what Ender posted up above and you will be set.
I'm experiencing this problem, i think, with a uk host so that when mod_rewrite is on I experience the following:
"No input file specified" page as decribed above.
Fortunately my hosters seem to have a good level of support and offer to help out if i can point out what needs doing/installing to resolve it then they will consider it.
Is anyone able to specify what the problem is that causes this error?
Alternatively do you think the dreamhosts workaround is universal?
Actually there's an updated version on my blog that details a solution very similar to what you have arrived at. You will need to make one further change in order to avoid all possible problems when running php5-fcgi.
Is this supposed to be done along with something? It did stop giving me "No input file specified," but instead is redirecting to the home page; oddly, not to its own, but to a higher one.
To explain: I am, quite frankly, in way over my head. Presently, to try to decide which will work best for a project I'm working on, I actually have multiple CMSs installed on one site. I was originally going to try using WordPress, since it was the only one I'd done anything with before, but it was looking like it was going to be overly complicated; so I made sub-directories to experiment with with C5 and a couple others.
I've got the RewriteBase in the .htaccess file put in for the correct subdirectory and config/site.php has
as described in the installation thing (http://www.concrete5.org/documentation/installation/installing_conc... ). I would assume that, even if the redirect is wrong, that it would at least go back to the subdirectory's index, since I have Concrete5 completely contained in there. Of course, I don't really want it to do that, either; I want it to simply not redirect.
So... please pardon any clear idiocy I may be showing... but can I get any help on this?
Not sure if this is an indicator that they need to be there for it to run, or if they are even actually missing.
I've added dumps of the $_SERVER hash to the top of both sites for debugging purposes...