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:

<?php   
defined('C5_EXECUTE') or die(_("Access Denied."));
$v = View::getInstance();
$v->setThemeByPath('/page_not_found', "nsg_v1");


I do have a page_not_found.php page in the single_pages folder and the "nsg_v1" theme folder.

Any ideas?

View Replies:
BrianJM replied on at Permalink Reply
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.
weyboat replied on at Permalink Reply
weyboat
Have you copied the page_not_found.php from the root/concrete/single_pages/ folder to the root/single_pages/ folder?
weyboat replied on at Permalink Reply
weyboat
Your code is also missing the php closing tag, try this,
<?php   
defined('C5_EXECUTE') or die(_("Access Denied."));
$v = View::getInstance();
$v->setThemeByPath('/page_not_found', "nsg_v1");
?>
BrianJM replied on at Permalink Reply
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.
BrianJM replied on at Permalink Reply
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"
BrianJM replied on at Permalink Reply
This seems to be happening in concrete\libraries\view.php at line 635:

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...
BrianJM replied on at Permalink Reply
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.
BrianJM replied on at Permalink Reply
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:
if (!$page -> isError ()) {
         return;
      }
julia replied on at Permalink Reply
julia
Brian, It looks like the developer is responding now. He's been a bit slow due to a baby on the way.
BrianJM replied on at Permalink Reply
Yes, he notified me of that. I got a little discouraged after a few weeks without reply.
elyon replied on at Permalink Reply
elyon
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.
elyon replied on at Permalink Reply
elyon
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 :)
BrianJM replied on at Permalink Reply
Yes, we have an entries block on the home page.

Thanks!
elyon replied on at Permalink Reply
elyon
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.