WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 9 months ago

#13779 reopened defect (bug)

Preview doesn’t work - WP installed in its own directory

Reported by: antares19 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 2.9.2
Component: General Keywords: 2nd-opinion
Focuses: Cc:

Description

  1. Wordpress is installed on /wp/ subdirectory.
  1. Then it was set up to be visible from the site root according to http://codex.wordpress.org/Giving_WordPress_Its_Own_Directory
  1. Site works fine
  1. [BUG] Preview for posts & pages isn’t working.

When I press preview it goes to url like:
http://example.com/?preview=true&preview_id=235&preview_nonce=aa28f04
and says "You do not have permission to preview drafts.".

  1. If I type subdirectory name “/wp/” in that url by hands, it shows correct preview: http://example.com/wp/?preview=true&preview_id=235&preview_nonce=aa28f04
  1. The situation is getting worse if i'm using permalinks. In that case - there is nothing i can do to see preview.

ps: I’ve tested that on clean install.

Change History (16)

comment:1 antares194 years ago

Just found walkaround on the forums. This problem is related to this bug:
http://core.trac.wordpress.org/ticket/12081

So i've changed AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY in wp-config.php and the bug is gone.

Anyway that was strange unexpected behavior, i think it should be fixed someway.

ps: Thanks to SergeyBiryukov who gave me this solution.

comment:2 wpmuguru4 years ago

  • Summary changed from Preview don’t work - WP installed in its own directory to Preview doesn’t work - WP installed in its own directory

comment:3 nacin3 years ago

  • Keywords close added

Is this still an issue? If the issue was #12081, I don't think there's a bug here.

comment:4 dd323 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Closing as worksforme, It appears to work fine for me. Feel free to re-open with specific details if this is still an issue.

comment:5 SergeyBiryukov3 years ago

I was able to reproduce this on a localized install of 3.1-RC1.

After several hours of debugging wp_create_nonce(), wp_verify_nonce() and wp_salt(), I've noticed that somehow I was logged out on http://example.com/, but logged in on http://example.com/wp/. After I logged in again through the Meta widget on http://example.com/, the bug was gone.

According to wp_set_auth_cookie(), both cookies are set simultaneously, so I'm not sure how to reproduce it from scratch. Therefore I've decided not to reopen the ticket.

comment:6 SergeyBiryukov3 years ago

OK, now I'm able to reproduce it from scratch.

The only situation when home cookie is set and siteurl cookie is not, is right after
you make WordPress visible from the site root (as described by antares19 in step 2). Until you log out and log in again, you won't be able to preview posts and pages.

So I guess it's a misconception, but not actually a bug.

Last edited 3 years ago by SergeyBiryukov (previous) (diff)

comment:7 SergeyBiryukov17 months ago

#22706 was marked as a duplicate.

comment:8 SergeyBiryukov17 months ago

  • Keywords needs-patch added; close removed
  • Milestone set to Awaiting Review
  • Resolution worksforme deleted
  • Status changed from closed to reopened

So I guess it's a misconception, but not actually a bug.

We should still try to fix it.

comment:9 frizzle17 months ago

An easy fix would be to change the Codex: http://codex.wordpress.org/Giving_WordPress_Its_Own_Directory

Just add something like: "If you find that this makes it impossible to preview posts, simply log out and log back in again to reset your site cookie."

It's a simple fix once you know it but it was completely un-obvious to me what the problem was, and the actual problem is maddening.

comment:10 SergeyBiryukov17 months ago

  • Keywords needs-codex added

comment:11 follow-up: kristinachilds17 months ago

  • Keywords 2nd-opinion needs-testing added; needs-patch needs-codex removed

I still have this issue. Our setup is a bit convoluted since we are slowly migrating parts of our site to wordpress, so index.html is still live. I'm guessing the instructions for giving wordpress it's own directory only works in certain situations? I've followed all of these steps (even tryed to rewrite to /wp/index.php instead of /index.php just to rule it out) but it still wants to forward all previews to the site root index.html.

Since we are using pretty permalinks I can't edit the preview button target to anything that works or I would have done that long ago.

Last edited 17 months ago by kristinachilds (previous) (diff)

comment:12 in reply to: ↑ 11 SergeyBiryukov17 months ago

  • Keywords needs-patch needs-codex added; 2nd-opinion needs-testing removed

Replying to kristinachilds:

I still have this issue. Our setup is a bit convoluted since we are slowly migrating parts of our site to wordpress, so index.html is still live.

Your issue may sound similar, but the cause appears to be different in your case.

Please try the support forums for troubleshooting: http://wordpress.org/support/

comment:13 kristinachilds17 months ago

Thanks. For anyone else coming across this problem, here's the solution http://wordpress.stackexchange.com/q/75099/20954

comment:15 JustinSainton9 months ago

#24793 was marked as a duplicate.

comment:16 mdawaffe9 months ago

  • Keywords 2nd-opinion added; needs-patch needs-codex removed

I think the specific issue of not being able to preview themes immediately after changing WordPress's home option is fixed as of the new Theme Customizer.

Options:

  1. Close as fixed.
  2. Call wp_clear_auth_cookie() and wp_set_auth_cookie() whenever the home option changes. That would fix this issue at its root and probably fix other similar annoyances.

Option 1 is easy :)

Option 2 is hard because we know what the old values of COOKIEPATH, SITECOOKIEPATH, etc. are, we don't what the new ones should be. We can calculate them from the new values of the home, etc. options, but a site could have any of these constants hardcoded, in which case calculating them from the options is probably wrong.

Note: See TracTickets for help on using tickets.