How to Restore Custom Post Types and Advanced Custom Fields

Custom post types and Advanced Custom Fields represent the pinnacle of WordPress customization, enabling complex content structures far beyond standard posts and pages. When sites utilizing these advanced features go offline, restoration becomes exponentially more challenging than recovering basic WordPress installations. This comprehensive technical guide walks you through the intricate process of identifying, extracting, and restoring custom post types and ACF implementations from Wayback Machine archives.

Understanding Custom Post Types in WordPress

WordPress ships with five default post types: posts, pages, attachments, revisions, and navigation menu items. Custom post types extend this foundation, enabling developers to create specialized content structures for portfolios, products, events, team members, testimonials, case studies, and countless other use cases. Each custom post type functions as its own content silo with dedicated admin interfaces, taxonomies, and template files.

The Architecture of Custom Post Types

Custom post types are registered through WordPress functions, typically in theme functions.php files or dedicated plugins. The register_post_type() function defines post type parameters including labels, public visibility, capabilities, menu positioning, supported features, and permalink structure. Understanding this architecture is fundamental to successful restoration.

register_post_type('portfolio', array(
    'labels' => array(
        'name' => 'Portfolio Projects',
        'singular_name' => 'Portfolio Project'
    ),
    'public' => true,
    'has_archive' => true,
    'supports' => array('title', 'editor', 'thumbnail'),
    'rewrite' => array('slug' => 'portfolio'),
    'menu_icon' => 'dashicons-portfolio'
));

This registration code creates a portfolio post type with archive pages, featured image support, and a custom URL structure. When restoring from archives, you must reconstruct this registration code by analyzing the archived site's URL patterns, template structures, and visible content organization.

Why Custom Post Types Matter for Restoration

Sites leveraging custom post types often represent significant development investments. A real estate site with property listings, a restaurant with menu items, or an agency with team member profiles all depend on custom post types for core functionality. Losing these implementations means losing the entire content structure and administrative interface that made the site functional.

Standard WordPress restoration techniques fail with custom post types because the registration code lives outside the database. Archives capture the rendered output and database content, but not the PHP functions that define post type behavior. Successful restoration requires detective work to identify post types, reconstruct registration parameters, and rebuild the complete implementation.

Identifying Custom Post Types in Archived Sites

Before restoration can begin, you must identify which custom post types existed on the archived site. Multiple investigation techniques reveal this critical information.

URL Pattern Analysis

Custom post types typically use distinctive URL structures that differ from standard post and page patterns. Analyzing archived URLs reveals post type slugs and hierarchy. Look for patterns like:

• /portfolio/project-name/ - Indicates a "portfolio" post type
• /products/category/item-name/ - Suggests a "product" post type with taxonomy
• /team/john-doe/ - Reveals a "team" post type for team members
• /events/2023/conference-name/ - Points to an "event" post type with date hierarchy

Navigate through the Wayback Machine snapshots systematically, documenting every unique URL pattern. Pay special attention to archive pages listing multiple items, as these reveal both the post type slug and associated taxonomies. Category and tag archive URLs for custom post types follow formats like /portfolio-category/web-design/ or /event-tag/conferences/.

HTML Body Class Detection

WordPress automatically adds body classes identifying the current post type. View source on archived single post pages and examine the body tag. Classes like single-portfolio, post-type-archive-portfolio, or portfolio-template-default explicitly name custom post types. This provides definitive confirmation of post type names.

<body class="post-type-archive-portfolio portfolio-archive tax-portfolio-category">

This body class reveals three key details: a "portfolio" custom post type exists, it has archive page functionality, and it uses a custom taxonomy called "portfolio-category". Document every body class pattern you discover across different pages to build a complete post type inventory.

Content Pattern Recognition

Distinctive content layouts indicate specialized post types. Portfolios display project images with client names and categories. Team member pages show photographs with titles and social media links. Event listings include dates, locations, and registration information. These visual patterns help identify post types even when URL structures are ambiguous.

Create a spreadsheet documenting each suspected post type with example URLs, body classes, content patterns, and custom fields you observe. This inventory becomes your blueprint for restoration efforts.

Advanced Custom Fields and Their Database Structure

