Every page returns "Page Not Found" except home page (with Pretty URLs on)
Permalink 1 user found helpful
IMPORTANT -- APACHE UPGRADE MAY BREAK EVERY CONCRETE5 5.x SITE THAT IS LIVE
(not sure about 5.7)
Since about Oct 15, 2015 one of my sites gave Page Not Found errors on every page, except the home page. Last night it happened to one of my other sites too.
Both are running Concrete5 version 5.6.x (update: just checked, they are running 5.6.2.1 and 5.6.3.3 currently, reminds me I need to upgrade ;))
After hours of trying to find the problem, some debugging of dispatcher.php and request.php, checking htaccess etc. I found the problem to be in the contents of the REDIRECT_URL server variable. It now contained the full URL, (eg.http://hostname.com/news/) instead of just the part after the hostname (eg. /news/).
After discussion with my hosting company they told me they upgraded Apache to 2.4.17.
A quick search taught me that the following bugfix regarding REDIRECT_URL was backported to 2.4.17:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57785...
This version of Apache was released on Oct 13, 2015.
Since the function 'get' and 'parsePathFromRequest' in request.php do not handle a full URL in REDIRECT_URL correctly, the result is that the page (now a full URL) cannot be found in the database, resulting in errors on all pages except home.
How to fix:
I did the following: In my config/site.php I added this:
This solved the problem for me.
Hopefully the Concrete5 team can make changes to the request.php file, because I think this will break Pretty URLs for every installation of C5, live sites included!
Additional info: If Pretty URLs are turned off everything works. Also when adding the index.php into the URL manually (with Pretty URLs still turned on) the pages also load correctly.
Update: Thought I would double-check if this is really an issue in a clean install of 5.6.3.4. So, I installed from scratch and chose to install the demo site. Checked if the pages were working: yes, they did, but with the index.php in between of course.
Then turned on Pretty URLs by checking the checkbox. Checked the pages again: homepage worked, all other pages showing "Page Not Found".
(not sure about 5.7)
Since about Oct 15, 2015 one of my sites gave Page Not Found errors on every page, except the home page. Last night it happened to one of my other sites too.
Both are running Concrete5 version 5.6.x (update: just checked, they are running 5.6.2.1 and 5.6.3.3 currently, reminds me I need to upgrade ;))
After hours of trying to find the problem, some debugging of dispatcher.php and request.php, checking htaccess etc. I found the problem to be in the contents of the REDIRECT_URL server variable. It now contained the full URL, (eg.http://hostname.com/news/) instead of just the part after the hostname (eg. /news/).
After discussion with my hosting company they told me they upgraded Apache to 2.4.17.
A quick search taught me that the following bugfix regarding REDIRECT_URL was backported to 2.4.17:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57785...
This version of Apache was released on Oct 13, 2015.
Since the function 'get' and 'parsePathFromRequest' in request.php do not handle a full URL in REDIRECT_URL correctly, the result is that the page (now a full URL) cannot be found in the database, resulting in errors on all pages except home.
How to fix:
I did the following: In my config/site.php I added this:
define('SERVER_PATH_VARIABLE', 'REQUEST_URI');
This solved the problem for me.
Hopefully the Concrete5 team can make changes to the request.php file, because I think this will break Pretty URLs for every installation of C5, live sites included!
Additional info: If Pretty URLs are turned off everything works. Also when adding the index.php into the URL manually (with Pretty URLs still turned on) the pages also load correctly.
Update: Thought I would double-check if this is really an issue in a clean install of 5.6.3.4. So, I installed from scratch and chose to install the demo site. Checked if the pages were working: yes, they did, but with the index.php in between of course.
Then turned on Pretty URLs by checking the checkbox. Checked the pages again: homepage worked, all other pages showing "Page Not Found".
Hey there, Great catch! You should post a bug report for your version of C5 and maybe even send a pull request on the Github repository
Actually, not so great... ;)
Will make a bug report now, just wanted to get this out asap...
Will make a bug report now, just wanted to get this out asap...
not so great...but thank you for reporting this back to the community and devs !
Hi,
I am getting a very similar error but it's the home page that isn't found but the rest of the site pages are loading in fine?
I was made aware of this on the 16th Oct.
I haven't touched the site in months which points to a server issue or update?
I am getting a very similar error but it's the home page that isn't found but the rest of the site pages are loading in fine?
I was made aware of this on the 16th Oct.
I haven't touched the site in months which points to a server issue or update?
Care to share some urls?
Do you use pretty urls?
Does the homepage work when you add index.php/ to the end?
Do you use pretty urls?
Does the homepage work when you add index.php/ to the end?
Hi see the URL below. Yes I have pretty URL's on.
Yes adding index.php fixes the issue.
The host is names.co.uk
http://www.teaandsympathy.uk.com/...
Yes adding index.php fixes the issue.
The host is names.co.uk
http://www.teaandsympathy.uk.com/...
Adding index.php to the end of the URL works for your home page:
http://www.teaandsympathy.uk.com/index.php...
Not sure if it is related...
Do you know the version of Apache?
What does your htaccess file look like?
What happens when you log in?
Can you edit the page?
To check if it has to do with the original error I mentioned at the beginning, you could try uploading a file called serverinfo.php and put the following in it:
Edit: Sorry, you'd better add this to the beginning of concrete/dispatcher.php, not in a separate file as mentioned above.
(hope I typed everyting correctly)
Open it on your site and take a look at the following values:
PATH_INFO
REDIRECT_URL
REQUEST_URI
ORIG_PATH_INFO
SCRIPT_NAME
These are the ones that C5 looks at (in request.php), after checking SERVER_PATH_VARIABLE that you may have defined in site.php.
http://www.teaandsympathy.uk.com/index.php...
Not sure if it is related...
Do you know the version of Apache?
What does your htaccess file look like?
What happens when you log in?
Can you edit the page?
To check if it has to do with the original error I mentioned at the beginning, you could try uploading a file called serverinfo.php and put the following in it:
Edit: Sorry, you'd better add this to the beginning of concrete/dispatcher.php, not in a separate file as mentioned above.
<pre> <?php var_dump($_SERVER); ?> </pre>
(hope I typed everyting correctly)
Open it on your site and take a look at the following values:
PATH_INFO
REDIRECT_URL
REQUEST_URI
ORIG_PATH_INFO
SCRIPT_NAME
These are the ones that C5 looks at (in request.php), after checking SERVER_PATH_VARIABLE that you may have defined in site.php.
Thanks I will look into it.
I have also got in contact with the webhost to see if they can shed some light on the issue.
I have also got in contact with the webhost to see if they can shed some light on the issue.
I see you have Google Analytics... take a look there at
Behavior->Site Content->All Pages
Then choose Primary Dimension: 'Page Title' just under the graph.
Now change the Date Range narrowing it down to the first day that you are seeing "Page Not Found" appearing in the list. That's the day it stopped working.
If that day is before Oct 13 (Apache release), you can be pretty sure it is something else.
Behavior->Site Content->All Pages
Then choose Primary Dimension: 'Page Title' just under the graph.
Now change the Date Range narrowing it down to the first day that you are seeing "Page Not Found" appearing in the list. That's the day it stopped working.
If that day is before Oct 13 (Apache release), you can be pretty sure it is something else.
Thanks for your advice.
Looking at the analytics It appears the error occurred from Friday 16th.
I have just switched Pretty URLs off and on and it appears to of cleared the problem at the moment. However this is how I fixed it on Friday but the error eventually occurred again.
Once again thanks for your support.
Looking at the analytics It appears the error occurred from Friday 16th.
I have just switched Pretty URLs off and on and it appears to of cleared the problem at the moment. However this is how I fixed it on Friday but the error eventually occurred again.
Once again thanks for your support.
Thanks for posting this fix as it helped with our general issues with the Apache update. However we have a few pages on our website that are using some custom htaccess rules for dynamic code that doesn't seem to work unless we full map out the domain in the mod rewrite rule.
What used to work:
RewriteCond %{PATH_INFO} !^/area/subitem/.+ [NC,OR]
RewriteRule ^area/subitem/(.+) /area/subitem/?_siUrl=$1 [NC,L]
Has to be rewritten as:
RewriteCond %{PATH_INFO} !^/area/subitem/.+ [NC,OR]
RewriteRule ^area/subitem/(.+)http://www.domain.com/area/subitem/?_siUrl=$1... [NC,L]
Oddly though, the url gets rewritten when loaded as:http://www.domain.com/area/subitem/?_siUrl=itempage...
Instead of being:http://www.domain.com/area/subitem/itempage...
Any help/advise would be very much appreciated. Thank you!
What used to work:
RewriteCond %{PATH_INFO} !^/area/subitem/.+ [NC,OR]
RewriteRule ^area/subitem/(.+) /area/subitem/?_siUrl=$1 [NC,L]
Has to be rewritten as:
RewriteCond %{PATH_INFO} !^/area/subitem/.+ [NC,OR]
RewriteRule ^area/subitem/(.+)http://www.domain.com/area/subitem/?_siUrl=$1... [NC,L]
Oddly though, the url gets rewritten when loaded as:http://www.domain.com/area/subitem/?_siUrl=itempage...
Instead of being:http://www.domain.com/area/subitem/itempage...
Any help/advise would be very much appreciated. Thank you!
Can you tell us which URL must turn in which other URL (example)?
Your rule looks like it is now doing exactly what you ask it to do...
Your rule looks like it is now doing exactly what you ask it to do...
Sorry about that, here would be the perfect world situation:
The path ofhttp://www.domain.com/area/subitem/itempage/... would be translated tohttp://www.domain.com/area/subitem/?_siURL=itempage/...
Sincehttp://www.domain.com/area/subitem/... is a page controlled by a custom Concrete5 block, normally anything after the "subitem/" would result to the content on the subitem page. But when the criteria matches in the htaccess, it should return a GET value from the field _siURL. In turn the script takes this value and queries the table to get the contents.
Does that help out?
Thank you!
The path ofhttp://www.domain.com/area/subitem/itempage/... would be translated tohttp://www.domain.com/area/subitem/?_siURL=itempage/...
Sincehttp://www.domain.com/area/subitem/... is a page controlled by a custom Concrete5 block, normally anything after the "subitem/" would result to the content on the subitem page. But when the criteria matches in the htaccess, it should return a GET value from the field _siURL. In turn the script takes this value and queries the table to get the contents.
Does that help out?
Thank you!
Sorry, still not completely clear to me...
But first, it looks like this is completely unrelated to the original forum post at the top. You may get more answers when you put your question in your own forum "discussion" post. It is also nice to keep this original post "clean".
So you want the RewriteRule to change
http://www.domain.com/area/subitem/itempage/...
('behind the scenes') into
http://www.domain.com/area/subitem/?_siURL=itempage/...
Is that correct?
And does that part work already?
Then you are talking about a custom block and GET value... that's where you lost me ;) Can you explain further (in a new topic preferably)?
But first, it looks like this is completely unrelated to the original forum post at the top. You may get more answers when you put your question in your own forum "discussion" post. It is also nice to keep this original post "clean".
So you want the RewriteRule to change
http://www.domain.com/area/subitem/itempage/...
('behind the scenes') into
http://www.domain.com/area/subitem/?_siURL=itempage/...
Is that correct?
And does that part work already?
Then you are talking about a custom block and GET value... that's where you lost me ;) Can you explain further (in a new topic preferably)?
Well, this did work prior to the Apache 2.4.17 update which is how I found this post. And I'm pretty sure its how the htaccess is interpreted by Concrete5.
What gets me is how the Apache update botched how C5 and htaccess work together.
As for the custom block in relation to htaccess and C5, I can put this block on any page and as long as I put an entry into the htaccess, I can expect $_GET['_siURL'] to provide a string value or blank. Without the htaccess entry, this process will not work as Concrete5 will be looking for these "itempages" and they do not exist in their system.
We were hoping that the issue stated on this post would be related to our issue.
What gets me is how the Apache update botched how C5 and htaccess work together.
As for the custom block in relation to htaccess and C5, I can put this block on any page and as long as I put an entry into the htaccess, I can expect $_GET['_siURL'] to provide a string value or blank. Without the htaccess entry, this process will not work as Concrete5 will be looking for these "itempages" and they do not exist in their system.
We were hoping that the issue stated on this post would be related to our issue.
Let's say that you visithttp://www.domain.com/news/ in your browser and you have pretty urls turned on (in the default C5 way).
Then, before the Apache update, the REDIRECT_URL would get the value:
/news/
After the update:
http://www.domain.com/news/
The REDIRECT_URL value being what was there before the RewriteRule was executed (if I understood correctly)
Now, C5 will try to find the page based on this value,http://www.domain.com/news/ , in the database, but in the db it is stored as /news/ so the page is not found...
I don't know if there are any other side effects to the Apache update.
Did you try turning off pretty URLs? Does that work?
Does it work if you put index.php in your URL, like so:
http://www.domain.com/index.php/area/subitem/itempage...
Then, before the Apache update, the REDIRECT_URL would get the value:
/news/
After the update:
http://www.domain.com/news/
The REDIRECT_URL value being what was there before the RewriteRule was executed (if I understood correctly)
Now, C5 will try to find the page based on this value,http://www.domain.com/news/ , in the database, but in the db it is stored as /news/ so the page is not found...
I don't know if there are any other side effects to the Apache update.
Did you try turning off pretty URLs? Does that work?
Does it work if you put index.php in your URL, like so:
http://www.domain.com/index.php/area/subitem/itempage...
Just tried to disable PrettyUrls and test using the index.php with no success. It returns a Page Not Found. Which is accurate since this page doesn't technically exist. But it shows us that the htaccess isn't being used which is the larger issue related to the Apache update.
Thank you for helping on this situation with us.
Thank you for helping on this situation with us.
On the host I use, their servers crashed and reloaded it with Apache/2.4.17. So on a site they hosted for me I had links to pages by their page title rather than their ID numbers. I changed my .htaccess code to following and kept pretty URLs enabled. I still have the issue where the internal pages will load show index.php after the .com and before any internal pages – example: site.com/index.php/services/
I've tried all of these ways (http://stackoverflow.com/questions/4365129/htaccess-remove-index-php-from-url) to remove the index.php but no luck... Anyways, here's my code in the htaccess file as a bandaid fix until this issue is resolved.
I've tried all of these ways (http://stackoverflow.com/questions/4365129/htaccess-remove-index-php-from-url) to remove the index.php but no luck... Anyways, here's my code in the htaccess file as a bandaid fix until this issue is resolved.
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME}/index.html !-f RewriteCond %{REQUEST_FILENAME}/index.php !-f RewriteRule ^(.*)$ index.php/$1 [R,L] </IfModule>
That stackoverflow link you posted... they say that it ADDS index.php instead of removing it. And I'm no htaccess specialist, but it looks like your code is actually doing that too...
So, you may want to start with the default htaccess rewrite code generated by Concrete5 when you turn on Pretty URLs and start from there.
Regarding the links on your site: when you add links through the CMS (like in a Content block) the C5 CMS does the translating from ID numbers to pretty urls.
In the database there are links with numbers (because they will always point to the right page), and they get translated to pretty urls when rendering the block on the page.
So, you may want to start with the default htaccess rewrite code generated by Concrete5 when you turn on Pretty URLs and start from there.
Regarding the links on your site: when you add links through the CMS (like in a Content block) the C5 CMS does the translating from ID numbers to pretty urls.
In the database there are links with numbers (because they will always point to the right page), and they get translated to pretty urls when rendering the block on the page.
It's a bug that's been reported with Apache. Check the thread for updates:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57785...
https://bz.apache.org/bugzilla/show_bug.cgi?id=57785...
I know ;) The link to this bug was already in my original writing at the top of this discussion ;)
But great to see that they are going to fix Apache, which is where the problem originated.
But great to see that they are going to fix Apache, which is where the problem originated.
I had the same problem.
Thanks a lot for your solution!
Thanks a lot for your solution!
Glad that it helped you!
Looks like it gets fixed in the next version of Apache. You could change your site.php back after that, but it's not really necessary.
Looks like it gets fixed in the next version of Apache. You could change your site.php back after that, but it's not really necessary.
I take it this is all fixed now in apache? [url=http://gold.com]gold[/url]
