Opened 12 years ago
Closed 5 years ago
#16614 closed enhancement (wontfix)
Allow blog privacy to be set in wp_config.php
| Reported by: |
|
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 (11)
#2
in reply to:
↑ 1
@
12 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.
#4
follow-up:
↓ 8
@
12 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.
#5
@
12 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.
#6
@
12 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.
#8
in reply to:
↑ 4
@
12 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.
#9
follow-up:
↓ 10
@
11 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
#10
in reply to:
↑ 9
;
follow-up:
↓ 11
@
5 years ago
- Resolution wontfix deleted
- Status changed from closed to reopened
Replying to nacin:
Highly desirable feature, what a shame devs and other contributors to this thread are too stubborn to pull their heads out from wherever they keep them and realize that it's not their role to micromanage how we organize deployment strategies. No compelling argument is presented against creating this flag.
If only there was some way to highlight the marketing impact of a production or development site with the wrong setting...
#11
in reply to:
↑ 10
@
5 years ago
- Resolution set to wontfix
- Status changed from reopened to closed
Replying to Vision Hive:
Coming into a ticket that hasn't had an update in five years and stating developers are stubburn and have their heads stuck somewhere is not the best way to make an impression and get what you want. Please treat everyone who is contributing their time to WordPress with respect.
For many years, WordPress has been avoiding adding new constants as the way to identify how something should function. They have proven to not be as agile as the WordPress hooks system and also make automated testing harder.
If you are looking for a way to have a greater visibility into this option's value on your sites, there is a plugin for that.
I'd rather you stuck to a filter.
The option controls 3 things:
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..