WordPress.org

1. nighthwk1
   Member
   Posted 4 months ago #

   I already know how to work around it, but why is the URL stored in the database at all? Not once, but at least twice! (wp_options.siteurl and wp_options.home)

   I understand some users might rely on this to use their site in a subdirectory, but I'd guess they are the "fringe" users, and the default behavior should not cater to them.

   Many users are frustrated and confused by this, and it's a pain for administrators of multiple WP sites.

   If I need to submit a patch, I'll make one, but I don't want to waste my time on it if it's just going to be brushed off because a core developer likes this irritating quirk.

2. ClaytonJames
   Member
   Posted 4 months ago #

   I already know how to work around it, but why is the URL stored in the database at all

   Just out of curiosity, what is the reason for working around it, and why shouldn't it be stored in the database?

   Many users are frustrated and confused by this, and it's a pain for administrators of multiple WP sites.

   This is the first time I've ever seen it mentioned (but that doesn't mean much). I'm curious as to why this is an issue and what problems it causes?

3. figaro
   Member
   Posted 4 months ago #

   I'm curious as to why this is an issue and what problems it causes?

   The problem for the less tech savvy, is people changing it and locking themselves out of their site. I'm not convinced it should be removed, but, just from my own observations, people sure do seem to lock themselves out with those settings an awful lot. Would it be better to have these in the wp-config.php file? Maybe...the web admin could still change them and it may prevent a lot of frustration for the "average" user.

   Of course, anyone who hosts multiple WP sites and has this problem, could put them in wp-config and not have the problem, so it's an easy fix for the host of multiple sites.

4. ClaytonJames
   Member
   Posted 4 months ago #

   The problem for the less tech savvy, is people changing it and locking themselves out of their site

   Ahh... I think I see where he's coming from now. I guess I never considered it an issue because database access and repair for that situation is so easy.

   If I need to submit a patch, I'll make one, but I don't want to waste my time on it if it's just going to be brushed off because a core developer likes this irritating quirk.

   That sort of gave me the impression that the issue may be related to something substantially more than just changing blog URL's without understanding the procedure (what you're doing) beforehand. That happens all the time. Seems like a non-issue (to me anyhow) if that's all it's about.

   Thanks figaro!

5. figaro
   Member
   Posted 4 months ago #

   Seems like a non-issue of that's all it's about.

   Agreed...maybe the OP will clarify if there is more to it that what we're seeing.

6. nighthwk1
   Member
   Posted 4 months ago #

   I'm curious as to why this is an issue and what problems it causes?

   The biggest problem I have with it is that I cannot just duplicate the database when switching servers (new domain name, setting up development/staging servers, or working on the site on my local machine)

   The workaround I've been using is keeping a SQL script for each server I use (to update the siteurl value), and run it after each time I import data.

   This could probably be all fixed if bloginfo('siteurl') didn't look at the DB, and instead returned:

   $_SERVER['DOCUMENT_ROOT'] . $optional_subdirectory;

7. nighthwk1
   Member
   Posted 4 months ago #

   Of course this isn't a super-important bug, it's just something that would make working on multiple large Wordpress sites much more pleasant, and I don't think changing it would negatively impact anyone.

   There's also the side effect of making life easier for those individuals that lock themselves out of their site.

8. ClaytonJames
   Member
   Posted 4 months ago #

   Excellent answer. I can see where that could be a hassle. The current process is of course, outlined here;

   http://codex.wordpress.org/Moving_WordPress

   But you make it sound a heck of a lot simpler. Might be worth the effort to suggest for future consideration...

   http://codex.wordpress.org/Development_Planning#Process_For_Feature_Requests

   Thanks!

9. wien1900
   Member
   Posted 4 months ago #

   ClatonJames, I'm a new WP user (and reformed PHP/MySQL coder), trying to rescue a client's site that got hacked. Copy the DB and PHP files, install on a different server. Comes up, but all links broken, pointing at original server.

   Can't login, it redirects to the original server.

   Looked for some hardwired URL in the PHP files, where I'd expect. Nope. Searched thru PHP files, found lots of use of 'siteurl' and 'home', yet couldn't find them defined anywhere.

   Finally, now that I knew the variables' names, googled and found they're set in the DB. Ug. Used an "UPDATE wp_options ..." SQL comand to fix it. But wasted over an hour to do this. Very counter-intuitive.

   Seems links should be relative, and if you have to hard code them, make it easier and more obvious, like in the same file where you give it your DB connection parameters. That's where I'd look anyway.

10. wien1900
    Member
    Posted 4 months ago #

    followup:

    I guess I just can't see any advantage to putting such a critical parameter in the DB. It makes changing this when moving a site a lot more painful than it should. Even with the PHP functions which are designed to do this.

Reply

You must log in to post.