CodeCanyon WordPress API Posts and Pages Sync - WordPress Plugin

A Setup Guide to CodeCanyon WordPress API Posts and Pages Sync for Independent WordPress Sites

CodeCanyon WordPress API Posts and Pages Sync handles a narrow but highly practical task: one site becomes the place where an editor creates and revises content, while several other independent WordPress installations receive a consistent copy. This guide covers more than installation and the Sync button. It explains how responsibility is divided between sites, how to prepare credentials, when to use automatic or manual mode, how to send an older archive in bulk, how to check media and taxonomies, how to handle deletions safely, and how to track down API errors.

Here, synchronization does not mean backing up or migrating an entire site. The plugin works with posts and pages, along with the related data it supports transferring: categories, tags, media, and some metadata. It does not combine several independent sites into one shared database, resolve conflicting editorial rules on its own, or eliminate the need to test each recipient's theme.

The steps below assume that you can access the admin dashboards for all the sites and have a regular backup in place before making significant changes. A sensible way to start with this plugin is to connect two test installations and send one draft post, then enable an ongoing workflow. That sequence only seems slow until the first time someone selects the wrong recipient or a deletion setting affects a live site.

Where the Plugin Helps, and Where It Adds Risk

The product is designed for independent WordPress sites on different domains or hosts, not sites within one WordPress Multisite network. This distinction matters. Each site has its own admin dashboard, users, and database. The plugin sends content through an API rather than accessing the network's internal tables. That makes it suitable for a group of regional sites, a network of branch locations, a primary site with publishing destinations, or a central editorial team that prepares the same reference pages for several independent projects.

The simplest example is an editor publishing news about a new service on the primary site. The same post, including its title, text, categories, tags, and featured image, needs to appear on two branch sites. Instead of copying it into three editors by hand, one site serves as the source and the other two as recipients. When the original post is revised, you can send the update again without having to track down every duplicate manually.

Good fits

• A shared editorial source for several independent brand or branch sites.
• Distributing press releases, instructions, blog posts, and static pages from a controlled source.
• Gradually populating a new site with approved content through bulk synchronization.
• Manually sending one post when the content is needed by only selected recipients.
• Maintaining a knowledge base where the main article is prepared centrally and sent to local sites as source material for their audiences.

When to pause and choose a different approach

Do not use this plugin to migrate an entire site. Themes, menus, page-builder settings, users, forms, comments, caching rules, and SEO settings do not become identical automatically just because a post was transferred. A full-site move requires a separate migration process. You should also avoid automatic delivery to sites where editors deliberately rewrite incoming content for local audiences: a later source update could replace those local edits with the central version.

Do not confuse independent sites with WordPress Multisite. If all your projects are already part of one network, a dedicated Multisite synchronization plugin is a more natural fit. Its permissions model and site connections work differently. CodeCanyon WordPress API Posts and Pages Sync makes sense when independent installations are a requirement, not a limitation.

The Transfer Path: From a Post Edit to the Published Page

It helps to think of the plugin as a four-step chain. First, an editor creates or changes the source content. The selected mode then determines when delivery starts: immediately after saving or after an explicit action by the editor. The settings for each recipient determine which related data can be sent and where the content is allowed to go. Finally, the remote WordPress site accepts the request and creates or updates its post or page. You verify the visible outcome on the recipient's public site, while technical failures appear in the API Error Logs section.

This breakdown helps you avoid fixing a symptom in the wrong place. If a post appears on the recipient but has the wrong category, the theme is not necessarily at fault. If the post does not appear at all, check the site connection, URL, credentials, and logs before clicking Sync dozens of times. If the post appears with unexpected local blocks, determine separately which elements belong to the post content and which are added by the active theme or another plugin.

Content types supported for transfer

The official product description identifies posts and pages as the main content types the plugin synchronizes. For posts, it lists categories and tags. Media, including featured images, is also supported when synchronizing a post or page. The settings include exclusions for post metadata and term metadata, so you can limit what is transferred to each connected site.

Advanced Custom Fields support is not a blanket guarantee for every configuration. The listed field types are text, text area, number, email, password, WYSIWYG editor, select, checkbox, radio button, true/false, map, date, color, and message. Treat fields outside that list, especially complex composite fields and nested relationships, as something you need to test. Do not transfer a live catalog, legally important page, or large archive until you have confirmed on a copy that the specific fields you use are preserved as needed.

The key prelaunch check: use a separate test installation as the recipient and give the test post distinctive features: a unique title, one category, one tag, a featured image, and a short passage of text. That makes it easy to see which part of the transfer chain did not work.

Prepare Both Sites Before Installing

The safest way to start is to sketch a simple map of roles. Name the source, each recipient, the responsible editor, and the rule that determines which content goes to which site. For example, the main editorial site might send general news to regional versions, while regional service pages stay local. This map is not bureaucracy. It keeps the list of connections from turning into a confusing set of similar domains where one wrong checkbox changes content on an unexpected site.

What to check on each site

1. Make sure each site is available at a stable address and that an administrator can sign in to its dashboard.
2. Check that the standard WordPress REST API works on the source and recipients, and that security plugins, proxies, and server rules do not block the required requests.
3. On each recipient, open Settings → Permalinks, choose a permalink structure other than Plain, and save the settings. The plugin's instructions specifically recommend Custom Structure, such as Post name.
4. Confirm that the required categories and tags can be created and that local formatting rules do not require fields missing from the source.
5. Back up the database and uploads directory, or work on a site copy. This is essential before bulk transfers and especially before enabling deletion syncing.
6. Prepare a separate test post and capture its original state in a screenshot or editorial log.

Permalinks matter here for more than appearance. WordPress uses predictable routes to access objects and public pages. After changing the structure, click Save Changes and open a regular post on the recipient. If it returns a 404, fix the permalink settings and server rules before adjusting metadata exclusions in the plugin.

Connection account

The plugin's instructions specify a URL, username, and remote WordPress administrator password in the site connection form. Do not put these credentials in an article, email, screenshot with the field visible, or shared chat. For each connection, consider creating a separate technical account on the recipient, naming it by role, storing its password securely, and removing or replacing its access when the connection is no longer needed. Give the plugin only the permissions required to create or update the relevant posts.