Advanced Custom Fields revolutionized WordPress development by providing an intuitive interface for creating custom data fields without writing code. ACF stores field configurations in the database and field values as post meta data, creating dependencies that must be understood for successful restoration.

ACF Field Groups Architecture

ACF organizes fields into field groups assigned to specific post types, page templates, or other conditional logic. A portfolio post type might have a field group containing fields for client name, project date, project URL, and technologies used. Field groups are stored as posts with the acf-field-group post type, while individual fields are stored as posts with the acf-field post type.

The relationship structure looks like this:

Component	Storage Location	Purpose
Field Group	wp_posts (post_type: acf-field-group)	Container and location rules
Field Definition	wp_posts (post_type: acf-field)	Field type, label, name, settings
Field Value	wp_postmeta	Actual data for each post

How ACF Stores Field Values

ACF uses a dual-entry system in wp_postmeta for each field value. One entry stores the actual value with a meta_key matching the field name. A second entry with the meta_key suffixed by _field stores the field definition reference. This enables ACF to format and validate data correctly.

INSERT INTO wp_postmeta (post_id, meta_key, meta_value) VALUES
(123, 'client_name', 'Acme Corporation'),
(123, '_client_name', 'field_5f8a3b2c1d4e6');

INSERT INTO wp_postmeta (post_id, meta_key, meta_value) VALUES
(123, 'project_date', '2023-05-15'),
(123, '_project_date', 'field_5f8a3b2c1d4e7');

The underscore-prefixed entries reference field IDs that correspond to posts in the acf-field post type. This referential system ensures ACF displays fields correctly in the admin interface with proper formatting, validation rules, and field types.

Complex ACF Field Types

ACF supports numerous field types beyond simple text inputs: repeater fields for adding multiple value sets, flexible content for custom layouts, gallery fields for multiple images, relationship fields linking posts, and group fields for organizing related data. Each field type stores data differently, with repeater fields using array indexes and relationship fields storing serialized post IDs.

Repeater field data in wp_postmeta uses indexed meta keys:

team_members = 3
team_members_0_name = 'John Doe'
team_members_0_role = 'Developer'
team_members_1_name = 'Jane Smith'
team_members_1_role = 'Designer'
team_members_2_name = 'Bob Johnson'
team_members_2_role = 'Manager'

This complex storage structure makes ACF restoration particularly challenging. You must not only extract field values from rendered HTML but also reconstruct the underlying field group configurations that define how ACF interprets and displays this data.

Extracting Custom Field Data from HTML

Archived HTML contains custom field data in rendered form, but extracting it requires sophisticated parsing techniques that understand both HTML structure and WordPress conventions.

Identifying Custom Field Values in Page Source

Custom fields appear as visible content on frontend pages. A portfolio project might display "Client: Acme Corporation" and "Completed: May 2023" in dedicated sections. These values correspond to ACF fields that need extraction. Look for common patterns:

• Definition lists with <dt>Field Label</dt><dd>Field Value</dd> structure
• Labeled divs like <div class="project-client">Acme Corporation</div>
• Data attributes such as <span data-field="project_date">2023-05-15</span>
• Structured data in Schema.org or JSON-LD format revealing field relationships

Systematic Field Extraction Process

Create a field extraction worksheet for each custom post type. For every archived post of that type, document which custom field values appear and where. After analyzing 10-20 examples, patterns emerge showing consistent field names and data types. This sample size reveals the complete field structure.

Use browser developer tools to inspect HTML elements containing custom field data. Note CSS classes, HTML structure, and surrounding context. Many themes use semantic class names like project-client, event-date, or product-price that directly correspond to ACF field names.

Handling Image and File Fields

Image fields, gallery fields, and file upload fields present special challenges. Archives capture image URLs but not the WordPress attachment IDs that ACF requires. During restoration, you must download images from archives, upload them to WordPress media library, and store the resulting attachment IDs in custom field entries.

Gallery fields store arrays of attachment IDs in serialized format:

project_gallery = 'a:3:{i:0;i:142;i:1;i:143;i:2;i:144;}'

This serialized string represents three attachment IDs. After restoring images and obtaining new attachment IDs, recreate these serialized arrays with the correct format and byte counts to ensure ACF recognizes them properly.

