Change to defines WP_SITEURL and WP_HOME & Settings

[Frumph]

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.

[strider72]

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.

[azaozz]

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.

[scribu]

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

[scribu]

Remove the 2 options from options-general.php

[azaozz]

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).

[Denis-de-Bernardy]

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)

[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.

[scribu]

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.

[scribu]

Sorry, got ahead of myself

[scribu]

See #10970.

[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.

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.

[MichaelH]

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.

[Frumph]

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.

[wpmuguru]

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.

[strider72]

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."

[hakre]

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.

[hakre]

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.

[Frumph]

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?

[Frumph]

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

[Frumph]

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.

[strider72]

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!

[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

[westi]

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.

[Frumph]

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.

[Frumph]

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!

[hakre]

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.

[scribu]

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.

[scribu]

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