Modern WordPress supports application passwords for some external API use cases, but this product's instructions describe Username and Password fields and do not confirm support for an alternative authentication method. Do not assume you can substitute a different setup. If your security policy prohibits using a user's password for this integration, test the connection in a controlled environment and agree on an approach with the site owners first.

Install the Plugin and Run the First Safe Test

On every participating site, upload the ZIP file through Plugins → Add New → Upload Plugin, then install and activate the extension. The product's instructions also allow you to place the plugin folder manually in /wp-content/plugins/. For most administrators, uploading it through the dashboard is more convenient: WordPress shows the installation status and lets you confirm that the extension appears in the plugin list.

Site roles do not remove the need to install the plugin. In a one-way setup, the source uses all the configuration sections, while the recipient also needs the plugin installed and active to accept content. After activation, do not start with an archive transfer. Find Content Sync in the admin dashboard, confirm that the Sites, Settings, Bulk Sync, and API Error Logs sections are visible, and only then connect a test recipient.

First controlled transfer

Create a new draft or test post with a distinctive title, such as one that starts with SYNC-TEST. Add a short passage, a category, a tag, and one featured image. The post should not matter to site visitors. Its purpose is to test content creation, taxonomies, media, and theme display at the same time. In manual mode, send it when you choose; in automatic mode, save a change after the connection and settings are ready.

After synchronization, open the recipient's post list, find the test post by its unique title, and check its status, author, category, tags, image, and public page. Do not rely only on a success message on the source. Success means the recipient shows the expected outcome, not simply that someone clicked the button.

Connect Recipients in the Sites Section

In Content Sync → Sites, create a connection card for each recipient. Enter the site's exact base URL, add the credentials, and save the connection. Avoid nearly identical addresses unless you have a naming convention to distinguish them. If a project has both a live and a test site, label them so editors can tell them apart before selecting a destination. An extra path, temporary domain, or incorrect protocol can cause an authentication failure or send data to the wrong environment.

Site status and when to pause a connection

Each connected site has a status that enables or disables synchronization. It is not just a visual label. If a recipient is undergoing local work, a redesign, a domain move, or conflict resolution, disable the connection in its site card first. You can then continue editing the source without the automatic mode sending new changes to an unstable environment. When the work is done, re-enable the connection, run one controlled manual test, and only then decide whether to catch up on older content with a bulk transfer.

Exclude metadata without changing the meaning of the post

For each recipient, you can list metadata keys that should not be sent with a post. The instructions list common tokens such as date, date_gmt, content, excerpt, featured_media, categories, and tags, as well as custom keys. Enter values separated by commas, without spaces. The important point is not to memorize the list, but to understand the effect: an exclusion changes the data sent to that specific recipient.

Start with an empty list and add a key only when you have a clear requirement. A local site, for example, may need its own category or featured image. An exclusion can make sense in that case, but the editor must then verify that the other data still transfers. Do not paste a long list of keys from an unverified tip: that can undermine synchronization and leave you guessing why the recipient has no excerpt or has lost its image.

Use categories and tags as editorial rules

The site settings include checkboxes for excluding posts in selected categories and tags. This is more reliable than hoping an editor always remembers a local restriction. For example, technical notes may be allowed on the primary site but not on a regional blog. Add that category to the exclusion for the relevant recipient, then create a test post in that category and confirm that it does not appear there. Next, test a regular post without the excluded category and confirm that it does transfer.

Do not use exclusions as a hidden way to resolve an editorial conflict. If a site needs a different version of the text, a different title, or different legal wording, set up a separate local workflow. Excluding a field is useful only when the outcome is predictable and easy to verify.

Configure the Sync Mode, Content Types, and Authentication

Content Sync → Settings controls the behavior of the source installation. Here you choose the transfer mode, enable or disable Posts and Pages, select an authentication option, and decide whether deletions should be synchronized. Configure these options on a test pair first. This is the level where one global setting can affect every edit an editor saves afterward.

Auto Sync: when automation makes sense

With Auto Sync, the plugin sends a post or page when it is created or updated. This mode is useful when the source is the sole owner of the content, recipients are not edited manually, and delays are unacceptable. It works well for short news updates, centrally managed policies, shared service information, and regular content that needs to match across all publishing destinations.

Automation comes with a tradeoff: every save can become an external change. An editor might fix a typo, temporarily replace an image, open a post to review it, or save an incomplete draft. Before enabling Auto Sync, agree on publication statuses, how drafts are handled, and who can edit the source. For the first few days, route automatic updates only to a test recipient.

Manual Sync: when control matters more than speed

In Manual Sync, the editor opens a specific post or page, finds the WordPress API Content Sync section, selects the recipient sites, and clicks Sync. This is a sensible mode for content that a regional team will revise, important pages that require several checks, and the initial rollout. It makes delivery a deliberate editorial step: the author checks the content, chooses the recipients, and only then sends the update to other sites.

Manual mode still needs a clear process. Add a short check to the editorial record: title, main content, image, category, tags, and recipient list confirmed. That way, Sync is not a mysterious action but the final step in a defined review.

Header and Query String Parameters

The product documentation allows Header and Query String Parameters authentication options. It specifically recommends setting Query String Parameters in the source configuration. Do not choose an option just because it seems more modern or familiar. Start with the method recommended for this product on a test pair, confirm that it works, and consider switching only if your infrastructure requires it and a new transfer test succeeds.

Authentication is not a reason to experiment by disabling protection. If requests are blocked, do not turn off every security plugin on a live site or open access to all visitors. First check the error in API Error Logs, then verify the URL, account, permissions, HTTPS, and relevant server or security-layer rules. Change one factor at a time and repeat the original test after each fix.

Make a separate decision about syncing deletions

The Sync on post/page delete? setting can send deletions: moving an item to the source's trash also moves it to the recipient's trash, while permanently deleting the source permanently deletes the recipient copy. This can be useful for a fully centralized editorial team, but it is risky when recipients maintain their own additions to the content.