Recreating Custom Post Type Registration Code

With post types identified and custom fields documented, the next challenge is recreating the PHP registration code that makes WordPress recognize these custom post types.

Building Registration Functions

Create a custom plugin to house post type registrations rather than placing code in theme files. This ensures post types remain available even when switching themes. The plugin structure should include an initialization hook:

function restored_site_register_post_types() {
    register_post_type('portfolio', array(
        'labels' => array(
            'name' => 'Portfolio Projects',
            'singular_name' => 'Portfolio Project',
            'add_new' => 'Add New Project',
            'add_new_item' => 'Add New Portfolio Project',
            'edit_item' => 'Edit Project',
            'view_item' => 'View Project',
            'all_items' => 'All Projects'
        ),
        'public' => true,
        'has_archive' => true,
        'show_in_rest' => true,
        'supports' => array('title', 'editor', 'thumbnail', 'excerpt'),
        'rewrite' => array('slug' => 'portfolio', 'with_front' => false),
        'menu_icon' => 'dashicons-portfolio',
        'capability_type' => 'post'
    ));
}
add_action('init', 'restored_site_register_post_types');

Determining Registration Parameters

Each registration parameter must be inferred from archived evidence. The has_archive parameter is true if archive pages like /portfolio/ existed. The rewrite slug comes from URL patterns. The supports array lists features available in the editor, which you can determine by examining post edit screens in archives if admin pages were captured.

Common registration parameters include:

• public: Usually true for any publicly visible post type
• exclude_from_search: False if posts appeared in search results
• publicly_queryable: True if individual posts were accessible
• show_ui: True creates admin interface for managing posts
• show_in_menu: True adds top-level admin menu item
• menu_position: Controls menu ordering, typically 5-100
• hierarchical: True if posts had parent-child relationships like pages

Custom Taxonomy Registration

Custom post types often use custom taxonomies for categorization beyond standard categories and tags. Register these using register_taxonomy() with similar parameter inference from archived URL patterns and content structure:

function restored_site_register_taxonomies() {
    register_taxonomy('portfolio_category', 'portfolio', array(
        'labels' => array(
            'name' => 'Portfolio Categories',
            'singular_name' => 'Portfolio Category'
        ),
        'hierarchical' => true,
        'show_in_rest' => true,
        'rewrite' => array('slug' => 'portfolio-category')
    ));
}
add_action('init', 'restored_site_register_taxonomies');

Advanced Custom Fields Restoration Process

Restoring ACF functionality requires both recreating field group definitions and populating field values from extracted data.

Manual ACF Field Group Recreation

Install Advanced Custom Fields plugin on your restored site. Using your field extraction documentation, manually recreate each field group through the ACF interface. For a portfolio post type, you might create a field group called "Portfolio Details" with fields:

• Client Name (text field)
• Project Date (date picker)
• Project URL (URL field)
• Technologies Used (checkbox field)
• Featured (true/false field)

Configure field names to match the meta keys you observed in your extraction analysis. If archived pages showed a client name and HTML inspection revealed class names like project-client, name the ACF field client_name or project_client to match WordPress naming conventions.

Setting Location Rules

ACF field groups use location rules to determine where they appear. Set rules to display your "Portfolio Details" field group only when editing portfolio post types. This prevents fields from appearing on standard posts or pages where they don't belong.

Location rules support complex logic: show fields when post type equals portfolio AND category is web-design, or show fields when page template equals portfolio-template.php. Match these rules to how the original site organized content.

Programmatic ACF Import

For sites with extensive ACF configurations, manually recreating dozens of field groups becomes impractical. ACF supports JSON export and import for field groups. If you can reconstruct field group configurations programmatically from your extraction data, export them as JSON and import into WordPress.

ACF field group JSON structure:

{
    "key": "group_portfolio_details",
    "title": "Portfolio Details",
    "fields": [
        {
            "key": "field_client_name",
            "label": "Client Name",
            "name": "client_name",
            "type": "text",
            "required": 1
        }
    ],
    "location": [
        [
            {
                "param": "post_type",
                "operator": "==",
                "value": "portfolio"
            }
        ]
    ]
}

