Archives

Cloud Hosting FAQ

Frequently-asked questions about our VIP Cloud Hosting. Have a question that’s not answered here? Get in touch. 

1) We don’t yet have a WordPress theme – how should we get started with WordPress.com VIP Hosting?

If you’re building a theme from scratch, we suggest using the WordPress default themes, Twenty Ten, Twenty Eleven, or Twenty Twelve, as they use the recent APIs, are cleanly coded, and provide a good foundation for your work. You should start your theme as a Child Theme instead of modifying Twenty Ten/Twenty Eleven/Twenty Twelve directly. All WordPress.com public themes are available at https://wpcom-themes.svn.automattic.com/.

2) We already have a theme on a self-hosted WordPress site. Will we be able to use it on VIP Hosting?

Yes, probably! As part of the setup process the VIP team will review your theme for any errors or code that needs to change to make sure it’s a good fit for our environment. We also require the use of GPL-licensed plugins and themes or 100% custom ones. If you’re not sure about what you’re using, just ask!

3) How long does the theme review process take?

Once you have your theme fully built and tested in your local environment, the theme is ready for us to review. We generally need 10-15 business days to do a full theme review. You’ll send it to us in an email as a zipped attachment.

4) Can we use X plugin?

Yes, probably! There are +23k WordPress plugins, and you can use most.  We review each plugin to be sure it’s enterprise quality, secure, and will scale with your site’s traffic.  Legacy methods of modifying database tables and manipulating the file system are also traits of plugins we try to avoid, and will work with you to use modern approaches such as Custom Post Types and in-memory file manipulations. We also have a bunch of popular plugins already pre-installed and ready for use. If you are interested in using a plugin that isn’t available as a pre-approved VIP plugin, we will review it for stability, performance, and security before it can be used on WordPress.com VIP.

We also recommend using existing WordPress functionality whenever possible instead of a plugin. If you are not sure if a function exists, try a quick search of a descriptive keyword/field name or similar on one of the many WordPress code documentation sites such as http://codex.wordpress.org/, http://phpdoc.wordpress.org/trunk/, http://wpseek.com/, or http://hitchhackerguide.com/function-filter-action-index/

5) Can we use X caching plugin?

You won’t need any caching plugins on WordPress.com VIP Hosting. WordPress.com employs multiple levels of caching automatically. For cases when you are sure that you cannot use a function that contains caching and need to do something that is resource intensive, you should implement some caching yourself using the WordPress cache.

6) How will we access our code?

All WordPress.com code is managed using the Subversion (SVN) revision control system. SVN is the only way to access and update code on VIP Hosting. After your theme has been reviewed, you will be able to use your WordPress.com username and password to access the code for your theme using Subversion. The VIP team will review and handle all deploys for your site, and your developers will get deploy notifications automatically.

7) How does staging work?

VIP clients for the most part have staging servers in-house. A few clients choose to use one of their VIP-package sites as a pre-production site, but any code must be tested and debugged prior and aligned with our coding standards. Think of this pre-production site as a way to test integrations with WordPress.com features that don’t have WordPress.org equivalents (via Jetpack or other plugins).

8) Can we have custom database tables on WordPress.com?

Themes and plugins should use the existing database tables and structure (no alterations). Custom Post Types, Custom Taxonomies, post meta, etc. are incredibly flexible as an alternative to custom database tables.

9) Can we use plugins or code that modify the filesystem?

For security and performance reasons we do not allow plugins or code that write directly to the filesystem.  We’ll work with you to modify the code to avoid local file system manipulations.

10) How do we register user accounts?

By default, users registered through VIP-hosted websites are created as WordPress.com users, which means that the millions of users logged in to WordPress.com will also be logged in on your domain, making it easier for them to comment on your site. If you’d like to be able to query user data or create custom registration fields you’ll need to use a 3rd-party registration service.

11) Is WordPress.com VIP running stock WordPress, or are there tons of custom modifications?

WordPress.com is running mainly off core WordPress, but uses some alterations and optimizations which are unique to our large-scale environment, including a lot of very cool features built right in for all users. WordPress.com is constantly evolving, which means that VIP clients often have access to the latest features and WordPress releases well before the rest of the world. Easy-to-use shortcodes and other built-in features replace the need for many custom plugins.