Leave deletion syncing off at first. Enable it only after a separate test on a test post, confirmation of a recovery plan, and a clear rule about who can delete the source. If you are unsure, it is safer to leave the connection one-way for creation and updates, and handle deletions manually after checking for dependent pages.

Bulk Sync Without Creating Archive Chaos

Content Sync → Bulk Sync is for controlled work with older content, not routine small edits. Here you can choose posts or pages, a category, a tag, and the number of entries per page, apply Filter, select specific rows, choose recipients, and start Sync. This lets you narrow the transfer to a manageable group instead of sending the entire site in one action that is difficult to reverse.

Choose a safe size for the first batch

Start with a small topic group, not hundreds of posts. Include content with different structures: a standard article, a post with multiple categories, a tagged post, a post with a featured image, and a page. After sending them, inspect each type on the recipient. You will learn whether categories, images, and theme display are handled correctly while any error affects only a few test items.

If the archive contains outdated URLs, old shortcodes, or dependencies on a previous theme, do not assume they are synchronization problems. Separate the two tasks: the plugin should transfer the data it supports, and the recipient's theme and other extensions should display that data in their environment. Sometimes a successful transfer produces a post that still needs local adjustments.

How to work with filters

1. Choose one content type and one clear category or tag.
2. Set a reasonable number of posts per page so you can review the full list before sending.
3. Click Filter and read each row's title instead of selecting everything automatically.
4. Select a batch, choose one test recipient, and start the transfer.
5. Check the outcome and the error log, then expand the recipient list or move on to the next batch.

This approach is especially important when exclusions are in use. If some posts do not transfer, do not immediately assume the button is broken. The selected category or tag may be excluded for that recipient. In that case, the missing post means the rule is working as intended, not that you should weaken security or retry blindly.

Example: One Central Article for Three Independent Sites

Imagine a network with one primary editorial site and two local sites. The central team needs to publish instructions that describe a new service procedure consistently. The local sites use different themes but follow the same category rules: the post should go in News, receive the service tag, and display a featured image. Local teams may add their own contact block later, so that block should not be part of the central article.

Goal and setup

The goal is to create the same base post on both recipients without changing their themes or affecting other categories. The plugin is installed and active on the source and recipients. Both recipients have saved permalink settings and separate technical accounts. Two separate connection cards have been added under Sites. The team chooses Manual Sync because the article needs an internal review first.

Transfer the post step by step

1. On the source, create an article with a clear title, text, category, tag, and featured image.
2. Save it as a draft and review its preview on the source site.
3. Open the WordPress API Content Sync section in the post editor.
4. Select both local sites as recipients and compare their names with the editorial map.
5. Click Sync, wait for it to finish, and do not edit the post in another tab at the same time.
6. Open each recipient's dashboard in turn, find the post, and check its status, title, main text, category, tag, and featured image.
7. Open the public pages in separate windows to check how the active themes display the posts, not just what appears in the editors.

If a local team adds a contact block afterward, document the rule: a later central update must not overwrite it blindly. There are two sound ways to handle this. Store the local content outside the synchronized field and display it through the site's template, or send central updates manually only after they have been reviewed. Trying to combine automatic full-content matching with independent editing of the same field creates predictable conflicts.

What counts as a complete result

A complete result is more than two posts with the same title. On each recipient, open the post in the dashboard and its public page. Compare the main text, category, tags, image, permalink, date according to your editorial policy, and any unexpected blocks. Then make a noticeable, low-risk change on the source, such as adding a sentence, and send the post again manually. If the change appears on both recipients, you have tested both creation and updates to existing content.

Check Media, Taxonomies, and Custom Fields

Media and taxonomies often reveal weak spots before ordinary text does. A post may appear to transfer successfully, yet its public page shows an empty space where the image should be or an unfamiliar category. Check from simple to complex: first a post with no exclusions, then one with an image, then categories and tags, and finally a limited set of custom fields.

Check the featured image and attachments

After the first transfer, confirm that the image appears not only in the post editor but also in the recipient's media library, opens when clicked, and displays in the post template. If the recipient's theme uses a special crop, that does not necessarily mean the plugin damaged the file. First inspect the original file in the media library, then check the theme's image-size settings. Also confirm that featured_media is not excluded for that site.

Categories and tags

Prepare one unique category and one unique tag for the test post. After sending it, confirm that they are assigned to that post and have not been replaced by a local term with the same name but a different meaning. If the sites use different languages or editorial classifications, agree on a shared vocabulary first. The plugin can transfer a category, but it cannot decide for the team whether News represents the same business concept on both sites.

Custom fields and ACF

For ACF, create a separate test post and fill in one or two of the simple supported types, such as a text field and a toggle. Check the values in the recipient's editor and wherever the theme displays them. Then test each other required type individually. Do not add a complex structure to a bulk transfer until you know how it behaves. This is not caution for its own sake: a custom field often controls an important part of a template, and a blank value can break the appearance of a card, map, or page block.

If a recipient needs to keep its own local value, use the metadata exclusion and repeat the test. Check the exact outcome you want: the central text should update while the local field stays unchanged. One successful transfer without custom fields does not prove that a complex page is compatible.

Working Rules for the Source and Recipient Sites

Technical setup does not answer the main editorial question: which site is the source of truth? CodeCanyon WordPress API Posts and Pages Sync cannot understand the business meaning of each edit. It transfers content according to the rules you configure. Before enabling an ongoing workflow, document a few simple rules for the team. They do not require a separate project-management system, but they help prevent two editors from treating the same post as their own.

Assign an owner to each layer of content

Divide the page into layers. The main text, title, excerpt, categories, tags, and base image usually belong to the central source. A contact block, local form, regional phone number, banner, or link to a local service may belong to the recipient. If all these elements are stored in the same editor field, an automatic update cannot tell shared content from local content. In that case, switch to manual mode or move the local element into a field that is deliberately excluded for that recipient.

This rule is useful even when there are only two sites. Suppose the central team updates an article while the local team adds office hours at the end. If the hours are part of the main content, a later source update may erase them. If they are displayed through a separate local field or theme block, the central post can be updated without a conflict. Define the boundary between shared and local data before enabling automation.

