Make WordPress Core

Opened 14 years ago

Last modified 20 months ago

#13779 reviewing defect (bug)

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

Reported by: antares19's profile antares19 Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: Future Release Priority: normal
Severity: normal Version: 2.9.2
Component: General Keywords: 2nd-opinion needs-patch
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 (19)

#1 @antares19
14 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.

#2 @wpmuguru
14 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

#3 @nacin
13 years ago

  • Keywords close added

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

#4 @dd32
13 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.

#5 @SergeyBiryukov
13 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.

#6 @SergeyBiryukov
13 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 13 years ago by SergeyBiryukov (previous) (diff)

#7 @SergeyBiryukov
11 years ago

#22706 was marked as a duplicate.

#8 @SergeyBiryukov
11 years 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.

#9 @frizzle
11 years 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.

#10 @SergeyBiryukov
11 years ago

  • Keywords needs-codex added

#11 follow-up: @kristinachilds
11 years 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 11 years ago by kristinachilds (previous) (diff)

#12 in reply to: ↑ 11 @SergeyBiryukov
11 years 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/

#13 @kristinachilds
11 years ago

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

#15 @JustinSainton
11 years ago

#24793 was marked as a duplicate.

#16 @mdawaffe
11 years 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.

#17 @DrewAPicture
9 years ago

  • Owner set to SergeyBiryukov
  • Status changed from reopened to reviewing

@SergeyBiryukov: What would you like to do with this ticket? See comment:16.

#18 @desrosj
20 months ago

  • Keywords needs-patch added
  • Milestone set to Future Release

I came across this one going through tickets missing milestones.

In my testing, this issue still exists, and is actually much worse with the block editor.

Using the steps above, if you open the block editor without logging out and logging back in, there are several endpoints that are repeatedly retried without stopping. The repeated requests are:

  • /wp/v2/block-patterns/patterns
  • /wp/v2/block-patterns/categories
  • `/wp/v2/themes
  • /wp/v2/users

index.php?rest_route=/&_fields=description,gmt_offset,home,name,site_icon,site_icon_url,site_logo,timezone_string,url&_locale=user

  • /wp/v2/templates/twentytwentytwo//single (not sure why the double slash there. Something seems missing, but this is a separate problem).

Since the root of this bug has resurfaced several years later in a different form, it's reasonable to think that it will continue to cause issues in the future and I think that it would be best to fix this issue.

I think a good way forward would be to:

  • Add a note to the Site Address field that if the setting's value is changed the user will be logged out.
  • Call wp_clear_auth_cookies() after all needed operations have completed.
  • Redirect them to the login screen with a redirect_to parameter pointing back to the general options page with a success message asking them to log back in.

This will fix the issue for the current user, but theoretically this will happen for all users actively logged in. So it's not a full fix.

#19 @desrosj
20 months ago

I've opened up Gutenberg-42400 to address the infinite retrying of failed requests.

Note: See TracTickets for help on using tickets.