Populating Field Values

With field groups configured, populate values by inserting data into wp_postmeta. For each portfolio post, create meta entries for each custom field value you extracted from archives. Remember to include both the value entry and the field reference entry:

INSERT INTO wp_postmeta (post_id, meta_key, meta_value) VALUES
(123, 'client_name', 'Acme Corporation'),
(123, '_client_name', 'field_client_name'),
(123, 'project_date', '20230515'),
(123, '_project_date', 'field_project_date'),
(123, 'project_url', 'https://example.com'),
(123, '_project_url', 'field_project_url');

Date fields require YYYYMMDD format. URL fields need complete URLs with protocols. Checkbox and select fields use serialized arrays for multiple values. Refer to ACF documentation for field-specific formatting requirements.

Testing Complex Custom Post Type Implementations

Thorough testing ensures restored custom post types function correctly before deploying to production environments.

Frontend Display Verification

Visit single post pages for each custom post type and verify content displays correctly. Check that custom fields appear in expected locations with proper formatting. Test archive pages to confirm post listings work properly. Navigate taxonomy archives to ensure categorization functions correctly.

Compare restored pages against archived snapshots side-by-side. Visual discrepancies indicate missing custom fields, incorrect template files, or incomplete data restoration. Screenshots of archived pages serve as reference materials for achieving visual parity.

Admin Interface Testing

Access the WordPress admin and edit custom post type entries. Verify that ACF field groups appear correctly with all fields present. Test that field values load and save properly. Check that field validation works as expected for required fields, format restrictions, and conditional logic.

Create new posts of each custom post type to ensure registration parameters support all necessary features. Test featured images, custom taxonomies, post excerpts, and other WordPress features your post types use.

Query and Loop Testing

Many themes and plugins query custom post types using WP_Query or get_posts(). Test these queries by viewing pages that loop through custom post type content. Check that correct posts appear, ordering works properly, and pagination functions correctly.

Test REST API endpoints if your site uses them. Custom post types with show_in_rest enabled should appear at /wp-json/wp/v2/portfolio endpoints. Verify JSON output includes all expected data and custom fields if exposed via REST.

Common Issues and Solutions

Custom post type and ACF restoration encounters predictable challenges with established solutions.

Issue: Permalink 404 Errors

Symptom: Custom post type URLs return 404 errors despite posts existing in the database.

Cause: WordPress hasn't flushed rewrite rules after custom post type registration.

Solution: Navigate to Settings → Permalinks in WordPress admin and click "Save Changes" without modifying anything. This flushes rewrite rules and regenerates permalink structures. Alternatively, programmatically flush rules in your plugin activation hook using flush_rewrite_rules().

Issue: ACF Fields Not Appearing

Symptom: Custom fields don't display in post editor even though field groups are configured.

Cause: Location rules don't match the current editing context, or field group is set to inactive.

Solution: Edit field group location rules to ensure they match your post type. Verify the field group status is "Active" rather than "Inactive". Check for plugin conflicts by deactivating other plugins temporarily.

Issue: Incorrect Field Data Types

Symptom: Field values appear as serialized strings or arrays rather than formatted data.

Cause: Mismatch between field type and stored value format.

Solution: Review field type configurations in ACF. Ensure repeater fields store indexed arrays, relationship fields store post ID arrays, and simple fields store scalar values. Use get_field() function to retrieve formatted values rather than accessing wp_postmeta directly.

Issue: Missing Image Attachments

Symptom: Image fields show broken images or no images despite URLs in database.

Cause: ACF image fields expect attachment IDs, but restoration inserted URLs or old attachment IDs.

Solution: Download images from archives, upload to media library, and update custom field entries with new attachment IDs. Use media handling functions to programmatically upload images and retrieve attachment IDs during bulk restoration.

Automated Restoration with ReviveNext

Manual custom post type and ACF restoration requires deep WordPress expertise and dozens of hours for complex sites. ReviveNext automates the entire workflow, dramatically reducing restoration complexity and timeline.