Keep a minimal transfer log

For important content, record four things: the source post title, the date and time it was sent, the recipients, and who checked the outcome. This does not need to become a lengthy report. One row in an editorial spreadsheet can help when differences between sites turn up a week later. It shows whether the post was sent, where it went, and which version was approved.

A log is especially useful after a bulk sync. A filter may return many posts, but a technically successful operation does not replace spot checks. Record the batch boundaries, such as the category, tag, and list pages included. If you later need to retry one post, you will not have to send the entire archive again because the context of the first transfer was lost.

Set a rule for publication statuses

WordPress has published, scheduled, draft, pending review, and private posts. Test the plugin with the statuses your team actually uses. Start with a regular published post, and test a draft separately if it matters to your workflow. On the recipient, check not only whether the post exists but also whether visitors can see it. If a test draft unexpectedly becomes public, or the reverse, stop automatic syncing, document the condition, and build the workflow around behavior you have confirmed.

Keep synchronization separate from translation and localization

When sites use different languages, a central post in one language is rarely ready to publish as-is in another. The plugin can deliver structure, source data, or a base text, but it does not translate content, choose local terminology, or check legal wording. In this setup, synchronize only content that truly needs to be identical, and define a separate editorial path for translated pages. Using one field as both the source and the localized version creates the same kind of conflict as a local contact block, only on a larger scale.

A quick decision matrix

Choosing a mode and rule for common use cases

Situation	Recommended setup	What to check
General news belongs entirely to the central editorial team	Auto Sync after a successful test period	Intermediate saves do not reach live sites
An important page needs review before it is sent	Manual Sync with recipients selected explicitly	Title, media, categories, and public display
The recipient keeps its own contact block	A local field or a data exclusion that has been tested	A source update does not erase the local content
An older blog section needs to be transferred	Bulk Sync in small, filtered batches	The first batch and the outcome for different post types
Editors change the same post on both sites	Assign field ownership first, then test a two-way setup	What happens when changes are made in sequence or at the same time

This table does not replace testing your specific installation, but it helps prevent a dangerous assumption: that one toggle fits every editorial model. In this plugin, the transfer mode is part of the publishing workflow, not just a technical detail.

Compatibility with Themes, Caching, and the Block Editor

The plugin creates or updates WordPress data, while the recipient's theme, templates, and other extensions determine how that data looks. The same post can therefore look different on two sites even when the transfer worked correctly. One theme may show the featured image above the title, while another hides it on pages; one template may display tags, while another does not use them at all. Check data and presentation separately: first confirm the values in the recipient's editor, then investigate the template if the public page does not match expectations.

Make sure caching is not hiding the update

After synchronization, the public page may still look unchanged because it is being served from the theme, server, or CDN cache. Do not start by removing the connection or changing credentials. First open the post in the recipient's dashboard and check its actual text. If the editor shows the new version but the public page is old, clear the cache through the site's normal procedure and reopen the page in a new window. Then check whether categories, archives, or images are cached separately.

Do not disable caching across a live site just to check one update. It is safer to clear the specific page's cache and record which layer delayed the change. If it happens repeatedly, add cache clearing to the editorial checklist after each transfer. The plugin is not described as a cache-management tool, so do not expect it to handle another system's job.

The block editor and complex page elements

Standard WordPress blocks are part of the post content, but a complex page may depend on the theme template, custom fields, shortcodes, or extensions. Transferring the text does not prove that the recipient will reproduce the full layout. Take a page with one important element, such as a gallery, table, CTA block, or custom field, and test it separately. Record where the relevant value is stored: in the main content, metadata, theme settings, or another extension.

If an element depends on a local plugin, install and configure that plugin on the recipient through the standard process first. Do not use content synchronization to transfer someone else's settings or code. This keeps responsibilities clear: CodeCanyon WordPress API Posts and Pages Sync handles the supported post data, while the recipient's environment is responsible for displaying it.

Test carefully on a site copy

If you need to investigate PHP warnings or a theme conflict, do it on a site copy. WordPress provides a debug mode for development, but displaying errors on a live public site can expose technical details to visitors. Use diagnostic tools only in a test environment, record what you observe, and return to normal mode after the test. This is safer than guessing from a blank page or enabling every debugging option on a live recipient.

Updates, Deletions, and Two-Way Sync Without Conflicts

Updating an existing post is a normal plugin task, but it carries the most editorial responsibility. In automatic mode, each source save can send a new version. In manual mode, the editor chooses when to send it. In either case, it helps to define a simple rule: the source owns the base content, while the recipient either publishes it as-is or maintains a clearly defined local part.

Why a two-way setup needs its own plan

The product documentation describes support for two-way synchronization, but it does not promise that the plugin will understand the meaning of two simultaneous edits. Suppose an editor changes the first paragraph on the source while an editor on the recipient adds a local notice. Both changes may be technically valid, but the editorial question of which version takes priority remains. Before enabling two-way syncing, decide who owns each post, when edits are locked, and how conflicts are resolved.

For most small teams, it is safer to start with a one-way setup: the central site sends content outward, and recipients do not edit synchronized fields. If you genuinely need a two-way connection, use a separate test pair, try creating and updating unimportant posts in both directions, and log which site made the most recent change.

Deletion and the trash

Enable the deletion setting only when you have a clear policy. A good practice is to treat moving a post to the trash on the source as a signal to review it, not as an automatic command to destroy the content on every recipient. Until the team has accounted for all local dependencies, leave deletion syncing off. If you do enable it, test both events separately: moving a post to the trash and permanently deleting it. Then check each connected site and confirm that your team can restore the test post from a backup.

Troubleshoot with API Error Logs and a Test Post

The plugin has a dedicated Content Sync → API Error Logs section that displays WordPress API errors. Start there if a post is not created or updated. The log is more useful than repeated clicks because it helps show whether the issue is with the request between sites rather than the page's appearance.

