WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 years ago

#16614 closed enhancement (wontfix)

Allow blog privacy to be set in wp_config.php

Reported by: kanuck54 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: General Keywords: close
Focuses: Cc:

Description

I imagine this scenario is fairly common: I regularly reverse-migrate data from the client_live database to the client_dev database on a client site, so that I'm always working with the very latest live data when working on their custom theme.

In this scenario, the WP_HOME and WP_SITEURL constants in wp_config.php save me a ton of work; they very nearly foolproof the entire back-and-forth process.

The one notable problem is blog privacy. Since blog_public is an option stored in the database, every time I reverse-migrate, our dev site switches from private to public, and I need to remember to switch it back so I don't accidentally send out pingbacks and notify a site where our development environment is located.

I can mitigate this with (in order of increasing foolproof-itude) a theme function, or a plug-in, or a drop-in plug-in; but I think it would make the most sense if I could set this in wp_config.php, since, like WP_DEBUG, WP_HOME and WP_SITEURL, it's something that will frequently differ between two otherwise identical incarnations of a site.

As I see it, defining a WP_BLOG_PUBLIC constant in wp_config.php could have the same effect as setting WP_HOME or WP_SITEURL; the option would still be visible in the Privacy Settings in the administration panel (options-privacy.php), but you wouldn't be able to change it.

Change History (9)

comment:1 follow-up: @dd325 years ago

  • Keywords 2nd-opinion close added

I'd rather you stuck to a filter.

The option controls 3 things:

  • robots.txt
  • robots Meta in the <head>
  • Disables pings

Pretty sure it's the last one you wish to do here, We've been playing down the privacy option as it doesn't do what a lot of people expect it to do (ie. completely block search engines from indexing it, which it doesnt). giving it a define seems to give it more credentials than it's worth.

Not all options deserve a define, infact, I can think of a few more that are worthy of it than this..

comment:2 in reply to: ↑ 1 @wpmuguru5 years ago

Replying to dd32:

I'd rather you stuck to a filter.

I agree. This can be handled by a one line filter in a plugin.

comment:3 @wpmuguru5 years ago

  • Keywords 2nd-opinion removed

comment:4 follow-up: @kanuck545 years ago

My main issue with that solution is that wp-content/ is typically synched between live and dev environments; so ultimately, if I write a theme function or a plug-in, it's going to have to look at a constant defined in each config file anyway.

And should my plug-in or theme wind up deactivated during a live-to-dev migration, the worst case scenario is that I could potentially have a broken dev site being indexed by a search engine.

It's just not as robust as I'd like. I find it's always safest to assume myself and everyone else an idiot, and therefore I always like things idiot-proofed.

I understand where you're coming from, and obviously in the meantime I'll just short-circuit blog_public based on my own constant in wp_config.php. I'm just hoping you'll consider this for the future—especially since I would disagree with the notion that the blog privacy option ought to be downplayed. It looks like #16416 will re-word the option to better indicate to non-techies what it does; and for the tech-inclined, it does exactly what it ought to do, so being able to control it absolutely alongside other instance-specific options would be ideal.

Cheers.

comment:5 @nacin5 years ago

You're always going to have code that needs to run on one or not the other, and some of it will need to be once the dev environment is loaded.

One good example is a "Staging" plugin that deliberately detects live versus dev, and does various things depending on the environment. Or a plugin that only gets activated on one of them.

comment:6 @Hekos5 years ago

Using WP_DEBUG might be a solution, since it is really ill-advised to be using WP_DEBUG on production sites, but recommended on development sites.

Making a plugin that suppresses features conditional on WP_DEBUG would be trivial.

comment:7 @nacin5 years ago

Not necessarily -- many use WP_DEBUG in production but with display_errors off.

comment:8 in reply to: ↑ 4 @mikeschinkel5 years ago

  • Cc mikeschinkel@… added

Replying to kanuck54:

My main issue with that solution is that wp-content/ is typically synched between live and dev environments; so ultimately, if I write a theme function or a plug-in, it's going to have to look at a constant defined in each config file anyway.

And should my plug-in or theme wind up deactivated during a live-to-dev migration, the worst case scenario is that I could potentially have a broken dev site being indexed by a search engine.

@kanuck54 - As a way to handle what you need you might consider using the plugin I published here. With it you could add a 'blog_public' element and a hook for the one-click webhost migration to assign the setting the proper value for each applicable specific webhost. When I get a chance I might even add that into my next update of the plugin.

If you need help getting it set up feel free to contact me; you can find my contact info on the site where I posted the plugin.

Hope this helps.

comment:9 @nacin3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.