WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 20 months ago

#16386 closed defect (bug) (worksforme)

Issues with broken wp-admin urls

Reported by: segui Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Multisite Keywords: reporter-feedback
Focuses: Cc:

Description (last modified by scribu)

Hi,

i've just finish a brand new distributed setup and i ran into 2 few issues.

A word about the setup:
2 servers involved both running on debian stable. Wordpress version is 3.0.4 +dfsg-1~bpo50+1.
The first one handeling client request and, through apache's rewriting and proxypass revers rules, ask another server and eventually get datas to send back to client.

Urls invoked by client ar on that form http://www.blah.com/~user/blog to be rewritten to http://user.blah.blah.com/

The first issue was with the settings side where url were not correctly rewritten due to, as far as it seems, a bug code.
The url called after trying to submit changes in the settings panel is not concatenated tu the base url site, ie:

http://www.blah.com/~user/blog/wp-admin/options-general.php

leads to

http://www.blah.com/wp-admin/options-general.php?updated=true

instead of

http://www.blah.com/~user/blog/wp-admin/options-general.php?updated=true.

The second issue was on the dashboard part. Links, for example to configure, widgets are broken on the same way described above.

Here is a patch which fix this issue, just by concatenating site_url() in order to have a correct complete path just like everywhere else in the code (as far as i saw).... Is this relevant ?

Thanks,
Christophe

Attachments (1)

path.patch (1.4 KB) - added by segui 3 years ago.

Download all attachments as: .zip

Change History (16)

segui3 years ago

comment:1 follow-ups: scribu3 years ago

  • Keywords reporter-feedback added

There are a lot more places where wp_get_referer() is used.

I think your patch handles the symptomps, instead of the problem.

Also, if this bug is to be reproduced, we need to know more about your configuration, such as:

  • multisite or not
  • siteurl and home option values

comment:2 in reply to: ↑ 1 ; follow-up: segui3 years ago

Hi,

wp_get_refer() call is one of the two targets of my patch.

It's a multisite configuration as i described before.

Here are the configuration values:

siteurl : http://www.math.univ-toulouse.fr/~user/blog
home: http://www.math.univ-toulouse.fr/~user/blog

the frontend allows wordpress to be accessed through these url.
Real wordpress server urls are : http://user.math.ups-tlse.fr/

My patch is against the onlyt two calls i found which were not referring the complete path to the next page ... as far as i saw

Replying to scribu:

There are a lot more places where wp_get_referer() is used.

I think your patch handles the symptomps, instead of the problem.

Also, if this bug is to be reproduced, we need to know more about your configuration, such as:

  • multisite or not
  • siteurl and home option values

comment:3 in reply to: ↑ 2 segui3 years ago

I forgot to say that the wordpress server and the frontend are not the same hosts.Rewrite is done through some apache rules :

on the frontend :

RewriteRule /~([/]+)/blog$ /~$1/blog/ [R]

RewriteCond /public_html/$1 -d

RewriteRule /~([/]+)/blog/(.*) http://$1.math.ups-tlse.fr/$2 [P]

ProxyPassReverse /~([/]+)/blog/ http://$1.math.ups-tlse.fr/

This bug is highly reproductable ...

Replying to segui:

Hi,

wp_get_refer() call is one of the two targets of my patch.

It's a multisite configuration as i described before.

Here are the configuration values:

siteurl : http://www.math.univ-toulouse.fr/~user/blog
home: http://www.math.univ-toulouse.fr/~user/blog

the frontend allows wordpress to be accessed through these url.
Real wordpress server urls are : http://user.math.ups-tlse.fr/

My patch is against the onlyt two calls i found which were not referring the complete path to the next page ... as far as i saw

Replying to scribu:

There are a lot more places where wp_get_referer() is used.

I think your patch handles the symptomps, instead of the problem.

Also, if this bug is to be reproduced, we need to know more about your configuration, such as:

  • multisite or not
  • siteurl and home option values
Last edited 3 years ago by segui (previous) (diff)

comment:4 in reply to: ↑ 1 segui3 years ago

Hi,

You were right, this bugs appear also while trying to navigate around the available widget ... many calls to wp_get_referer() may be buggy...

Do you wish me to report all the buggy call i'm finding ?

Replying to scribu:

There are a lot more places where wp_get_referer() is used.

I think your patch handles the symptomps, instead of the problem.

Also, if this bug is to be reproduced, we need to know more about your configuration, such as:

  • multisite or not
  • siteurl and home option values

comment:5 follow-up: scribu3 years ago

  • Description modified (diff)

Thanks for the info. The problem is that the front-end is set up as a subdomain install, while the backend is set up as a subdirectory install.

What is the value of the SUBDOMAIN_INSTALL (previously VHOST) constant?

comment:6 scribu3 years ago

  • Component changed from General to Multisite

comment:7 in reply to: ↑ 5 ; follow-up: segui3 years ago

i didn't defined this SUBDOMAIN_INSTALL at all ... am i missing something huge ?

Replying to scribu:

Thanks for the info. The problem is that the front-end is set up as a subdomain install, while the backend is set up as a subdirectory install.

What is the value of the SUBDOMAIN_INSTALL (previously VHOST) constant?

comment:8 in reply to: ↑ 7 ; follow-ups: scribu3 years ago

If you didn't set it, it's automatically set to FALSE.

comment:9 in reply to: ↑ 8 segui3 years ago

yes, i saw tht ... but i thought you meant it might be the problem with my setup ...

As you say, since i haven't defined this value, it's FALSE

Replying to scribu:

If you didn't set it, it's automatically set to FALSE.

comment:10 in reply to: ↑ 8 segui3 years ago

Is that my istake ? should i have set this to yes ? in conjunction with something else ?

Thanks

Replying to scribu:

If you didn't set it, it's automatically set to FALSE.

comment:11 follow-up: scribu3 years ago

You can try setting it to TRUE, but I don't think that will solve the problem. As I said, you have one type of URLs on the front-end and another type on the back-end. WP doesn't know how to handle that.

comment:12 scribu3 years ago

Also, are you sure you don't have the VHOST constant set either?

comment:13 in reply to: ↑ 11 ; follow-up: segui3 years ago

No VHOST defined.

Tell me if i'm wrong, you're telling that i must configure frontend & backend either as a subdomain install or a subdirectory install but it can't be mixed ... right ?

What is the prefered way ? Is there any tuto describing ?

Replying to scribu:

You can try setting it to TRUE, but I don't think that will solve the problem. As I said, you have one type of URLs on the front-end and another type on the back-end. WP doesn't know how to handle that.

comment:14 in reply to: ↑ 13 segui3 years ago

FYI i'm using debian distros and i've followed the mulstisite instructions given with the package .. The default wp-config.php searches for a (mysql) configuration filename based
on the blog's host

Replying to segui:

No VHOST defined.

Tell me if i'm wrong, you're telling that i must configure frontend & backend either as a subdomain install or a subdirectory install but it can't be mixed ... right ?

What is the prefered way ? Is there any tuto describing ?

Replying to scribu:

You can try setting it to TRUE, but I don't think that will solve the problem. As I said, you have one type of URLs on the front-end and another type on the back-end. WP doesn't know how to handle that.

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

comment:15 nacin20 months ago

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

Appears to be a support issue.

Note: See TracTickets for help on using tickets.