• Has there been a good argument as to why WordPress includes the full TLD domain in the database?

    Specifically the ‘posts’ table in the ‘guid’ column, WordPress also stores it in both the site_url option and home_url. Shouldn’t it just store “/” or “/blog” in the home_url field? Wouldn’t it be much DRYer and much more efficient to just store the TLD once and then have everything else build off of that?

    For instance if I update my “WordPress address (URL)” within the settings section it doesn’t update all of the post records with the new url, it keeps it at the old one. This is only really a problem with media uploads at the moment since posts don’t really reference this value at all at the moment.

    Instead of this:
    http://localhost/?p=28
    Why not this?
    /?p=28

    It’s just kind of annoying when you switch a site from dev.mysite.com to mysite.com and have to update things in a few places when I think it would make a lot more sense to build off of the TLD once.

    If I am missing something or someone from WordPress core can jump in that would be great, just wanted to know the thought process behind it.

Viewing 7 replies - 1 through 7 (of 7 total)
  • Not much of an explanation but maybe this will help:

    https://core.trac.wordpress.org/ticket/10857

    Also use this plugin to fix the urls in your database after you move to a new ‘domain’: http://wordpress.org/extend/plugins/search-and-replace/

    Thread Starter nickhammond

    (@nickhammond)

    I know how to change/update it, just wondering why it’s not something that wasn’t setup properly in core and becomes kind of a pain when switching. Seems like everything should be inherited from the one root setting.

    Nick this is a great question. I set up a wordpress blog for my wife that she accesses both at home and at work. I was disapointed to find that accessing wordpress over LAN requires extra configuration on the client side due to the way WP handles it’s URLs as you mentioned. I have found a solution for accessing over LAN but this is a real pain and not at all practical. I’ve done a great deal of digging and I’ve found that for the most part the problem is ignored or as MichaelH did here a totally useless answer to a different question is given. I would really like to know why the wordpress team has made this decision. I’m sure they have their reasons but why is beyond me. I’ve used Joomla, Drupal, Tikiwiki, Mediawiki and several other CMSes and none have given me as much trouble as wordpress. WP team I just want an answer as to why you’ve set up your CMS in this way? FYI I use tikiwiki for my own website/blog and it works great and is easy to set up but isn’t nearly as good looking as wordpress.

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    problem is ignored or as MichaelH did here a totally useless answer to a different question is given.

    Wow, how harsh. You ought to request a refund for your WordPress.ORG support account. MichaelH’s answers are usually based on solving a tangible problem; whinge-ing doesn’t help.

    Now for a not totally useless answer: @nickhammond or even @zafthan I suspect that it’s that way for historical reasons, meaning no one felt the need to change it. WordPress development is usually driven by someone scratching an itch so cool features get added i.e. oEmbed (yay Viper007bond)or media uploads but the more mundane issues don’t. This one has not bugged enough people (apparently) so it stays untouched.

    When you look at the wp-hackers list, all I found was one e-mail on the topic.

    If you can fix it yourself via a patch then you can submit it to trac. If you can’t then consider joining the wp-hackers list and make a feature request there.

    jdembowski, I apologize for my harsh tone, uncalled for. Actually while condescending your answer is exactly what I wanted, thanks. In addition to trying to be more polite in the future I will follow your advice.

    You ought to request a refund for your WordPress.ORG support account

    Had to laugh jdembowski, because as you can guess, there are no refunds! 😉

    trrrent

    (@trrrent)

    I would also like to point out that the reliance on the full hostname complicates multi-server and multi-database environments. I’ve been toying with a clustered environment with a master-master mysql setup and SamFS for media library use.

    So far it works, but is an order of magnitude more complicated than your average blogger would like. It would simplify things if the server’s hostname weren’t a crucial component of the data.

    All that said, the other features of the platform far outshine some of its weaknesses.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Discussion: Why does WordPress store the TLD/absolute URL in the database?’ is closed to new replies.