[Advanced] So you’re planning to launch a new blog but don’t want to reveal it to anyone quite yet, for a variety of reasons. You want to be able to view individual posts as they would normally appear, but neither want them indexed nor visible to anyone. Or you want to test some themes on an existing blog without your visitors having to see.
There are a few ways to accomplish either, and it’s relatively easy. Just make sure you take precautions to back up your existing blog and database. (I’ve wiped out a few sites. Fortunately, they never had more than about 9 posts, and could be fixed manually.)
Subdomain Method for Existing Blogs
This method is useful for testing changes to a blog that already exists. It amounts to creating a test blog on a subdomain. Your hosting account must allow you to not only set up a subdomain for your, but also access the existing database. You should know that many hosts do not allow this. And as I’ve only tested on WordPress this method may not work for you on other blog platforms.
- Create a subdomain. So if your blog is at http://www.myblogdomain.com/, then create something like test.myblogdomain.com. You’ll need to do this in your hosting control panel, not your blog platform control panel.
- Install your blog platform on the subdomain. If you have “one-click” blog setup through your host, just make sure that you specify the subdomain during installation, else you may wipe out your existing blog.
- Tweak the test blog’s configuration to access the real blog’s database. If your hosting provider does not allow this, you will need to backup the main database and import into the test database.
- Turn off access to your test blog to search engine bots. Newer versions of WordPress have a “privacy” setting. For older versions, look under the “Writing” options of “Options” and get rid of the entries in the “Update Services” section that “ping” one or more blog pinging services. For other blog platforms, you will have to look for something similar.
- Make your changes and test them. No one will know that the test blog exists, provide you don’t click on any links to either the main blog nor outside your domain. Also make sure not to change the database or you may affect the main blog. (That is, if the test blog is accessing the original database.)
- When you’re done, just get rid of the test blog and apply changes to the main blog, if desired. Just make sure you don’t get over-zealous and delete the wrong database. [I would highly recommend backing up the main blog’s database before starting this process.]
This method is good for when you have an existing blog and want to test a few themes and plugins before going live. But what if you want to launch a new blog and don’t want anyone to see any of the content until you’re done tweaking?
Hide Your Home Page Method
This method is ideal for a new blog. No one knows your URL yet, and posts and pages are not indexed.
Last year, I came across a WordPress plugin that disallows access to the home page, unless you are an admin. However, I never managed to get it to work, as simple as it was. My method requires no plugin, but does require a bit of code tweaking. The general essence of it is to tweak your theme’s main page code. What you’ll do depends on both your specific theme and your blogging platform. My specific instructions will be for WordPress’ “default” theme, for simplicity. Here is the general procedure:
Whether your theme uses a single template file for rendering the home page, post (permalink) pages, and archive pages, the process is the same. Note that for most themes I’ve tried (a good several dozen), all had a different template file for “page” pages. (That’s “pages” in the blog sense, where the page is not part of the reverse chronological bunch of post pages.)
- Backup your theme’s files.
- Tweak your home page’s template file.
- In WordPress, that file is called index.php but in your WP panel’s Theme Editor, it may be labelled something like “Main index”. Select that file for editing. and look for the conditional code that determines whether the URL being rendered is the home page, a post (permalink) page, or an archive page. [Not a “Page” page, though.] Note that even if you have a theme that uses a separate template file for the home page than for post pages, the process is the same.
- In the conditional code of the template file that checks whether the URL being rendered is the home page, remove any code that displays post content.
- Replace that code with a message or graphic stating that the blog is “in beta” or whatever you like.
- Remove all links in the sidebar template(s).
- Remove any advertising in all templates, in case having ads on pages with no content violates some network’s TOS.
- Turn on the privacy setting to block search engines. In some blog platforms, you may need to disable the “ping” settings. That way, when you post a new article, the URL will not be sent out to various blog pinging services. If that happens, then your whole effort is pointless.
- Tweak themes and plugins, add new content. You’ll be able to access specific posts and pages from your blog platform’s control panel. However, if you try to view the home page, it’ll be blank except for your message.
- When you’re ready to go live, just replace the template files with your backup copy. Remember to turn off privacy settings and add any pinging services you want to access.
There’s generally no need to do anything to the “page” template because it will not affect the home page. We also don’t need to do anything to the post template, only the code that renders the home page.
Keep in mind that both methods above fall apart if you click on any link to an URL outside your domain, since those sites could have a list of referring URLs. This of course exposes your otherwise hidden blog
8 thoughts on “How to Keep Blog Changes Temporarily Under Wraps”
geeksaresexy: I was thinking of your post when I said above about installing locally. But I couldn’t remember where it was (here or your site or some where else). I guess I should have searched. Still, some people are not comfortable with installing Apache and PHP locally, hence why I’ve mentioned the above.
I wrote something in the past that was linked by performancing last year.. thought it would be approprite to post it here again
Installing WordPress Locally Under Windows XP
http://geeksaresexy.blogspot.com/2006/06/installing-wordpress-locally-under.html
(skip the ads on top 😉 )
Not everyone has the luxury of cpanel, and yes, it’s one of those situations where the process is easier than explanation. I embellished the description a bit to cover two situations.
BTW, what “dev” folder are you talking about? What wp import function? And can you do this with on every host? The answer is no, especially if you don’t have cpanel. You have a single sentence trying to summarize my post, and yet I don’t understand any of the details you’ve mentioned. Neither will someone who has never done this before. Now you do you understand why my complicated explanation? I labelled this post [advanced] because though the idea I’m presenting isn’t that complicated, it’s not something a newbie blogger wants to do, and may not be familiar with any of the control panels beyond WordPress (or whatever platform. I was also trying not to be too WordPress-centric. In hindsight, maybe I should have been, to reduce the complicated explanation.
umm…copy the theme / plugins to the dev folder (through cpanel) and use the wp import function to pick up the original db (do this once and you can then test as much as you want).
sorry mate, don’t understand the point of making things more complicated.
Brett, good points. As long as you’re using a setup where the database is on a separate server than the rest of your website, then you can theoretically connect to the db from other servers. However, some hosts are now disallowing this, for security reasons. But it generally does work. I’ve tried it in the past.
So, if your site is running on Linux, instead of a LAMP setup (Linux/ Apache, mySQL, PHP) on one server, you’d have LAP on one and M on another. I currently use two hosts (having just switched from a stinky one), GoDaddy and Site5. GoDaddy uses LAP+M, Site5 uses LAMP. But a GoDaddy rep had informed me a few months ago that they were disabling cross-server access. Subdomains, however, would work.
But any method that effectively hides your pages will suffice. You could use password protection on each post, but you would have to enter the password each time as you create a new post. Also, my experience with WP and password-protected posts is that after X days, it won’t let you change the password. I don’t know what X is, and I haven’t tried simply removing the password, since that’s not what I wanted.
Note that with password-protected posts, your post titles would still appear on the home page. Maybe you want a private backup of your content, but want it live rather than on your home computer/ laptop. With the “hide your home page” method, you’d have that, and no one would know your site’s there. You could still pswd protect each post if you wanted, for double protection.
I had never thought to run a subdomain attached to the same db for a blog, but that is an excellent suggestion for testing.
I suppose that if you are running your own server/virtual server you could even connect to the db from a different domain if you chose.
Plus, you should be able to password protect things going into the domain as well.
In the past I have done this type of thing every now and then on a very deep sub directory as opposed to a subdomain. If by chance you have a limit on the number of subdomains this should be a feasible option, but its wise to go pretty deep with the directories so that you do not have any file name cross over with an article from a blog if you use a permalink structure that creates a file name that looks like a directory.
Ahmed, the situation here is that maybe you’re testing your own theme hacks, or the content of your posts is affected in terms of display. I.e., you need to view the theme/ plugin changes like a beta test. That is, you don’t want anyone to see. You’ll have to come up with your own reasons for why “hide” your blog, but there are many legit reasons – particularly testing your own themes, which you don’t want released, etc. So a dev blog would only work if you can access the original database.
And of course, you may have a new blog you’re working on that you don’t want to reveal just yet, but want to test on a live server instead of a WP installation on your computer. Don’t forget that for some people, it’s easier for them to create a live test installation than to installl Apache and PHP on their computers, configure it, then add a local WP install.
This is an extreme case, but I’m documenting a series of techniques because I think there are some people out there that want to do this and others that might at least like to know the methodology.
1) for theme changes, cant we just use the theme switcher plugin?
2) live theme editing is a lot of fun, albeit a bit stressful if you mess things up
3) I have a dev blog I use to test themes and plugins – make all the major changes there, then port the theme / plugins to the actual site and make small tweaks if necessary.
Comments are closed.