Custom "Page Not Found" page displays content from home page
Permalink
I just noticed this today.
When attempting to access a page that does not exist, the content that is displayed is based on the theme view.php and the inner content from the home page. The "page not found" page used to display properly.
For example, if is access a page that does not exist (http://bit.ly/JzMe00), you can see the inter content from the home page is displayed. I can access the "page_not_found" page directly though, and it displays properly (http://bit.ly/L3D20z).
In site_theme_paths.php file, I have the following:
I do have a page_not_found.php page in the single_pages folder and the "nsg_v1" theme folder.
Any ideas?
When attempting to access a page that does not exist, the content that is displayed is based on the theme view.php and the inner content from the home page. The "page not found" page used to display properly.
For example, if is access a page that does not exist (http://bit.ly/JzMe00), you can see the inter content from the home page is displayed. I can access the "page_not_found" page directly though, and it displays properly (http://bit.ly/L3D20z).
In site_theme_paths.php file, I have the following:
I do have a page_not_found.php page in the single_pages folder and the "nsg_v1" theme folder.
Any ideas?
After further investigation, any page that is not found loads the home page (content and template), not view.php. If I edit the template for the home page (home.php), the change is displayed when attempting to access a page that does not exist.
Have you copied the page_not_found.php from the root/concrete/single_pages/ folder to the root/single_pages/ folder?
Yes, thanks for the suggestion.
"I do have a page_not_found.php page in the single_pages folder and the "nsg_v1" theme folder."
Out of the box, that file does not have a php closing tag. It's actually best practice to not have it.
"I do have a page_not_found.php page in the single_pages folder and the "nsg_v1" theme folder."
Out of the box, that file does not have a php closing tag. It's actually best practice to not have it.
If I look at the raw apache logs, an invalid address receives a HTTP code 200:
31.63.121.16 - - [18/May/2012:03:56:55 -0400] "GET /page-does-not-exist/ HTTP/1.1" 200 8764 "-" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5"
31.63.121.16 - - [18/May/2012:03:56:55 -0400] "GET /page-does-not-exist/ HTTP/1.1" 200 8764 "-" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5"
This seems to be happening in concrete\libraries\view.php at line 635:
This is retuning 'home', so $view is going to render the home page later in the code. I don't fully understand what is going on here...
if ($this->controller->getRenderOverride() != '') { $view = $this->controller->getRenderOverride(); }
This is retuning 'home', so $view is going to render the home page later in the code. I don't fully understand what is going on here...
If I uninstall the "WordPress for Concrete5" addon (http://www.concrete5.org/marketplace/addons/wordpress-for-concrete5/), the problem is fixed.
Too bad I can't get any support from @elyon.
Too bad I can't get any support from @elyon.
I reported a critical bug with the add-on (noted below). I don't know how this passed Concrete5's quality control of add-ons.
-------------------------------------------
By installing your add-on and placing an entries block on the home page, all 404's are no longer directed to "page_not_found". Instead, the home page is rendered.
This occurs in the block of code that starts on line 44 of models\redirect.php:
-------------------------------------------
By installing your add-on and placing an entries block on the home page, all 404's are no longer directed to "page_not_found". Instead, the home page is rendered.
This occurs in the block of code that starts on line 44 of models\redirect.php:
if (!$page -> isError ()) { return; }
Brian, It looks like the developer is responding now. He's been a bit slow due to a baby on the way.
Yes, he notified me of that. I got a little discouraged after a few weeks without reply.
The WordPress for Concrete5 add-on intercepts pages that do not exist, in order to handle virtual URLs for your blog.
It will properly allow "Page Not Found" errors to come through, but when it finds that the path contains a WordPress Entries block, it will usually pass the data on.
Are you using a WordPress Entries block on your home page?
I am guessing that is what you have on your site, and is why the "Page Not Found" is not being displayed. I should be more aggressive about ensuring that the virtual path matches an expected pattern (like /###/###/post-name/, /###/post-name, /tags/tag-name, etc) to play more nicely.
It will properly allow "Page Not Found" errors to come through, but when it finds that the path contains a WordPress Entries block, it will usually pass the data on.
Are you using a WordPress Entries block on your home page?
I am guessing that is what you have on your site, and is why the "Page Not Found" is not being displayed. I should be more aggressive about ensuring that the virtual path matches an expected pattern (like /###/###/post-name/, /###/post-name, /tags/tag-name, etc) to play more nicely.
I'll keep you up-to-date on the support request you have open. I think we'll be able to have it resolved soon :)
Yes, we have an entries block on the home page.
Thanks!
Thanks!
I've updated the add-on to version 1.5.2, which is more strict in how paths are handled.
Valid patterns, like "www.mysite.com/tag/my-tag" will be handled, but unknown paths like "www.mysite.com/alsdfjldskfj" will return "Page Not Found" if it is not an existing page in Concrete.
Valid patterns, like "www.mysite.com/tag/my-tag" will be handled, but unknown paths like "www.mysite.com/alsdfjldskfj" will return "Page Not Found" if it is not an existing page in Concrete.
