Jump to content

Mysterious 404 when viewing Unpublished pages


thijs
 Share

Recommended Posts

Hi all,

I’ve been experiencing quite a mysterious issue; I’m running PW 2.4, and the following occurs; the client is not able to view unpublished pages but get’s a 404 served instead. It’s not a role/permission issue I think, as it happened for me (admin) as well. But it’s not consistent. When I log into my local install of the website, it does seem to work, and here comes the crazy; it then also works on the production site. 

What else; the page template renders it’s parent (it’s a backbone js app), but I’m not sure if this matters, thought I should mention it anyway. Any clues? I’m not sure how to debug this one.

All the best,

T

– I did try to clear all sessions, and none of the websites pages are cached at the moment.

Link to comment
Share on other sites

So, does the client have to log in in order to view the page? If a page is unpublished, or its template can only be viewed/edited by a certain role, than an unauthorized user would get the 404 page. Unpublished pages won't remain hidden from the superuser/admin, so it makes sense that if you log in you can view it.  Ensure that the client has the appropriate template permissions set.

Also, I had a similar situation when I was testing the page flags in the template file. Setting/unsetting the hidden and unpublished flags from the API resulted in the appropriate flags being set, but they would not reflect in the admin view for some reason. Selecting the unpublished box, saving, and then unselecting and saving it fixed my mysterious 404. 

Link to comment
Share on other sites

Hey, thanks for your reply. The template is public (guests can view it). The template permissions are set as follows:

role-permissions.png

template-access.png

Publishing pages and then unpublishing them (from the cms, not the API) sometimes seems to do the trick. But it’s hard to pin it down. Thanks for your input though, I’ll give it another go.


And is there a way to debug the process that happens before the actual 404 is thrown? May shed some light on the issue

Link to comment
Share on other sites

Well, there was an error in my template code. That’s resolved now, but the behaviour still occurs, yet it is not consistent, sometimes it throws 404s, sometimes it just doesnt. I’m considering implementing my own published/unpublished mechanism (simple checkbox) to work around this, as it’s quite inconvenient...

Link to comment
Share on other sites

What else; the page template renders it’s parent (it’s a backbone js app), but I’m not sure if this matters, thought I should mention it anyway. Any clues? I’m not sure how to debug this one.

That statement stood out, to me, as something you may want to investigate further (Backbone.js app code structure/security/URL results).  I mean you need to find out how the Backbone.js app could possibly be affecting your results.

Reason:  The behavior that you are mentioning is not a known basic ProcessWire behavior.  Without eliminating the possible effect(s) the Backbone.js code has on your site structure, you will be chasing ghosts.  Maybe someone else who is qualified on Backbone.js issues can rule out what I'm talking about.

Another way to rule out any effect Backbone.js is having is if you are able to have a test ProcessWire website on the same server (local or hosting), using the same version of ProcessWire and PHP, without any Backbone.js code involved, I wonder what the result would be regarding published/unpublished pages generating mysterious 404s?

I hope you figure it out, as it is indeed interesting and unusual behavior for a ProcessWire website.

Best Regards,

Charles

  • Like 3
Link to comment
Share on other sites

  • 3 months later...

I've got the same issue. The problem was somehow in the subdomain.

When logged on to the admin panel on "www.domain.com" and try to view a unpublished page on the normal domain "www.domain.com" I got the 404. When viewing the same page on "domain.com" and logged on to "domain.com" I could view the page perfectly. This is very strange behavior. 

Something in the authentication process and assigning permissions isn't going correctly.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...