Before investigating an error, repeat the operation with one test post and one recipient. Record the exact time, selected site, mode, content type, and most recent settings change. Then read the log in context: authentication errors usually point to access or credentials, route errors to the URL or permalink settings, and a display mismatch after a successful transfer to the theme, fields, or local rendering rules.

Common Sync Failures and Safe Ways to Fix Them

The post does not appear on the recipient

Symptom: After a manual or automatic transfer, the expected post is missing from the recipient's post list. Likely causes: An incorrect URL in Sites, invalid credentials, a disabled connection, a blocked API, or a category or tag exclusion. What to check: Start with API Error Logs, then compare the URL and account with your test details, check the site's status, and review the test post's properties. Fix: Correct one variable, send the post to one recipient, and confirm that it appears. If the change made the outcome worse, restore the previous value and do not continue with a bulk transfer.

The text arrives, but the image is missing or the category is wrong

Symptom: The post exists, but its public page has no featured image or shows it under the wrong category. Likely causes: A field related to media or taxonomies is excluded, the recipient's theme displays a different image size, or the sites use different category vocabularies. What to check: Open the post and media library in the recipient dashboard, then check the site's card in Sites. Compare metadata exclusions and the selected categories and tags. Fix: Remove only an exclusion you have confirmed is unnecessary, resend the test post, and check the dashboard before the public template. If the local category must remain independent, restore the exclusion and document it as a permanent rule.

Automatic mode sends draft changes too early

Symptom: Recipients get an intermediate draft, temporary image, or unfinished page. Cause: Auto Sync responds to additions and updates, while the editorial process does not distinguish a working save from an approved version. What to check: Confirm the mode in Settings and review who edits the source. Fix: Switch to Manual Sync until the team has agreed on an editorial rule, or route automatic updates to a test site first. To roll back, return to manual mode and restore the last approved version on the recipient.

A new permalink structure returns a 404

Symptom: The post appears in the recipient dashboard, but its public URL does not open. Cause: Permalink settings or server rules were not applied. What to check: In Settings → Permalinks, choose a working structure, save the changes, and open the test post. Fix: Confirm that WordPress and the hosting server saved the rules. Do not change the site URL, sync settings, and theme at the same time. To roll back, restore the previous working structure if the change caused widespread 404s.

A local edit disappears after a source update

Symptom: An editor on the recipient adds content, but the next transfer restores the base version. Cause: Both teams consider themselves the owner of the same field. What to check: Find out whether automatic mode is enabled and which metadata is excluded for the recipient. Fix: Assign one owner to the synchronized content, move the local element into an excluded field, or switch to manual delivery. To roll back, restore the local edit from WordPress revisions or a backup, then temporarily disable the site's connection.

An ACF test looks different than expected

Symptom: A regular post transfers, but an ACF field is blank or displays differently. Cause: The field type may not be on the supported list, or the local theme may expect a different value structure. What to check: Compare the field type with the published list, test a simple text field separately, and check the actual value in the recipient dashboard. Fix: Do not include the page in a bulk batch until you have chosen a compatible structure or excluded the problem field. To roll back, restore the page from a backup and keep the exclusion for that recipient.

Plan Recipient Rules: One Source, Different Publishing Requirements

Connecting several independent sites is useful only when each recipient has a clear role. Otherwise, synchronization quickly turns into sending the same version of a post to sites that need a different title, category, or local edit. Treat each connection in CodeCanyon WordPress API Posts and Pages Sync as a delivery matrix, not an abstract list of URLs: for each post, know where it comes from, which sites can receive it, who is responsible for the final version, and which data must not be replaced automatically.

Start with a table in the team's working guidelines rather than connecting every installation at once. List the source site in the first column, the specific recipient in the second, the allowed content types in the third, and the chosen transfer mode in the fourth. Also record whether media, categories, tags, fields, and deletions may be transferred. The plugin lets you connect multiple sites, but the editorial team decides which routes to use. The safest starting route is one source, one test recipient, and one test post.

Assign an owner to each field first

A post does not always have a single owner in every respect. The title and main text usually belong to the central editorial team. A local sales funnel, related-content list, campaign banner, regional phone number, or SEO block may belong to the recipient. If you do not define these boundaries before enabling Auto Sync, one team may see the next transfer as a normal update while another sees it as lost work.

Example of assigning responsibility for a synchronized post

Part of the post	Typical owner	Recipient rule	Check after transfer
Title, main text, and date	Source site	Allow source updates	Compare the title, paragraphs, and post status
Categories and tags	Source site or shared editor	Transfer only when the taxonomies match	Open the post and the relevant category archive
Featured image and regular media files	Source site	Transfer after testing the media library	Check the thumbnail, full-size file, and public page
Local promotional or service block	Recipient	Exclude the related metadata key or move the block outside the synchronized content	Update the source and confirm the local block remains
Post deletion	Only an agreed central owner	Keep disabled until the recovery process is confirmed	Test separately on a copy or test post

This matrix prevents mismatched expectations rather than technical errors. The plugin may correctly deliver the data available to it, but it cannot decide whether a local edit matters more than the latest source version. If some fields need to remain independent, identify them and define a rule first. Then configure metadata exclusions for the relevant recipient and test them on a regular sample post, not on a page with an active campaign.

Group sites into environments instead of one long list

A practical setup for independent WordPress sites has three environments. The first is for testing: send a sample post there after changing settings, updating a theme, adding an ACF field, or changing the editorial process. The second is for live publishing: it receives content that has already been tested in a predictable mode. The third is for special cases: sites with a local design, different taxonomies, separate SEO rules, or a manual approval process. These sites do not need to be excluded from the tool, but Manual Sync and a separate review process may suit them better.

Do not give recipients nearly identical names. Labels like "article site" and "new article site" are clear only until the first urgent update. In the connection cards and team guidelines, use names that show each site's purpose, such as "US - test," "US - publishing," or "partner - manual review." This does not change API behavior, but it lowers the chance of selecting the wrong destination during a bulk transfer. If someone has to remember how a recipient differs from its neighbor, its name is not clear enough.

Each environment needs its own readiness criteria. For a test recipient, confirm that the data matches and no errors occurred. For a live recipient, check the data, public display, indexing settings, and whether local blocks were replaced. For a special environment, readiness may also require editor approval. Do not send every post to every environment out of habit: bulk sync helps with repeatable content, but it does not decide who actually needs a post.