Have a question that’s not answered here? Get in touch. 

Launch Checklist

Pre-Launch

Launch Day

  • If this is a migration, we’ll incrementally import any new content.
  • Make sure domain is mapped.
  • Set site privacy to “public.”
  • Update robots.txt.
  • Common 404s checked and redirected.
  • Launch!

Accessing Your Code

All WordPress.com code is managed using the Subversion revision control system. Subversion (SVN) is the only way to access and update code on VIP Hosting.

If you are a Microsoft Windows user, we recommend using the TortoiseSVN GUI client. If you use a Mac, and you don’t grok a little UNIX, SVNX comes recommended.

Accessing SVN

After your your theme has been reviewed, you will be able to use your WordPress.com username and password to access the code for your theme using subversion. The subversion repository URL will be specific to your site and sent to you by email from the VIP Hosting team.

Initially, you will just have read access to your theme’s SVN repository. Once, you’ve identified your familiarity with SVN, and the quality of your changes, we’ll provide write access. Until you have write access, please provide patches (svn diff) by email with any additional files included in a zip.

You also have read access to our shared VIP plugins. For more details about our shared plugins, please see the plugins section of this site.

All code development and testing should be done in your own local WordPress.org environment. Only tested code should be committed to WordPress.com.

Submitting Code

Our aim is to have all developers have write access to their own repositories, but all new-to-VIP project developers will have to send in code changes via support ticket. To submit code via support ticket, we ask that you create a diff of the changes so only the changed code is sent.

Here’s information about how to save a patch/.diff file. If you have questions about this, please let us know.

Committing Code

Once you’ve proven your skill, attention to detail, and willingness to apply feedback, we’ll give you write access to your VIP repositories. This gives you the ability to commit your code directly. Once you do, it is spot reviewed for security and performance concerns, and then deployed to server clusters in all of our data centers. Code changes are usually deployed within a few hours during US business hours, but usually much faster (within an hour).

For your benefit, we take code quality, security, and performance very seriously. Please check with us before committing very complicated or large chunks of code. If in doubt, it’s best to check with us first. It’s a lot less work for everyone (including you) if we’re able to take a look at it before committing than having to revert the change later. We also greatly appreciate if you commit often and with each functionality as a separate commit (if possible) rather than waiting and pushing a bunch of code to us all at once. It makes the code easier to review if we’re reviewing things in chunks.

We also like to review all plugins prior to committing them to your VIP repo. We have reviewed a small, but growing list of plugins, and modified some of them to make them more stable, secure, and perform better. Since these plugins have been pre-approved, we would prefer you use these plugins if possible if you need functionality similar to what they provide. Please see the Plugin Review Process if a solution isn’t yet available.

A few other notes:

  • When writing commit messages, consider your audience: those reviewing your code and those debugging your code at a later date.
    • For the first purpose, commit messages are one to many, asynchronous and textual. Try to write the commit message like an email. The first line should be a descriptive subject. The next line should be blank (as a separator). Then comes the body of the message.
    • For the second purpose, you’re explaining why the change was made. The commit message should say what the problem was (repro steps?), how you fixed it (briefly – the code itself gives more details), and why you changed what you did. This way the shiny pants people of the future have the information they need to decide if they can safely change your code.
  • At VIP → Dashboard (/wp-admin/admin.php?page=vip-dashboard), you can see the current deploy status.
  • If you’ve committed code you’re not happy with and would like to revert, you can do so from your local checkout. Simply use the command “svn merge -c-64320 .” where “64320″ would be the revision you’d like reverted. After running that command, you’ll need to commit your revert. You’ll want to use a commit message similar to “Reverted r64320 because [explain your reasoning]“.

Access for Additional Developers

For the security of your site and our systems, we like to have all of the following info for anyone with SVN access:

  • Full Name
  • WordPress.com username (should be their name or a handle, but not generic/brand)
  • Email
  • Alternate Email
  • Job Title (role)
  • Phone #
  • Mobile #, as well if possible
  • IM and/or Skype

In your VIP dashboard, you can request access for users added to your blog using the “Request SVN Access” widget shown below.