The platform analyzes archived sites to identify custom post types through URL pattern recognition, body class detection, and content structure analysis. It extracts custom field values from rendered HTML using machine learning-enhanced parsing algorithms trained on thousands of WordPress themes. Database reconstruction includes proper post type values, custom taxonomy relationships, and meta data entries formatted correctly for ACF.

For sites using Advanced Custom Fields, ReviveNext extracts field values and provides structured data export that can be imported into ACF field groups. While field group configuration still benefits from human review to ensure proper field types and validation rules, ReviveNext eliminates the tedious extraction and data population phases.

Frequently Asked Questions

Q: Can custom post types be restored without access to the original theme or plugin that registered them?
A: Yes. Custom post type registration is just PHP code that can be recreated by analyzing the archived site's URL structure, body classes, and content patterns. You create new registration code that replicates the original functionality even without access to the original implementation.

Q: Will ACF field groups be automatically restored from Wayback Machine archives?
A: Field group configurations (the definitions of what fields exist) are stored in the database but rarely captured in public archives since they live in WordPress admin areas. However, field values (the actual data) appear in rendered HTML and can be extracted. You recreate field group configurations manually or programmatically, then populate them with extracted values.

Q: What happens if I can't determine all the parameters for custom post type registration?
A: Start with basic parameters (labels, public visibility, rewrite slug, supports) that you can definitively determine from archives. Deploy with these minimal settings and refine over time as you discover additional requirements. WordPress defaults provide reasonable behavior for unspecified parameters.

Q: How do I handle custom post types that used custom taxonomies not visible in archives?
A: If taxonomy archive pages weren't captured, you may not discover all taxonomies. Use database inspection if you have partial database dumps, or recreate standard taxonomies (categories and tags) which cover most use cases. Custom taxonomies can be added later if evidence of their existence surfaces.

Q: Can I restore ACF Pro features like repeater fields and flexible content?
A: Yes, but it requires ACF Pro installation on your restored site. Repeater field data can be extracted from repeated HTML patterns on archived pages. Flexible content requires analyzing layout variations to determine content components. The complexity increases significantly with these advanced field types, but restoration remains possible with careful analysis.

Q: What if the site used a custom post type plugin like Custom Post Type UI?
A: The restoration approach is identical. Whether post types were registered via plugin, theme, or custom code, the result in the database and URL structure is the same. Install the same plugin or recreate the registration manually. Plugins like CPT UI provide GUI interfaces that simplify re-registration without writing code.

Q: How do I restore custom post types that had complex relationships with other post types?
A: ACF relationship fields and plugins like Posts 2 Posts create post-to-post connections stored in postmeta or custom database tables. Analyze archived pages showing related content, document which posts link to which others, then recreate these relationships in the restored database. This manual mapping is time-intensive but necessary for preserving content relationships.

Q: Will custom post type REST API endpoints work after restoration?
A: If you include 'show_in_rest' => true in post type registration, REST API endpoints are automatically generated. Test endpoints at /wp-json/wp/v2/your-post-type to verify functionality. ACF fields require ACF to REST API plugin or custom code to expose field data via REST.

Q: Can ReviveNext restore sites with dozens of custom post types and hundreds of ACF fields?
A: Yes. ReviveNext scales to handle complex WordPress implementations with extensive custom post types and ACF configurations. The automated extraction and database reconstruction process works regardless of implementation complexity, though sites with more custom post types and fields naturally require more processing time and human review for optimal results.

Conclusion

Restoring custom post types and Advanced Custom Fields from Wayback Machine archives represents advanced WordPress recovery requiring technical expertise, systematic investigation, and patient reconstruction. The rewards justify the effort: recovering complex content structures that took months to develop originally, preserving unique functionality unavailable in standard WordPress, and restoring sites to full operational capability.

Success depends on methodical analysis to identify custom post types, careful extraction of custom field data from rendered HTML, accurate recreation of registration code, proper ACF field group configuration, and thorough testing of the complete implementation. Each step builds upon the previous, creating a complete restoration that mirrors the original site's sophisticated content architecture.

For WordPress developers and agencies working with expired domains, disaster recovery, or legacy site preservation, mastering custom post type and ACF restoration opens opportunities to recover seemingly lost implementations and deliver results that manual reconstruction could never achieve in reasonable timeframes.