Use manual delivery to make a decision, not as an emergency mode

Manual Sync is especially useful for content with editorial risk: a major revision, a new category, untested media, careful localization, or a new group of fields. The editor opens the post or page, selects recipients in the WordPress API Content Sync block, and sends it only after checking the content. Before clicking Sync, it helps to ask three quick questions: which site is the source of truth, what data should be transferred, and what should remain local to the recipient?

This approach does not mean that every task has to stay manual. It provides a safe way to introduce new delivery routes. After five to ten test transfers in a row produce the expected result, the team has a basis for enabling Auto Sync for routine updates. Until you have that experience, manual mode can save more time than it takes: an error affects one post instead of dozens of sites.

Do not create a reverse route without a separate rule

If site B receives a post from site A, do not also treat B as an independent source for that same post on A. Even without a direct technical loop, editors will have to decide which version is current, and updates can lose their meaning. Assign a direction for each content group: the central site sends to local sites, a local site sends to the central site, or the sites have no ongoing synchronization and use one-time transfers only.

If a local site really needs to expand on a post, handle that as a separate operation. For example, the central team sends a base page, the local editor adds a regional block, and later changes to the base are sent only after reviewing metadata exclusions. Another option is for the local editor to revise the main text as a draft on the source, where the next version is published. One clear path for changes is more reliable than two equal paths that are expected not to cross.

Use a Test Post to Define the Contract Between Sites

A transfer is not successful just because a post with the right title appears in the recipient's dashboard. The plugin syncs posts and pages between independent WordPress installations, while the visible page is assembled from several layers: the content itself, taxonomies, media, metadata, the theme, and permalink rules. A test post helps you define those layers in advance and check them in a clear order.

Build a test post that exercises the features you need

A short note with one paragraph can create a false sense of readiness. For the first transfer, prepare a small but representative post: a clear title, several paragraphs with a subheading, one featured image, one file or embedded image in the text, two categories, two tags, and only the custom fields your workflow actually needs. Add a non-public internal phrase to the main text, such as a team test code, so you can tell the new version from a copy that was already there.

Do not use content with personal data, an active promotion, or irreversible sales in the first test. If the theme or page builder displays special fields, use a neutral sample that demonstrates the behavior without affecting visitors. For pages, include a few common site elements: regular text, an image, a button, a table, or an accordion, if you use them. The goal is not to stress the connection, but to find out which elements need their own rules.

Check the outcome across four layers

Review sequence for a test sync

Layer	What to open	What to compare	What to do if it differs
Post in the dashboard	The post or page list and the editing screen	Title, main text, status, date, and author if needed	Stop bulk transfers and check the selected recipient's rules
Taxonomies	The post sidebar and category archives	Categories, tags, and whether they match the editorial rules	Confirm that the structures match and review term exclusions
Media	The media library, featured image, and media in the post	File availability, thumbnail, and full-size image path	Test the specific file instead of resending the entire batch
Public page	The page in a new window and, if needed, at a mobile width	URL, layout, image and block visibility, and local elements	Separate a data-transfer issue from a theme or permalink issue

This sequence matters because the same symptom can have different causes. If content is missing from the WordPress editor, there is no point in looking for it in the theme styles. If everything appears in the editor but the public page has no image, the problem may be a widget, template, file optimizer, or recipient cache. Record which layer shows the mismatch. That keeps the next check focused and makes the API log a source of evidence rather than the final answer to every display issue.

Test three consecutive changes, not just the first transfer

The first send answers only whether the post can be created. For a working process, you also need to know what happens after an edit. First, transfer the test post. Next, change one paragraph on the source, replace the featured image, and add a tag, then sync again. Finally, remove one tag, restore the previous image, or clear the test field, and send it a third time. This checks not just creation but how updates change the recipient's content.

Inspect the recipient after each step, before making the next change. You cannot evaluate the transfer path if three edits are sent one after another: if the final state is wrong, you will not know when it went wrong. For an Auto Sync test, make the same changes with a short pause so the request can finish and you can confirm the update in the dashboard. With Manual Sync, consciously select the recipient each time to confirm that editors can distinguish between environments.

If the second update leaves the old image or the third does not remove the tag, do not work around the problem by creating a new post with a different title. A new post does not prove that updates to the original work. Record the source ID, change type, time observed, and the layer where the mismatch occurred. Then rule out caching, image optimization, and local plugins before repeating one controlled step.

Separate technical acceptance from editorial approval

Even without an API error, a post may not be ready to publish. A local site may use a different template, require a consent block, use different heading rules, or have its own search-visibility settings. After technical acceptance, use a short editorial review: open the public page, check readability and media, confirm that required local blocks are still present, and only then move the content into the normal publishing workflow.

This distinction is especially useful when different teams work on the recipient. The technical operator is responsible for the transfer, while the editor is responsible for meaning and fit with the local channel. With separate roles, an editor does not change API settings because a photo is poorly cropped, and an operator does not decide whether an unfinished draft is ready to publish.

Keep a short reference for a successful transfer

After a successful test, save a brief reference rather than an export or a large collection of screenshots: the test post title, recipient, selected mode, what should transfer, what should stay local, and which four screens were checked. This is useful after updating WordPress, the theme, an ACF field, or editorial rules. It gives you a way to test the new setup with one post before resuming bulk or automatic synchronization.

Media, Taxonomies, and ACF: When Data Needs a Separate Decision

Plain text shows only that the basic connection works. On a real site, the data around the text often matters more: the featured image, media in the content, categories, tags, and custom fields. CodeCanyon WordPress API Posts and Pages Sync lists categories and tags for posts, as well as media and featured images for posts and pages. These features are useful, but each carries its own risk, so treat them as separate parts of the delivery route and test them individually.

Category and tag syncing should reflect the same site rules