Introduction to the VIP Review Trac

We use the VIP Review Trac for all theme and plugin reviews. Our goal is to help you produce better quality code and improve the likelihood of launching in a timely manner.

Trac Overview

The VIP Review Trac is a standard Trac install with extra VIP juice mixed in. If you haven’t used Trac before, it’s an open source wiki, issue tracking system, and code browser that integrates fully with Subversion, our version control system. Because it also has a plugin architecture, we’ve extended it to include features like inline code commenting.

Trac is also the primary project management tool for the WordPress.org project. We’ll hope you’ll give back, either by writing patches for tickets, testing others’ patches, etc., once you become more familiar with the WordPress software.

Code Reviews With VIP Review Trac

When a VIP sends in a new theme or plugin via support ticket, we’ll load the code into the VIP Review Trac and send you a link to make the code review process more collaborative and effective. We’d like the review process to look something like this:

  1. A WordPress.com VIP Team member commits the initial set of code, and grants read-write access to VIP developers/project managers. You’ll be able to authenticate using your WordPress.com account. From this, you’ll be able to check out a copy of the code, browse the code in Trac, and see all of your tickets (assigned or cc’ed) from the homepage. You’ll also want to set your email address in Trac preferences so you receive notifications for new tickets or comments.
  2. WordPress.com VIP reviews the code, leaving inline comments and creating new tickets as needed. You can start working on issues as soon as we open them, but we’ll let you know when the review process is complete.
  3. We start everyone off with read-write access to code in the VIP Review Trac so you can resolve the tickets in a timely manner. The order in which you resolve the tickets does not matter, but we expect that each commit to the repository can be linked to only one or more tickets, if possible. You can do so with “See #NN”, “Ref #NN.” Also, please keep your commits as small as possible and make sure your commit comment communicates the change well. When you’ve committed all of the necessary code to resolve the issue, you can close the ticket.
  4. Once all of the issues are resolved, we’ll move the theme or plugin to WordPress.com. At this time, you should switch your Subversion checkout to the new VIP Subversion URL and prepare all future patches against that checkout.

As always, we love all feedback on what works and what could be improved.

Suggestions to Fast Track your Theme Review

1) Make sure you’ve reviewed VIP documentation

This site features documentation and a guide for developing sites on WordPress.com VIP. We share best practices, helpful tips and share information on custom modifications other VIP clients have implemented to help you code better, faster, and stronger. We highly recommend going through the Getting Started and Best Practices sections.

2) Make sure your local environment is set up correctly as described here:

http://vip.wordpress.com/documentation/development-environment/

3) Work with an existing theme that’s available on WordPress.com

If you’re looking for a barebones theme, to start from, check out _s, which is built and maintained our own Theme Team.

If you’re looking for something more fleshed out to work from, we recommend going through one of our 200+ pre-approved themes on WordPress.com. The code for all the free themes are available here.

If you’re interested in working with a Premium theme, let us know and we can provide access to the code.

If you’re running a number of sites you’ll want to take the common theme approach – it’s a single theme used across multiple sites

If each site contains some unique functionality you can add that via Child Themes. Here’s an excellent walk-through.

4) Re-use and Recycle

Instead of replicating functionality by coding it anew, use some of the many existing plugins we have pre-approved, including some from our partners.

5) Follow Standards

We recommend all developers follow the WordPress Coding Standards. It helps ensure consistency and cleanliness in code and helps us review things much faster.

6) Avoid Common Issues

Please review the list of common issues we see in Theme Reviews.

Code Review

Congratulations! You’re getting your code ready for WordPress.com VIP.

This document covers three types of reviews: Theme Reviews, Plugin Reviews, and Deploy Reviews.

Before You Submit Your Theme for Review

Once you have your theme fully built and tested in your local environment, the theme is ready for us to review. We generally need 10-15 business days to do a full theme review (we also have priority reviews available for a rush fee—get in touch if that’s of interest). Send it to us in an email as a zipped attachment.

If the theme is more than just a basic theme, it will speed up the review process for us to fully understand the purpose of any custom code and what it’s trying to accomplish. Therefore, the more technical and in-depth documentation you have, the better. If the theme is based on another theme, please let us know. Here are some more suggestions to fast-track your theme review.

