CoursesMigrating content from WordPress to SanityRestructuring content
Track
Replatforming from a legacy CMS to a Content Operation System

Migrating content from WordPress to Sanity

Lesson
10

Restructuring content

Take the opportunity to transform content from presentation-focused in WordPress to structured content in Sanity

Log in to mark your progress for each Lesson and Task

This lesson has no tasks but should inspire you to do the sorts of content refactoring you can do as part of your migration. Your decisions will depend on the shape of your content and the outcomes of your re-platforming.

You may have content stored in pages or posts that represent much more than what the concept of a "page" or "post" accurately describes. This is a key part of making your content reusable, and not having to copy-paste across surfaces.

In this example, imagine you have content stored in pages but separated by page template.

  • Staff profiles use a "staff" template
  • Office locations use an "office" template

You can look for it in the response of a page document type in a template field:

{
"title": "Emkay Petersen",
"template": "staff.php"
}

This presents a great opportunity in your transformation scripts to convert meaningful content currently trapped in presentational thinking into structured content.

The next step is to create Sanity Studio schema types with more appropriate descriptions of that content. A more accurate type name increases the likelihood of getting more future use from your post types.

  • person for staff profiles
  • location for offices

With new Sanity Studio schema types created, re-run schema extract and typegen generate to create new, useful TypeScript types for your transform functions.

Lastly, you would create a transform function that accepts the WordPress page as before, but will create new document types instead of just returning pages.

migrations/import-wp/lib/transformToPage.ts
import {decode} from 'html-entities'
import type {SanityClient} from 'sanity'
import type {WP_REST_API_Post} from 'wp-types'
import type {Location, Page, Person} from '../../../sanity.types'
// Remove these keys because they'll be created by Content Lake
type StagedPage = Omit<Page, '_createdAt' | '_updatedAt' | '_rev'>
type StagedPerson = Omit<Person, '_createdAt' | '_updatedAt' | '_rev'>
type StagedLocation = Omit<Location, '_createdAt' | '_updatedAt' | '_rev'>
export async function transformToPage(
wpDoc: WP_REST_API_Post,
client: SanityClient,
existingImages: Record<string, string> = {},
): Promise<StagedPage> {
if (wpDoc.template === 'staff.php') {
const doc: StagedPerson = {
_id: `person-${wpDoc.id}`,
_type: 'person',
}
doc.name = decode(wpDoc.title.rendered).trim()
return doc
} else if (wpDoc.template === 'office.php') {
const doc: StagedLocation = {
_id: `location-${wpDoc.id}`,
_type: 'location',
}
doc.name = decode(wpDoc.title.rendered).trim()
return doc
}
const doc: StagedPage = {
_id: `page-${wpDoc.id}`,
_type: 'page',
}
doc.title = decode(wpDoc.title.rendered).trim()
return doc
}

Re-platforming is an excellent opportunity to make huge improvements to your content model and unlock content reuse far beyond just your website.

Courses in the "Replatforming from a legacy CMS to a Content Operation System" track