WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#10957 closed defect (bug) (wontfix)

Change to defines WP_SITEURL and WP_HOME & Settings

Reported by: Frumph Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

Logic bug.

While repairing several sites who have installations in sub-directories, it's often times because they change the siteurl and blogurl inside the dashboard - settings - general.

To fix them quick and easy I assumed I could just set the

define('WP_HOME', 'http://example.com/wordpress'); 
define('WP_SITEURL', 'http://example.com/wordpress');

defines in the wp-config.php, but when I do that, the dashboard - settings - general options for changing the addresses properly in the database are grayed out.

This is a bug imo because it's not safeguarding anything, the purpose for the overrides is to fix situations, but not having those available to be edited is a hindrance.

Attachments (1)

options-general.php.2.diff (2.4 KB) - added by scribu 6 years ago.
Remove the 2 options from options-general.php

Download all attachments as: .zip

Change History (30)

comment:1 @strider726 years ago

If we leave the fields editable in the Admin, people will change that value and then not understand why it isn't doing anything (not realizing that it's being overwritten by the constants).

If you're running WordPress on your own hosting, surely you have access to the database for the sake of repairs.

comment:2 @azaozz6 years ago

Perhaps instead of disabling them we could add something like "Currently overridden in wp-config". However both are still changeable from wp-admin/options.php.

Better to fix the cause for this: "WordPress address" (siteurl) shouldn't be changeable from Settings->General at all as it cannot be set safely there. Most users would just break their blogs if they change it.

It is set at install and only needs changing when WordPress is moved to another domain or (sub)directory. This happens very rarely and there are other (better?) ways to set siteurl.

comment:3 follow-up: @scribu6 years ago

+1 for removing the two settings from Settings -> General. They can be left in options.php, which is used by devs.

@scribu6 years ago

Remove the 2 options from options-general.php

comment:4 @scribu6 years ago

  • Keywords has-patch added
  • Milestone changed from Unassigned to 2.9

comment:5 in reply to: ↑ 3 ; follow-up: @azaozz6 years ago

Replying to scribu:

+1 for removing the two settings from Settings -> General.

Perhaps we can keep "Blog address" (home). It can still be used to specify another home location and won't break the admin if set incorrectly (can be undone).

comment:6 in reply to: ↑ 5 @Denis-de-Bernardy6 years ago

Replying to azaozz:

Perhaps we can keep "Blog address" (home). It can still be used to specify another home location and won't break the admin if set incorrectly (can be undone).

in this case, we need to make sure the www. pref is passed on to the site_url. else we're bound to get massive bugs (e.g. #9873)

comment:7 follow-up: @hakre6 years ago

This report has been made in error. This is not a bug, it's the documented behaviour:

http://codex.wordpress.org/Editing_wp-config.php#WordPress_address_.28URL.29

According to the documentation, the fields are greyed out. So everthing is OK. If you want to improve this, add a note why those are greyed out and place a link to the documentation.

Strongly suggest to resolve as invalid. If anybody feels now (because of this defenetly bogus report) that wordpress needs a new feature, please open an additional ticket for a milestone in the future.

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

  • Resolution set to invalid
  • Status changed from new to closed
  • Summary changed from Change to defines WP_SITEURL and WP_HOME & Settings to Remove siteurl and home settings from options-general.php

Replying to hakre:

This report has been made in error. This is not a bug, it's the documented behaviour:

http://codex.wordpress.org/Editing_wp-config.php#WordPress_address_.28URL.29

According to the documentation, the fields are greyed out. So everthing is OK. If you want to improve this, add a note why those are greyed out and place a link to the documentation.

Strongly suggest to resolve as invalid. If anybody feels now (because of this defenetly bogus report) that wordpress needs a new feature, please open an additional ticket for a milestone in the future.

Yeah, I think we've hijacked the ticket.

comment:9 @scribu6 years ago

  • Summary changed from Remove siteurl and home settings from options-general.php to Change to defines WP_SITEURL and WP_HOME & Settings

Sorry, got ahead of myself

comment:10 @scribu6 years ago

  • Keywords has-patch removed
  • Milestone 2.9 deleted

comment:11 in reply to: ↑ 8 @scribu6 years ago

See #10970.

comment:12 follow-up: @Frumph5 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Being as it may, if someone needs their url changed because of an accident in changing it via the settings -> general, having it grayed out is wrong.

Using the defines to set the proper url then giving the ability to modify it in the settings-general to fix the mistake is proper, even though you they can hit the options.php file with circumvents even having them grayed out to begin with.

No this is not a bogus report.

comment:13 @MichaelH5 years ago

If you set the WP_SITEURL and WP_HOME in wp-config.php then you can't set them via Settings->General.

If you want to allow users to change those values via Settings->General, don't put those definitions in the wp-config.php file.

comment:14 @Frumph5 years ago

MAYBE my english is a little rusty seeing how I was born speaking it, but i'm saying that they should NOT be grayed out so they can fix a wrongly placed URL. To fix it you place the defines in the wp-config.php THEN go to the settings-general to adjust it in the database. SINCE they are GRAY'd out and uneditable an end-user CANNOT fix it and will have to have those defines permanently unless shown how to edit it with the options.php.

DO you WANT people to know how to edit in the options.php which circumvents the grayed out fields anyways?

For the love of pete.

comment:15 @wpmuguru5 years ago

Let's try this:

The admin mistakenly changes the home option or it's changed by an errant plugin. Currently, the only way to fix that is find the home record in the options table.