A category may look like a simple label, but it can affect menus, archives, recommendation blocks, breadcrumbs, and template rules. If a category is called "News" on the source and the recipient uses the same name for a different editorial stream, the matching name does not make them equivalent. Before enabling taxonomy transfers, compare the structures on both sites: which categories exist, which ones appear on the front end, whether parent categories are allowed, and how tags are handled.

For the first test, use two categories and two tags that the teams have agreed on. After syncing, open both the post and each category archive. This shows effects that are not visible in the editing screen, such as placement in theme blocks, list sorting, and navigation display. If the recipient uses a different category system, do not try to solve that with a bulk transfer followed by manual cleanup. Either keep taxonomies local or establish a reliable mapping before starting the workflow.

Term metadata exclusions should also be treated as a targeted tool. They are useful when a term on the recipient has its own internal values that are not present on the source. But an exclusion does not create the required category structure. Confirm that the term exists and is used correctly first, then decide which of its technical properties can be transferred. Similar category names do not prove that they behave the same way.

Check media as a chain, not just as an image on the post

Media has at least three visible states: the file appears in the library, the post uses it as its featured image, and visitors see it on the public page. For an image in the content, the editor and theme also need to display the right size and placement. That is why "the image is visible" is too broad a check. Open the source and recipient posts, then the recipient's media library, and finally the public page in a new window. If the site uses optimization, lazy loading, or a CDN, clear only the relevant test cache according to the site's usual process and check again.

For the first transfer, choose a file with a clear name and a safe but unusual aspect ratio. A square illustration and a wide photo can reveal different cropping issues in the theme. Do not change the image type, post template, and optimizer settings at the same time. If the featured image is missing after transfer, first check whether the attachment exists and is selected on the post. If the attachment is there but the public display is wrong, separate transfer from rendering: the plugin may have delivered the media correctly while the mismatch is in the template or optimization layer.

Do not treat a second bulk sync as a safe way to fix one image. It may replace other content that editors are working on. Reproduce the issue on one test post, identify the specific layer, correct the condition, and resend only that post. This is especially important for pages with many embedded files.

Metadata exclusions are agreements, not a catch-all for unknown keys

The plugin lets you exclude post and term metadata for a connected site. Use exclusions only when you can answer two questions: what does this key store, and why should that value stay on the recipient? Fields used for local analytics, promotional blocks, regional storefront links, or internal integrations often should not be overwritten by a shared source. But do not add unknown keys "just in case": you could leave behind a stale value that controls a public page.

A practical process looks like this. On a copy or test post, change one known field on the source and a different local field on the recipient. Send the post without an exclusion and record what happens. Then add exactly one relevant key to the exclusion, using the format shown in the setting, and repeat the test. The current process uses comma-separated keys with no spaces, so check for accidental spaces and typos before saving. Add the next key only after the first one works as expected.

Keep a short glossary for the team: the key, its plain-language purpose, its owner, whether it is transferred, where to check the outcome, and how to roll back. This does not need to be a long document, but it prevents a risky situation where one person adds an exclusion to preserve a block and someone else later removes it as an unfamiliar technical entry. An exclusion is reliable when the team can explain it without reading the source code.

Check ACF fields by type and by how the theme uses their values

Advanced Custom Fields and ACF PRO support is listed for several simple types: Text, Text Area, Number, Email, Password, Wysiwyg Editor, Select, Checkbox, Radio Button, True / False, Google Map, Date Picker, Color Picker, and Message. This is a useful boundary, not a promise that every ACF page will look the same on two sites. Even a supported value can display differently if the recipient's theme uses a different template, field name, or display condition.

Check each field in two passes. First, open the post on the recipient and confirm that the value is present in the expected field. Then check the public page where the theme uses it. With True / False, for example, check not only the saved state but also whether the block appears or stays hidden. For Select and Radio Button, confirm the chosen option and its expected label. With Wysiwyg Editor, check that paragraphs, links, images, and allowed markup are intact. For Date Picker and Google Map, check not just whether the value transferred but also whether it uses the format expected by the recipient's theme.

Do not treat complex or unusual fields as if they were on the confirmed list. Repeaters, flexible content, relationships between objects, custom serialized data, and fields from third-party extensions may need a separate solution. If such a field is critical, test it on a copy with one populated item, one edit, and one update. Until the outcome is predictable, keep it out of the live delivery route and fill it in locally instead of hoping the theme will reconstruct the structure.

Work through one real use case before sending content in bulk

Consider a regional service page. The central site owns the title, main text, shared photo, category, and an ACF field for the last-updated date. The local site owns the phone number, route information, and inquiry form. First, send the page manually to a test recipient. Confirm that the text, image, category, and date appear. Then change the date and a paragraph on the source, and the phone number on the recipient. Add the local phone field's key to the exclusions and send the update again.

Success does not mean that all the fields match. The expected outcome is that the central content changes while the phone number and local form stay as they were. Then open the public page and confirm that the theme does not expect a different date format and that the route block has not disappeared because of a field-based display condition. This gives the team a repeatable rule for a specific page type, rather than abstract knowledge about metadata syncing.

Updates, Statuses, and Deletions: Avoid Losing Content During Sync

Synchronization is valuable when it delivers an updated version faster than manual copying. But an automatic change affects more than the text. Editorial workflows include drafts, reviews, publication, unpublishing, media edits, and permanent deletion. CodeCanyon WordPress API Posts and Pages Sync offers Auto Sync and Manual Sync, the option to disable automatic sending, and a separate deletion-sync setting. Enable these options in order of increasing risk rather than accepting a default bundle.

Define the content lifecycle before choosing a mode

Write a short process for the team: content is created, reviewed, approved for transfer, sent to a recipient, checked technically, accepted by a local editor, and published or returned for revision. Specify when synchronization is allowed and what happens to the local copy after the next update. This is especially important when several people edit the source: one saves an intermediate version, another changes images, and a third is waiting for final approval.

If the source uses drafts and many intermediate saves, Auto Sync may be too early for that content type. Use Manual Sync or disable automatic delivery until the post passes internal review. For short news items where the source is always the owner and recipients make no local additions, Auto Sync can be convenient after testing. The mode should follow the editorial lifecycle, not just a desire to save one click.

