[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

Dion Hulse (dd32) wordpress at dd32.id.au
Mon Oct 31 03:51:48 UTC 2011


 On 31 October 2011 01:41, Mike Schinkel <mikeschinkel at newclarity.net>wrote:

> Let's use this as a starting point. I know Mark Jaquith has suggested this
> approach in the past. I think this can address all use-cases.  What does
> the hacker community think about baking this type of logic into
> /wp-load.php?  What about optionally loading a domain-specific file, if it
> exists, before loading wp-config.php?
>
> For example, if a browser requests http://example.com/ then /wp-load.php
> might look for ABSPATH . '/example.com-config.php' or  ABSPATH .
> '/../example.com-config.php' and load it if it exists?  It won't solve this
> root relative issue, but it will be a start?  (If this is not controversial
> I can add a trac ticket...)
>

At first glance that sounds good and all, but do you really want to be
calling your files wp-development.funclientsite.com-config.php ? What about
when paths are thrown into the mix?
wp-config.php is a php include line any other, it doesn't *have* to contain
any definitions at all, it can simply be a switch/if and include the
specific file for that instance. That's exactly what I've seen some
large-scale installations use, it's one of the things that everyone can do
themselves anyway they please, as it'll vary on each individual
configuration (domain names, environments, VCS in use, if it's their
fulltime site, or only a quick contract job, etc)
Something like this would do it:
wp-config.php: if ( 'blah.com' == HTTP_HOST ) include
'wp-production-config.php'; else include 'wp-development-config.php';

On 31 October 2011 04:18, Jess Planck <jess at funroe.net> wrote:

> Yes, there are many plugins storing serialized domains. I may have done it
> without thinking myself. It is the biggest  stumbling block doing manual DB
> transfers.
>

Yep, _doing_it_wrong().
So in that case,
 * If it's a file, page, post, etc that's being referenced to, the PostID
should be stored instead of the url, what if the slug gets updated on the
page? (or parent changes, etc)
 * If it's a link to an off-site site, well, it doesn't matter, it can
stay-as-is.
 * If it's a link to a page/post and is designed for easy insert by the
user, there's 2 options:
   1. Do a lookup on the url and retrieve the post ID, and store that (This
is easily done)
   2. do a str_replace on the domain component and prefix later.. if it's a
problem in the environments its designed for
   3. Consider that's is a necessary evil, and will have to live like that.
 bonus: If the plugin doesn't have many options, consider that it could be
stored as it's own string in the options table.. removes the serialised
problems.

Ultimately however, if a plugin is in use which stores the url's like that
in the database, you're just going to have to alter it when you move the
site anyway, there's nothing WordPress can do really that's going to
reliably solve it for everyone in that case..

On 31 October 2011 07:23, Rafael Ehlers <rafaehlers at gmail.com> wrote:

> Pride or it wont be good for the WordPress.com .
>
> If they really use wordpress.org latest software on that, maybe this
> change
> of paradigm would totally bring a lot of problems to them!
>
> Hence this difficult to change the direction of WordPress software on these
> kind of issues.
>

WordPress.com's usage of WordPress isn't really going to impact upon this
at all, WordPress.com runs a customised version of WordPress, many .org
functionalities are disabled, many additions have been added, as much as
some people won't agree with me saying this: Automattic/WordPress.com
doesn't direct the way WordPress.org project runs.
However, that being said, WordPress.com has some of the brightest people
I've met working on it, they've battled it out against many problems which
more-than-single-site installs have come up against, they're aware of the
issues with caching for millions of installs, they have the experience. and
because of that I will trust their opinions on how to most efficiently
implement something over a developer who's experience I'm unsure of any
day.. just the same as I'll trust their experience on what to cache over
what I would cache.. since I don't have that same level of optimization
skillset (ie. CPU Cycles might be cheap, but I'll still attempt to avoid
them in many cases)


More information about the wp-hackers mailing list