However, the admin can gain access to the admin area by defining the WP_HOME in their wp-config.php. As it stands now, they cannot fix the setting via the admin area because it is grey out. That's what Frumph is proposing to change so that you don't have to edit the database to fix it.

comment:16 @strider725 years ago

I agree with Frumph. The fields should be editable, but if the constants are set there MUST be a message saying "These are currently being overridden by settings in the wp-config.php file."

comment:17 in reply to: ↑ 8 @hakre5 years ago

Replying to scribu:

Yeah, I think we've hijacked the ticket.

You are just replying to a bogus ticket description before checking the documentation I assume.

comment:18 in reply to: ↑ 12 ; follow-up: @hakre5 years ago

Replying to Frumph:

Being as it may, if someone needs their url changed because of an accident in changing it via the settings -> general, having it grayed out is wrong.

If they would have changed it via settings -> general it will never be grayed out. so this is a bogus argument.

Using the defines to set the proper url then giving the ability to modify it in the settings-general to fix the mistake is proper, even though you they can hit the options.php file with circumvents even having them grayed out to begin with.

so for what are you argumenting here now? that it's okay to have it greyed out because the input element can not be used any longer to edit something?

No this is not a bogus report.

To clearify things I think it's adviseable to define what the "mistake" is. when you write about "mistake", please provide a step-by-step description of what the user did and where you think user made a mistake. Was the mistake to use constants to configure the blog? Was the mistake to not read the documentation why the input elements were greyed out? Please be specific.

It looks to me that a third person was not aware of the fact that constants were used to configure a certain blog. Then that person was quick at hand to open a ticket before consulting the documentation. RTFM.

comment:19 @Frumph5 years ago

Hakre:
Are you .. drunk? If they changed it via the settings -> general and it was wrong information and it locked them out from going to their site, the option to fix it with defines in the wp-config.php is the way to do it.

The mistake its not an editable field.

And it looks to me that your not reading. RTFT

THE CONSTANTS WERE USED TO FIX THEIR Mess. Then trying to permanently repair it having them go to the settings -> general to put the correct information there is impossible.

Getting someone your working with who has no idea what phpmyadmin is and explaining to them no, its not software you install on your machine is wrong. Some hosting doesn't even provide for this.

Seriously do you actually read what is written before you make assumptions?

comment:20 @Frumph5 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

I'm done talking to you about a concern with methodology.

comment:21 in reply to: ↑ 18 @Frumph5 years ago

Replying to hakre:

To clearify things I think it's adviseable to define what the "mistake" is. when you write about "mistake", please provide a step-by-step description of what the user did and where you think user made a mistake. Was the mistake to use constants to configure the blog? Was the mistake to not read the documentation why the input elements were greyed out? Please be specific.

"While repairing several sites who have installations in sub-directories, it's often times because they change the siteurl and blogurl inside the dashboard - settings - general."

IN THE TICKET. Gee, couldn't really get more clearer then that.

comment:22 @strider725 years ago

Frumph -- You are correct, and multiple people completely missed the point of what you were saying.

However it can also be fixed (I believe) by going to options.php from the admin and changing it there. (options.php isn't on the menu, it's a hidden page for devs only -- just type it in, e.g. "/wp-admin/options.php")

If it's grayed out there that's definitely a bug!

comment:23 follow-up: @sivel5 years ago

The proper way to deal with fixing the location of your WP install is to use the RELOCATE constant, and then navigate to wp-admin.

See http://core.trac.wordpress.org/browser/tags/2.8.5/wp-login.php#L292

comment:24 @westi5 years ago

As sivel says above the correct solution to use when relocating your blog is to define RELOCATE in wp-config.php

WP_HOME and WP_SITEURL are designed to override the database content and allow you to for example use a site database in a local test install without modifying it.

comment:25 in reply to: ↑ 23 @Frumph5 years ago

Replying to sivel:

The proper way to deal with fixing the location of your WP install is to use the RELOCATE constant, and then navigate to wp-admin.

See http://core.trac.wordpress.org/browser/tags/2.8.5/wp-login.php#L292

That's great Sivel thank you!

@Westi Thank you as well!

The only documentation I found for those fixes to help clients was the defines, I will look up the RELOCATE today, thanks very very much.

comment:26 @Frumph5 years ago

Take note: Usually I can't do the changes myself so I have to tell people via emails / twitter / WCP Chat how to do it and these people are 90% of the time not tech savvy enough to even know what a database is. The easier the better for them is what why I was using the defines, but RELOCATE looks like it does the same effect, thanks again!

comment:27 @hakre5 years ago

Then this is solved I guess, thanks for providing additional information, I'll be more kind the next time. Sorry for that. As describben, the scenario looks this way now in my eyes:

1.) The Blog was initially misconfigured by a User

2.) That User alerts Support (optional)

3.) Someone does add a second misconfiguration by using wrong constants.

This ends up in a blog with the important siteurl option value misconfigured in two diffrent places. I can fully understand that this creates many questions when looking from above to the blog. To clarify such situations, there is documentation. And this is the documented behaviour. Reading the docs does acutally help to deal with this misconfiguration.

As sivel already pointed out, the RELOCATE constant should be used instead. I have updated the codex page and extended the note.

comment:28 @scribu5 years ago

  • Milestone set to 3.0
  • Resolution wontfix deleted
  • Status changed from closed to reopened

The fact that's it's documented behaviour is all fine and dandy. But the fact that a user can shoot himself in the foot all from the confort of the admin can't be overlooked. A prime example.

comment:29 @scribu5 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

Forgot the other ticket I opened. Going to add a patch there.

Note: See TracTickets for help on using tickets.