We also like to review all plugins you’re planning to use. We have reviewed a small, but growing list of plugins, and modified some of them to make them more stable, secure, and performant. If your site hasn’t launched yet on WordPress.com, then please only consider the few plugins crucial for your user experience. It will make the launch process go much smoother.

We’ll provide feedback relating to any errors, irregular code, or calls in the theme that must be fixed and/or explained before the theme can be approved. Our code review process is collaborative—we encourage you to introduce yourself to how it works.

After your theme has been approved, we’ll provide access to your own subversion repository.

Here are several notes that will help speed up the review process and reduce the number of iterations needed to reach a successful launch:

  • WordPress code is licensed under the GNU Public License v2 (GPL2). All theme and plugin code needs to be GPL compatible or custom code you’ve written in-house—split or proprietary licenses are not allowed. The reasoning for this is that you, and we, need to have the legal rights to modify the code if something is broken, insecure, needs optimization, etc.
  • If you are using a premium theme or plugin, please get in touch with us before purchasing as we may already have it available on WordPress.com or have previously reviewed it.
  • If you are just starting up with your theme development, please check out the already approved WordPress.com public themes (SVN) and evaluate if you could base your development on one of these. This could reduce the review time dramatically. The Twenty Ten and Twenty Eleven themes, for example, make great base themes.
  • Please make sure that the code you submit for review is well-tested and includes all the information needed to function on a clean, current WordPress installation. If any content needs to be setup in order to test your theme, please provide a WordPress export with sample data.
  • Please note that plugins and other functions that alter the database structure or perform write operations on the filesystem interfere with our architecture, and we likely will not be able to approve these kinds of scripts. More details are shared in Best Practices.
  • Make sure that all of your plugins are included and running from within your theme folder. The plugins will be loaded by the themes’ functions.php file or similar methods. Some plugins need alteration of paths and/or urls in order to keep functioning in such an environment.

Common Issues with Theme Reviews

We review a lot of themes. Many of the issues we find repeat themselves over and over again. To save yourself (and us) time, here are some things you should keep a keen eye out for:

As always, if you have any questions about the best approach for a particular problem, please get in touch.

Before You Submit A Plugin for Review

If you are interested in using a plugin that isn’t available as a pre-approved VIP shared plugin, we will have to review it for stability, performance, and security before it can be used on WordPress.com.

Before deciding on a particular plugin solution, please share with us the problem you are trying to solve, or the experience you are trying to create. We likely can add our own insights to the scenario, and suggest advantages and weaknesses of different approaches.

When submitting a plugin, we appreciate as much detail as possible about how the plugin will be used and what it’s trying to accomplish (examples are particularly helpful). Our code review process is collaborative — we encourage you to introduce yourself to how it works.

Plugin Guidelines

  • WordPress code is licensed under the GNU Public License v2 (GPL2). All plugin code needs to be GPL compatible or custom code you’ve written in-house. Split or proprietary licenses are not allowed. The reasoning for this is that you, and we, need to be have the legal right to modify the code if something is broken, etc.
  • The plugin needs to run on the latest version of WordPress with MultiSite (previously WordPress MU) enabled.
  • The plugin should not directly write to the filesystem as this will not work with our distributed environment. You can use the WordPress API though, such as wp_handle_upload().
  • The plugin should use the existing database tables and structure (no alterations). Custom post types, custom taxonomies, post meta, etc. are incredibly flexible.
  • The plugin should not rely on the plugin activation and deactivation hooks as VIP plugins are a part of your theme and are loaded using require_once() rather than the plugins menu.
  • If you’re currently using Jetpack on your self-hosted WordPress site, you don’t need to include it on your WordPress.com VIP site—every feature that exists in Jetpack is already included in WordPress.com.

Please pre-review your plugin before submitting it to us to make sure it meets the WordPress.com guidelines for code. Depending on the complexity of the plugin under examination, the initial plugin review could take up to 2 weeks.

Once Your Plugin is Approved

Plugins on WordPress.com VIP are organized differently than a standard self-hosted WordPress.org site, since on VIP you only have access to your site’s theme folder. To use plugins on a WordPress.com VIP site, you add them to a “plugins” directory within your theme directory, and require_once/include_once them in functions.php. e.g.:

require_once( __DIR__ . '/plugins/custom-plugin/custom-plugin.php' );

Deploy Reviews

Once your plugin and themes have passed review they are moved to the VIP production repo and you are granted the necessary access to submit code changes.

We still review everything before deploying, so you can expect tickets, commits, or reverts from us if we find any issues. If issues are found in submitted code and it’s a simple fix, we fix the issue and notify the developer before pushing the code live. If it’s a more complex problem, we do not deploy the code. Instead, we revert the code and notify the developer with guidelines on how to fix the problem.

We deploy code changes to VIP sites throughout the business day and strive to have all changes live within two hours. Note that changes to CSS files and images are deployed automatically.

Some guidelines to help speed up the deploy process:

  • Only commit tested code. Never use WordPress.com for testing or debugging. If there is something you cannot reproduce or work out in your local environment, please open a ticket and ask for assistance.
  • Including a detailed commit message speeds up the time it takes us to review and deploy the code, and is also essential for future debugging or in case of emergencies.
  • If you have significantly large or complex changes to push, please send the changes in as a patch ahead of time.

 

Setting up your Development Environment

Like all software development, develop and test your code in your local WordPress.org development environment before committing the code to WordPress.com. We often deploy beta versions of WordPress to WordPress.com early, so we recommend using a SVN checkout of WordPress trunk rather than the latest stable release version. This way you won’t get caught off guard when new versions of WordPress are rolled out to WordPress.com.

No direct access to WordPress.com databases is possible from your local development environment. An updated copy of your site’s data can be easily exported and imported locally.

Setting up your environment

Here’s how we generally recommend local dev environments be set up:

  1. Install WordPress
    • Do an svn checkout of trunk from http://core.svn.wordpress.org/trunk/
    • Enable multisite (this is recommended, but not necessary)
    • Make sure to svn up every day or so so that you’re working off the latest code (this isn’t necessary during early development phases of a WordPress version but required as the project nears alpha and beta releases).
    • Populate your site with some test data (you can use our demo files, though, you’re better off using test data from your own sites)
  2. Install and activate the Developer Plugin.
    • The plugin will help you optimize your development environment by making sure that you have all the essential tools and plugins installed and available.
    • Make sure to select “WordPress.com VIP” as your project type.
  3. Install and setup Jetpack.
  4. Install VIP Shared plugins
    • See below
    • Again, make sure to svn up every day or so
  5. Set up your theme
    • Themes in the VIP environment live in WP_CONTENT_DIR . '/themes/vip/'. For example, your theme path might be /wp-content/themes/vip/my-theme/
    • If your theme is already in the VIP SVN, do an svn checkout in the vip themes folder: svn co https://vip-svn.wordpress.com/my-theme/ wp-content/themes/vip/my-theme/
  6. Enable debugging to catch errors early and often
    • See below.

VIP Plugins and Helper Functions

You should already have read access to our shared VIP plugins directory containing a growing list of plugins that you can use.

To test these plugins in your development environment, use your WordPress.com username and password to check out a copy of them from https://vip-svn.wordpress.com/plugins/ using Subversion. To match our environment, they should be checked out to wp-content/themes/vip/plugins/ and not wp-content/plugins/ like you would normally.

svn co https://vip-svn.wordpress.com/plugins/ wp-content/themes/vip/plugins

Once you’ve checked out that directory to your local environment, you should add the following to the very top of your theme’s functions.php file:

(hover over the below code to make the toolbar appear which contains a button allowing you to easily copy the code)

// Init WP.com VIP environment
require_once( WP_CONTENT_DIR . '/themes/vip/plugins/vip-init.php' );

This initializes most of the code necessary to develop well in a VIP environment. Here are a few things the init process loads:

  • wpcom_vip_load_helper_wpcom() includes the vip-helper-wpcom.php file which defines some helper functions that are specific to WordPress.com.
  • The vip-local-development-helper.php file defines some helper functions that assist in loading plugins and helper files. This file is automatically include()‘ed on WordPress.com.
  • The vip-powered-wpcom.php file defines some helper functions that assist you in displaying the “Powered by WordPress.com” text or image.
  • wpcom_vip_load_helper() includes the vip-helper.php file which defines some helper functions that will work on both WordPress.com and your hosting environment.