List separately the changes that do not need to be sent right away: correcting a typo in a draft, testing an image upload, rearranging internal blocks, or entering a temporary field value. Then list the changes that should reach recipients: an approved text, an agreed image replacement, a required legal edit, or removal of incorrect information. When the team knows the difference, choosing a mode becomes a quality rule rather than an argument about speed.

Enable Auto Sync only after a controlled series of updates

Test automatic mode with the same test post you used for manual mode. Create or update the post on the source, confirm that it appears on one recipient, then make one small change and check what happens. After that, replace the image, change a taxonomy, and confirm that local data kept through exclusions has not disappeared. Expand the route to another site only after all the required layers behave consistently.

If one recipient requires manual review, you do not have to give up automation across the whole network. Keep Auto Sync for a consistent group of live sites and leave the special site on Manual Sync. That is better than enabling automatic distribution and repeatedly having to repair local pages after each central edit. Similarly, temporarily disabling automatic delivery makes sense during a major redesign, category restructure, field change, or theme replacement on the recipient.

Before enabling automatic mode, agree on a minimal notification process. The source editor should know that saving a change will update connected sites, and the local editor should know where to check the outcome and how to report a mismatch. You do not need a burdensome approval process for every comma, but you do need a clear channel for changes to required local blocks or higher-risk posts.

Treat deletion syncing separately from updates

The deletion-sync setting can send an action to recipients when a source post or page is moved to the trash or deleted. This is the most sensitive part of the workflow because an editor may see the result as irreversible and expect the local post to remain. A successful text and media update does not prove that deletion syncing is ready: deletion involves a different ownership rule.

Before enabling it, answer four questions in writing. Should every copy disappear if the source is taken down? Do recipients have local additions that must be preserved? Where is the working backup, and who can restore the right version? Who approves a bulk deletion if one is sent by mistake? If you cannot answer any of these confidently, leave deletion syncing off and handle removals manually after review.

Test deletion only on a post created specifically for that purpose, with no connection to visitors, advertising, or search traffic. Make sure both the source and recipient versions are easy to identify. Then move the source post to the trash, check what happens on the recipient, and test the recovery method your team would use. Afterward, create a new test post rather than returning the experimental one to the live workflow. That small investment of time helps prevent one of the most costly sync mistakes.

API logs help narrow down the cause, but do not replace checking the site

The plugin includes an API Error Logs section. Open it after a specific failure: a post did not appear, an update did not arrive, or a recipient returned an error. Before checking the logs, record which post you sent, to which site, in what mode, and what you expected to see. That ties log messages to one action instead of leaving you with a list of old events without context.

If the log points to a connection error, check availability and connection details through your team's approved process. If the post was created but the issue is only on the public page, do not blindly rewrite the connection: confirm that the data is actually in the dashboard, then investigate the theme, cache, permalinks, or local plugins separately. If only a particular metadata field differs, review its owner and exclusions. One observed symptom should lead to one focused check, not simultaneous changes to every setting.

For a recurring error, keep a short record of the symptom, content type, recipient, mode, minimum steps to reproduce, layers checked, and resolution. Over time, these records become an internal guide for editors. They also show where synchronization needs additional work to be a good fit, such as an unusual field, local theme, or page that cannot be updated automatically.

Keep the rollback plan shorter than the launch plan

A rollback does not need to become a complex migration. For a routine mistake, you should know how to stop new transfers: temporarily disable Auto Sync, switch to Manual Sync, exclude the problematic field, restore an approved revision on the recipient, and recheck the public page. The most important thing is to stop sending content until you understand the cause. Another transfer could overwrite evidence and make recovery harder.

For each live recipient, record the owner, the editor's contact details, and the last successful test post. After a major theme change, permalink restructure, or ACF field change, repeat the reference test in the test environment first. Resume the regular mode only after that. This makes CodeCanyon WordPress API Posts and Pages Sync part of a controlled publishing workflow: synchronization saves routine work, while the team remains responsible for publication decisions, data boundaries, and recovery.

Questions to Answer Before Launch

Does the plugin work with WordPress Multisite?

No. Its primary use case is independent WordPress installations. The developer offers separate products designed for a Multisite network.

Can I sync just one page?

Yes. In Manual Sync, open the page or post, select recipients in the WordPress API Content Sync block, and click Sync. This is safer than a bulk transfer when you are checking one important page.

What happens to categories, tags, and images?

Category and tag transfer is listed for posts, and media, including featured images, is supported for posts and pages. Test this on each recipient because the local theme and metadata exclusions can affect what visitors see.

Can I leave out specific fields?

Yes. A connected site can have exclusions for post and term metadata. Add only relevant keys, separated by commas with no spaces, and test each new exclusion on a test post.

Should I enable automatic mode right away?

No. First configure one test connection and use manual mode. Automatic mode makes sense when the source is the sole owner of the content and the editorial process prevents intermediate edits from being sent.

Why was the post created if its public page returns an error?

Check the recipient's permalinks and save the settings under Settings → Permalinks. Then make sure the active theme can display that content type and that its URL rules are not conflicting.

Will any Advanced Custom Fields work?

No. The plugin lists specific simple ACF field types as supported. Test fields outside that list and complex structures on a site copy before transferring live content.

Should I enable deletion syncing?

Only if the central site has full ownership of the content, a backup is available, and local editors have agreed on the deletion rule. Otherwise, leave the option disabled and remove content only after review.

When CodeCanyon WordPress API Posts and Pages Sync Is a Good Fit

This plugin is a good fit when several independent sites need to receive the same posts or pages from a clearly defined source, and the team is ready to assign content ownership and test the connection on a pair of sites. Its main strength is not the number of toggles, but the clear workflow: connect a recipient, choose a mode, set exclusions, send a test post, check the public page, and use the API log when something goes wrong.

Do not rush to connect every site or enable automatic deletion on day one. Start by manually syncing one post, expand the test to include media, categories, and required custom fields, then document the editorial rule. Once that sequence is repeatable, you can download the latest version of CodeCanyon WordPress API Posts and Pages Sync and roll it out to your live environment without turning synchronization into an unpredictable content broadcast.