To load plugins from the shared themes/vip/plugins/ folder, you can use the following function call:

wpcom_vip_load_plugin( 'zoninator' );

Jetpack

Jetpack is a plugin that brings the many great features of WordPress.com to your self‑hosted WordPress install. It’s especially useful for testing various WordPress.com features like Contact Forms.

Jetpack currently requires that WordPress sites be reachable by WordPress.com to enable many of its cloud-specific features. For development in local or offline environments, you can enable Jetpack’s development mode by adding the following to your wp-config.php file:

define( 'JETPACK_DEV_DEBUG', true );

Note: development mode automatically gets enabled if you don’t have a period in your site’s hostname, i.e. localhost.

Debugging

You should have have PHP error display on in your development environment to banish the WSOD (white screen of death).

  1. display_errors in PHP: That can either be done via your php.ini (don’t forget to restart Apache) or via your .htaccess file ( php_flag display_errors on ).
  2. Add define('WP_DEBUG', true); to your wp-config.php file for additional warnings and notices (especially regarding the use of deprecated WordPress functions). plugin.

Using Git with Subversion

Read about how to use Git with Subversion for your local development environment.

Migrating and Importing Content

It’s important to start populating your site with real content as soon as possible.

For Small Migrations (less than 15MB)

We make it easy for you to import your blog content from a variety of other blogging platforms, including Blogger, Israblog, LiveJournal, Movable Type, Typepad, Posterous, Splinder, and Yahoo! 360. Simply log into your WordPress.com blog dashboard, then go to Tools -> Import, choose your previous platform and follow the instructions. The WordPress.com support site has more detailed instructions, or feel free to reach out with any questions.

For Large Migrations

In most cases, the most straightforward approach to migrating your content is to first get it into WordPress’s native import/export format: WXR. Once you have all of your content available in WXR format, WordPress can import that file.

A few notes on imports:

  • One of the most important steps in the migration process is adding users to the site before the import, so any existing articles and content can be correctly mapped at time of import. Please provide the VIP team a definitive list of the username mapping as soon as possible.
  • We will work directly with you to make sure that nothing malicious or spammy slips in through old comments, and to make sure WordPress.com’s security filter does not strip any of your in-post Javascript, media, embeds, or iframe tags.
  • We’ll either side-load all of your images over, or grab a copy of your media archive and after copying them to our data centers, massage the information in the export files before importing them.
  • WordPress.com has automatic URL transformation for the popular platforms. We’ll examine your permalink structure, and share with you the solutions our other customers have done, or advise you on what is the best solution in your unique case.

As each import is a little different, lead time is desired. The operation depends on the size and nature of your content. It’s a great idea to do an import early on in the migration process. This makes sure data import will not slow down the site transfer and allows you to theme with real data.

Migration Services

Migrating content from WordPress-to-WordPress is included in your per-site setup fee. We also provide content migration services, and can help you migrate from any other content management system—those projects are priced on scope, and typically range $15k-$50k. Get in touch via the contact form in your VIP Dashboard if you are interested. 

Adding Users and Content

Adding Users

Now that you are set up as the admin of a WordPress.com based site, you’ll want to add the other admins, editors, authors, and contributors, so they can get cracking on the content.

The first thing to know is that users can have different permissions regarding creating, editing, and modifying site content. We suggest reviewing WordPress User Roles and select the appropriate permissions for that new user. Roles can be changed at any time by a site administrator.

If you have a small number of users (~15 or less) to add to your new WordPress.com site, we’d recommend asking them to sign up for new WordPress.com user accounts if they don’t have them already, and then inviting them to your new site with their appropriate role. Your writers and editors can sign up for WordPress.com accounts from the WordPress.com homepage. We also have documentation on how the invites system works.

If you have more than fifteen or so users, or you have users who need to be added to a lot of sites, we can take care of creating or adding them for you using some magic behind the scenes.

Important note: We prefer you ask your team if they have existing WordPress.com user accounts first, and to provide them to you if they do. In many cases, they may have already signed up for them and this will reduce confusion in the long term to just use one account across all of their WordPress.com sites.

For adding users to one or more WordPress.com sites, please send us a spreadsheet (or CSV) with each user’s WordPress.com username, the role (“admininistrator”, “author” or otherwise) they should be added to the site as, and the URL for the sites they need to be added to.

For creating new users and then adding them to one or more WordPress.com sites, we’ll need a bit more information: WordPress.com username, email address, first name, last name, display name, and user role. This should come as a CSV or spreadsheet. All new users created with this method will be prefixed with a common slug. If they want to have their “unbranded” WordPress.com username, they’ll need to create it in advance.

When you have this information together, please contact us through the VIP Support form in your dashboard, and attach your CSV.

Adding Content

If you’re coming to WordPress VIP with content from a pre-existing site, you’ll need to read about Migrating and Importing Content.

When it comes to creating new content here is some essential reading for the editors, authors, and yourself as you support them in their WordPress adventures:

* Many of those pages have awesome videos at the bottom.

Mapping Your Domain and Managing DNS

You love your shiny new WordPress.com site and you probably want to put your own domain on it.

To proceed forward, you’ll need to have first registered your domain with a domain registrar. If you haven’t yet, you can register your domain through WordPress.com or another domain registrar. To map a domain you already own, simply follow these instructions. Domain mappings are included for free on WordPress.com VIP and Enterprise. Domain registrations will cost either $18 or $25 USD/year.

Since mapping a domain can take up to 72 hours, you will want to begin this process at least a week before your planned launch date.

Once you point your nameservers to WordPress, you can continue to manage your domain with our Domain Management tools. If you map a 2nd-level domain (e.g. example.com), you can easily add a subdomain (e.g. vip.wordpress.com) or add email. You can also map a subdomain to WordPress.com, but you will be unable to add email.

Mapping to WordPress.com

If your site will live on a 2nd-level domain (example.com), we highly recommend hosting it with our DNS servers. In order to smoothly handle any volume of traffic and weather any malicious attack, our load balancing and high availability solutions are dependent on us being the name server for 2nd-level domains. By taking this approach, it enables our skilled systems team to effectively route traffic to additional servers, mitigate attacks, or accommodate for an outage in one of our data centers.

If you have an existing website that you are migrating to WordPress.com, the following steps should be taken to set up the domain least a week before the launch:

  1. Send us the ZONE file for your domain including any subdomains or MX records for email.
  2. We will set up the domain mapping on the WordPress.com site
  3. We will set up the DNS entries to mirror your current setup (so your existing site continues to work when you point your domain to our nameservers).
  4. Once setup is complete, you can verify and switch to our nameservers.
  5. When your site is ready to launch, we will update your website’s entry to point to your new WordPress.com site.

This provides the most fluid migration and means we’re around to pull the actual trigger and assist with any post-launch tasks.

Using WordPress.com Nameservers

The nameservers to use are:

ns1.wordpress.com
ns2.wordpress.com
ns3.wordpress.com

We provide a handy DNS management tool for you to create A, MX, CNAME, and TXT records.

Using 3rd-party Nameservers

If, for some reason, you would like to host the DNS elsewhere, you can create A records pointing to two or more of our IPs. To get this information, please contact us using the contact form inside your Dashboard.

At least a couple of days before the migration you will want to change the TTL to 300, or if that is not allowed by your current DNS hosting, the lowest value allowed to allow for the smoothest transition possible.

www subdomain

Note that on WordPress.com, we do not support the www subdomain. The www is CNAMEd to the root and gets redirected.

Subdomain (sub.example.com)

If your site will live on a subdomain (sub.example.com, all that is required is a CNAME. When the site is ready to launch, you can create a CNAME entry pointing to your registered WordPress.com site:

sub.example.com IN CNAME subexample.wordpress.com.

Note that you will want to change the TTL for the subdomain to 300 or the next lowest value allowed to make the transition as smooth as possible.

Primary Domains

Every WordPress.com site can have multiple mapped domains but only one Primary Domain. This the canonical domain name for your site and all other domains registered against the site will redirect accordingly. The Primary Domain can be set from the Domains page in the WordPress.com Dashboard; just head to Settings > Domains and select the domain you would like to be primary.