MainWP Post Plus - WordPress Plugin

MainWP Post Plus Guide: Drafts and Controlled Random Metadata

MainWP Post Plus is useful when you need more than simply sending one piece of content to several sites. It helps you keep the publishing process under control before anything goes live. The extension adds two connected but distinct tools to the MainWP Dashboard: the ability to save post and page drafts in the central dashboard, plus the MainWP Randomizer panel for randomly selecting an author, category, and publication date on child sites. This guide explains how to prepare your network, where to find the relevant actions, how to keep randomness from becoming an editorial-policy mistake, and how to verify the final outcome on every site.

This is not a guide to purchasing, activation details, or license bypassing. It assumes that MainWP Dashboard, MainWP Child, and MainWP Post Plus have already been obtained legitimately. The focus is the actual publishing workflow: prepare the site list, assemble the content in a draft, choose recipients, define acceptable limits for variation, publish, and confirm that visitors see exactly the information you expected on the public-facing site.

MainWP Post Plus has one important limitation: it does not create new authors or categories on child sites. It uses the existing entities on each site receiving the content. This is not a tool for making an empty network look like an editorial team. It is a way to distribute pre-prepared content across sites that are already configured properly. If author accounts, roles, and categories have not been reviewed in advance, random selection simply makes the problem less obvious until publication.

The guide covers two safe workflows. The first works well for an editor who wants to pause a prepared item and return to it after review. The second is designed for a network of similar but not identical sites, each with its own editorial structure. The core principle is the same in both cases: align the source data on child sites first, enable a random rule second, and publish only after that.

Where Post Plus Actually Saves Time

The extension is not meant to replace an editor. Its main purpose is to reduce repeated work across a managed WordPress network. When an agency manages several sites with similar content formats, the usual sequence can become tedious: sign in to a site, create a post, paste in the content, choose an author, assign a category, set a date, save or publish, and repeat the same process on the next site. MainWP Dashboard already makes it possible to manage content from one place, while Post Plus adds an intermediate layer of control: centrally saved drafts and rules for selected metadata.

A draft is useful when an editorial task is not finished yet. For example, a network manager may have prepared an article and selected child sites but still be waiting for client approval, a legal revision, or a final image. Instead of keeping an unfinished browser form open, they can click Save Draft on the MainWP post or page creation screen. The same content can later be opened from the draft list, revised, and published directly from the list or editing screen. This is different from automatic backup behavior: saving a draft is an explicit user action and should be performed at clear review checkpoints.

Randomizer addresses a different need. It adds settings to the content creation form that can randomly select an existing author with a chosen role, an existing category, and a publication date. The outcome may vary from one recipient site to another. That variation is appropriate only when the site structure was designed for it in advance: each site has real editors, clear categories, and an acceptable date range. A random rule does not make content unique in substance and does not remove the need for editorial review. It controls only the metadata listed in the extension documentation.

Who This Workflow Is For

The extension fits naturally into the work of agencies, publishing networks, franchises with independently managed local sites, or owners of several in-house projects where content is created centrally. Its value is especially noticeable when content shares a common framework but local sites differ in their authors, categories, and publishing rhythms. Another natural use case is an editor preparing a series of pages in MainWP Dashboard and wanting a reliable return point before each item goes live. A draft is for a controlled pause, not for forgetting unfinished work.

It can also help teams where one person creates content and another person publishes it. The first person saves a draft in the central dashboard and records what has already been reviewed. The second opens the item from MainWP > Posts > Drafts or MainWP > Pages > Drafts, checks the recipients, and decides whether to publish. This is simpler than passing content through a messenger and rebuilding it in multiple admin panels, but it does not replace appropriate permission separation within WordPress and MainWP.

When a Different Tool Is Better

If your goal is to distribute content over time according to a schedule, MainWP Post Plus should not be treated as a complete campaign calendar. An older MainWP Community discussion noted a limitation in the interface: the random-date setting did not provide a publication time and was not a substitute for dedicated scheduling. For releasing content in sequence with delays between sites, MainWP Post Dripper is a closer fit. If the main task is inserting repeated blocks, contact information, or variables into different texts, consider MainWP Boilerplate. For products, portfolios, and other custom post types, use the separate Custom Post Types extension.

Do not use Post Plus when child sites do not have prepared authors or when authorship must be identical and legally verified. You must not randomly assign an article to an account that has no relationship to the content. Random dates should also be avoided where chronology matters for a contract, news item, medical notice, financial announcement, promotion deadline, or legal publication. In those cases, predictability matters more than variation: set the date explicitly and confirm publication on every target site.

Before Installation: Map the Network, Roles, and Responsibilities

Post Plus works within the MainWP architecture, not as an independent editor on each client site. The central MainWP Dashboard is installed on a dedicated WordPress site that manages other sites. Every managed site must have MainWP Child installed and active, after which it is added to the Dashboard. This is the basic requirement for any remote content action. Do not begin by enabling Randomizer. First, confirm that every future recipient appears on the site-management screen and passes its connection check.

It is helpful to create a small internal map. For every site, record its URL, MainWP working group or tag, responsible editor, approved category list, real user roles, acceptable date range, and post-publication verification method. The table does not need to be complicated. Its purpose is to move conditions out of people's heads - conditions the extension cannot infer. For example, a regional site may use a category named "News," while a topic-focused site may use "Guides." If you permit random category selection, make sure every possible category preserves the meaning of the article.

Check Connections Before Editorial Work Begins

Open MainWP > Sites > Manage Sites and synchronize sites where users, categories, or plugins have recently changed. For a problematic recipient, use Test Connection while adding the site or through the relevant MainWP tool. A successful connection response only means that Dashboard can reach Child and receive the expected response. It does not prove that a specific user exists or that an editor is authorized to publish the selected content. Review the meaningful source data separately after the technical test.

Be especially careful with sites that have changed SSL settings, HTTP Basic Authentication, custom login protection, or a recently migrated domain. MainWP documentation describes connection settings including certificate verification, the administrator password, and an optional Unique Security ID. Do not disable SSL verification "just in case." If the certificate is valid, leave verification enabled. If a temporary staging site uses a self-signed certificate, document the reason in your working notes first, run the test, and restore the normal secure configuration when the work is complete.

Audit Authors and Roles on Child Sites

For random authors, Post Plus uses existing users on a child site filtered by the selected roles. Build a minimal list before you start. On every recipient, check which accounts belong to editorial work, which roles can actually publish the required content type, and which accounts are technical or client accounts. Do not include the administrator role merely because it exists everywhere. The author line on the public page should reflect real responsibility, not technical convenience.

If sites use different role sets, it is safer to narrow the selection than to assume they match. For example, some sites may have editors and authors, while others may have only an administrator remaining. In that situation, fix the user model first: create or approve appropriate editorial accounts where they are missing, verify their permissions, and then synchronize MainWP. An empty or questionable author pool is a reason to avoid random author selection until the data is corrected.

Audit Categories and Calendar Limits

A random category is selected from categories that already exist on the child site. It does not create missing structure and cannot understand editorial context. Prepare the approved category list in advance. Networks with a consistent taxonomy policy work best, as do networks with a small set of categories where every category suits the content. If one site has internal sections, archives, partner-content categories, or outdated labels, remove them from the workflow or do not apply the random-category rule to that group of sites.

The same principle applies to date ranges. The start and end of the range should have an editorial explanation: for example, you may be moving archived educational content into a period when it was genuinely relevant to the network. Do not use arbitrary past dates for a current news item or an article containing time-sensitive promises. Randomizer chooses a date within the specified limits, but it does not verify whether the text matches the campaign calendar, site time zone, current external links, or seasonal context. Those decisions remain the editor's responsibility.

Pre-installation checkpoint: Dashboard is available, MainWP Child is active on every recipient, connections have been tested, author and category lists have been reviewed, and the date range has defensible limits. If even one item is incomplete, save the prepared text as a draft and do not enable random rules.

Install the Extension on the Correct Site and Run an Initial Check

MainWP extensions are installed on the site running MainWP Dashboard, not on child sites. This is a common source of confusion: MainWP Child belongs on managed sites to communicate with the central dashboard, while MainWP Post Plus extends Dashboard itself. Open MainWP > Add-ons > Manage Add-ons, go to the add-on installation area, find Post Plus among the extensions, and install it through the standard workflow. Alternatively, upload the extension archive through WP Admin > Plugins > Add New > Upload Plugin on the Dashboard site, then activate it as a standard WordPress plugin.

Do not upload the Post Plus archive to every child site. Doing so will not add Randomizer controls there and will create unnecessary differences between plugin sets. After installation, open the add-on management page and confirm that the extension is active. MainWP documentation explains that automatic add-on updates may require an active MainWP account activation, but you should not test the editorial workflow on live sites until the extension has a clear status in Dashboard.

A Minimal Test With No Publication Risk

Run the first test on a staging child site or on one recipient where you can safely remove the outcome. Go to post creation through MainWP > Posts > Add New. The interface should display the MainWP Randomizer section. Do not enable every checkbox immediately. Start with a neutral title, short test text, one test site, and click Save Draft. Then open MainWP > Posts > Drafts, find the item, click Edit, and make sure the data was saved.

After that, you can publish the test draft and open it on the child site. Check the title, text, author, category, date, and link. Then remove the test item using actions in the draft list or standard content management if it is no longer needed. This short loop confirms several things at once: the extension is active on the correct site, Dashboard can see the recipient, draft functionality is available, and remote publication finishes in the expected state.

What You Do Not Need to Configure "for Performance"

Post Plus does not promise to optimize caching, indexing, or site speed. Do not add cache-plugin exclusions merely because you installed the extension. First identify a specific symptom: for example, a post was created but the public page still shows an old post list. Then clear or warm the cache according to that site's normal policy and check the URL again. If there is no sign of a problem, extra configuration only increases the risk of inconsistent settings across the network.

Likewise, there is no need to create custom code to alter authors or dates. Post Plus already sends the required metadata through its documented mechanism. Manually editing WordPress core, MainWP Child, or extension files makes updates and troubleshooting more difficult. If you have a separate organizational requirement, reproduce it in a staging environment first, review the official documentation, and choose the supported configuration. This guide intentionally contains no unverified PHP snippets: for the tasks described here, the extension interface is the safer approach.

A Draft Is a Controlled State, Not a Temporary Copy of Text

The most practical Post Plus feature is saving prepared content before publication. On MainWP > Posts > Add New or MainWP > Pages > Add New, begin creating content using your team's usual approach. Enter the title, main content, and only the settings that have already been approved. When you need to pause, click Save Draft. MainWP documentation explicitly describes this route for posts and pages: the item can be saved and later found among Dashboard drafts.

It is useful to distinguish between a draft that is paused because it is ready and a draft that is paused because something is unresolved. In the first case, the content has been reviewed but release is delayed until an agreed date or technical window. In the second, the author is still waiting for clarification, an image, a link, or a decision about recipients. These are not the same state. Use the title or an internal editorial note to identify the reason for the pause: "waiting for link," "ready to publish," or "check categories." Post Plus stores the draft, but it does not know which approval stage you mean.

From Creation to the Drafts List

After saving, do not create the same item again. Open MainWP > Posts > Drafts for a post or MainWP > Pages > Drafts for a page. Find the draft in the list and select Edit if you need to continue preparing it. From editing mode, you can click Save Draft again to save a new version or proceed to publication if every condition has been met. Once the item is fully ready, it can also be published directly from the draft list through the Publish action.

Do not treat the Drafts list as a permanent archive. It should contain only active items with a clear owner and next action. Review old drafts periodically. If a draft is no longer needed, use Delete in the list for that content type. If you want to use it as a template, first verify that cloning is actually available in your installed version: the extension changelog notes that post-cloning functionality was introduced in an update, but the location and availability of the action depend on the current interface. Do not build a required workflow around a button you cannot see in your dashboard.

What to Check Before Publishing a Draft

When you reopen an item, start with the conditions, not the publish button. Confirm that the correct content type is selected - post or page. Make sure the publication targets have not changed since the draft was saved. Review the title, permalink, images, links, editorial note, and MainWP Randomizer rules. If the item must be identical across all sites, random checkboxes should be off. If variation is allowed, verify not only that the checkbox is enabled but also the selected roles and date range.

The next review concerns the publication destinations. In a MainWP network, it is easy to forget that content is not being sent "everywhere" but only to selected child sites. If some sites are temporarily offline, under maintenance, or have not passed editorial review, exclude them from the release. After publication, every status change may need to be checked and potentially reversed individually. The least expensive mistake is the one you catch in a draft rather than on a public URL.

Review the Content Before Distribution

Random metadata is especially risky when the main text is written too broadly. First check whether the content contains claims tied to one brand, city, contact, regional law, or author. If it does, create a version for that specific site or use another system with explicit variables. Post Plus does not rewrite the post body for each destination. It does not analyze links, create translations, or synchronize local facts. Its role is narrower and therefore more predictable: save a central draft and apply selected rules to supported metadata when a post or page is created.

What MainWP Randomizer Does on Selected Sites

MainWP Randomizer appears on the Dashboard screens for adding posts and pages. Its behavior consists of several independent switches. You choose which metadata may vary, and when publishing, the extension uses suitable existing values on each child site. Take that literally. If you enable random author selection but do not select roles, the rule has no clear pool of candidates. If you enable a random category on a site with no suitable category, checking a box does not make the outcome editorially correct. If you leave the date unrestricted, the extension will choose a date according to its own behavior, but the editor will not control the calendar meaning.

Think of the panel as a set of constraints rather than a variation generator. Before enabling each checkbox, ask: "Which existing values are allowed on this site?" This makes it clear that author, category, and date carry different risks. The author affects trust and responsibility, the category affects navigation and context, and the date affects content order and audience expectations. Define a separate eligibility rule for each field.

Random Author: Only Existing Users With a Selected Role

To enable this mode, choose Set Random Author with privilege and select roles. According to the extension documentation, it chooses a random existing user from the selected roles on the child site and assigns that user as the author. The same publication may receive a different author on different sites because each site has its own local user list. This is the key difference from assigning one central login: Post Plus works with whatever already exists on the destination.

A safe configuration starts with a narrow role set. If your policy allows authorship only for users with a specific editorial role, select only that role. Do not broaden the pool with technical or client roles. Before a large release, manually open at least several child sites and make sure the selected accounts have accurate names, biographies, and permissions. The public author page can be a visible part of the site, so random assignment can quickly expose old test profiles, empty descriptions, and forgotten accounts.

Verify Random Author Selection After Enabling It

On a test site, publish one item with the rule enabled and check the outcome in two places: the WordPress post editor and the public page, if the theme displays authors. Then open the user list on that child site and compare the actual author with the approved role. If the wrong kind of account was selected, do not try to "fix randomness" by publishing again. Stop the rule, correct the selected roles or user pool, delete the test post or restore the author through the standard WordPress interface, and then repeat the test on one site.

The limitation is fundamental: the extension does not create a credible editorial team and does not verify that a person actually wrote the text. It only selects an existing account from the specified group. For a network where authorship must be consistent, use explicit author assignment. For a network with a legitimate local editorial team, Randomizer can remove a manual selection step, but the administrator remains responsible for available accounts.

Random Category: Navigation Variation Without Creating Categories

The Set Random Category option selects one existing category on the child site and assigns it to the content. This is useful only when every category in the approved pool suits the article. In practice, align the structure first. For example, a series of neutral educational articles may have "Tips," "Guides," and "News" available across all sites, but an article about configuration should not randomly land in "News" merely because that category is available. If strict topical control is required, assign the category explicitly.

There is also an interface detail confirmed by a MainWP Community response: Post Plus does not change how categories are displayed during bulk publishing. If different sites have categories with the same name, the general list may not show which site a particular item belongs to. This is not a Randomizer defect; it is a limitation of how the data is presented. Do not make a decision based only on a matching name. Align categories before publication or work with a group of sites whose structure has already been approved.

Check the Category on the Public Site

After a test publication, do not check only the category field in the editor. Open breadcrumbs, the category archive, the navigation widget, and site search results if the theme uses those elements. This reveals whether the random category sends visitors to an unsuitable section. If the category appears in the page URL or has its own landing page, check that as well. Problems here are usually fixed not by another random run but by changing the recipient set, cleaning up the taxonomy, or disabling the rule for that content.

Random Date: Use a Range When Chronology Matters

For random dates, enable Set Random Publishing Date. Specify a precise range when needed. The documentation describes two options: when boundaries are filled in, a date is selected from that range; without boundaries, the extension chooses a random date. For most working situations, specifying the range explicitly is safer because it makes the possible outcome clear to the team. An unrestricted random date can disrupt the order of an educational series, bury a new item in an archive, or create an odd contrast between the text and the date shown on the page.

The range has another limitation: it does not turn publication into exact scheduling. If you need a specific date and time for each site, use WordPress scheduling or an extension designed for delayed distribution. Do not confuse "select a date from a defined window" with "publish at a scheduled calendar moment." Decide why variation is needed first. If the answer is vague, leave the date explicit. A random date is justified only when every date in the range is editorially acceptable.

Combining All Three Rules and Testing Them in Order

You can technically enable several options at once, but it is more useful to add them one at a time. First test a draft without Randomizer. Then enable random author selection on one test site. After that succeeds, add the category rule. Add the date last because it has the strongest effect on how a post is perceived in archives. After every step, record the outcome: which site was selected, which role was allowed, which category was assigned, and which date was chosen. Keep this log in the team's task or publication record.

If a condition works on one site, do not treat that as proof for the entire network. A second recipient may not have the same role, may have a different user list, or may use another taxonomy. Choose one representative from each site group: for example, a site with multiple editors, a site with a minimal author count, and a site with a different category structure. If the workflow succeeds at those boundaries, the risk of a broad release is much lower. That is the practical value of the central dashboard: test differences deliberately instead of hiding them behind one action.

Practical Example: Prepare an Educational Article for Three Site Groups

Imagine an agency network of nine sites. Three focus on basic digital skills, three provide local consulting, and three serve as service directories. All are connected to MainWP, but each group has its own editors and categories. The agency needs to publish a calm educational article without local prices, addresses, or promises. The text suits every site, but the author line and navigation section must match the particular destination. The goal is to prepare the content in the central Dashboard, save it as a draft, review the groups, and publish only after a final check.

Step 1. Separate Recipients by Editorial Meaning

Do not select all nine sites immediately. Create MainWP tags, or use existing organization, to distinguish the three groups. For each group, record which author roles may be selected, which categories are allowed, whether the date is displayed consistently on the site, and whether a reviewer will open the published result. If the service directories hide the "Guides" category or use another label, do not include them in a shared run until the structure is aligned. Post Plus does not remove editorial differences; it only helps you work with a group that is already understood.

Assume that the first and second groups pass the audit while the third requires a separate version of the text. Select six sites for the first release. That decision may look less impressive than sending content to "the entire network," but it is safer. Central publishing is valuable not because of the number of recipients but because each one preserves the intended meaning. In the working note, state why the third group was excluded: an unprepared category, a different content tone, no real author, or a need for a local example.

Step 2. Create and Save the Draft

Open MainWP > Posts > Add New and add the title, text, images, and links. Complete the fields thoroughly enough that a second editor can assess the material without verbal explanation. Do not enable random metadata at this stage. Click Save Draft. Open the Drafts list, find the item, and assign an internal next step such as "check roles for group one" or "waiting for approval." If your team uses an external task manager, add a link to the relevant Dashboard screen, but do not place passwords or access details in the task text.

The pause provided by a draft helps expose problems that usually surface just before publication: an outdated link, an overly generic heading, a no-longer-current term, an unsuitable illustration, or duplicate copy. Review the text from the perspective of visitors to every site type. If the phrase "our team" does not match the author on one destination, remove it or prepare a separate local version. A random author should never become a way to hide a mismatch between text and context.

Step 3. Configure Only Justified Variation

After approval, open the draft again through Edit. In MainWP Randomizer, enable random author selection and choose only the roles confirmed for both groups. If the role lists do not match, divide publication into two runs with different settings. Do not select a role you have not reviewed. Enable the category rule only if all six sites have a category pool where every possible choice fits the article. Otherwise, assign categories manually or publish by group.

For this example, it is better not to enable a random date if the article is new and should appear as current content. If you have a justified archival range and the text is not tied to current events, set it explicitly. Before doing so, check how dates appear in the themes used by all groups and whether their sorting could bury the new publication at the bottom of the archive. The team should document that decision rather than leave it to a random outcome.

Step 4. Publish First to One Representative Site per Group

You do not have to send the final item to all six sites at once. Select one representative from each ready group, publish the post, and verify the outcome. Open the public page in a private browser window and check the author, category, date, images, links, and placement in the archive. Then return to Dashboard and make sure the post status matches expectations. If everything is correct, repeat the release for the remaining recipients in that group. If you find a problem, keep the remaining versions as drafts until the conditions are fixed.

This two-stage release does not remove the advantage of MainWP. It uses it wisely: you create the content and rules once, then control the consequences at the boundary between groups. This is particularly useful after role changes, new site templates, or migrations. One correctly tested group representative provides more useful information than publishing simultaneously to a dozen different sites without a checkpoint.

Step 5. Record the Outcome and the Rollback Plan

After publication, add the actual URLs, verification date, selected site groups, and reviewer's name to the working record. If an issue affects just one site, correct it locally through the standard WordPress interface or move the post to the appropriate status under the team's policy. If the issue is caused by an incorrect role, category, or range, stop further publications, correct the rule in the central draft, and repeat the test on one site. Do not use a new random publication as a way to reshuffle an unsuccessful outcome: that adds unpredictability instead of addressing the cause.

How to Prove That the Publication Reached Visitors

Verifying MainWP Post Plus has two levels. The first is administrative: Dashboard and the child WordPress site show that the item was created and has the expected status. The second is public: a visitor's browser opens the intended page and sees the correct metadata. Do not rely only on a successful-operation message in the central dashboard. Cache, themes, plugins, user permissions, and archive behavior can all affect what people actually see on the site.

Administrative Verification

On the child site, open the post or page list and find the new item by title. Check its status, author, category, and date. If the publication was supposed to remain a draft, make sure it does not appear among published items. If you used Drafts in MainWP, return to the central list and make sure you did not leave a duplicate draft that the team might publish later by mistake. For a published item, it is also useful to open editing mode and compare key fields with the central source.

Public Verification

Open the permalink in a separate browser window without being signed in. Compare the title, main text, images, links, author line, date, category, and breadcrumbs. If the theme does not display the author or category, that does not prove the metadata was not saved; verify it in the editor. If the date and author matter for the task, make sure the active theme actually displays them where visitors expect to see them. Check the category archive and author page separately if they exist.

When cache is involved, first confirm that the item exists in the administrative area, then inspect the response at the public URL. If the admin panel shows new data but visitors see an old version, follow the normal cache procedure for that specific site: clear the relevant layer, wait for the update, or check in a private window. Do not alter Post Plus settings if the cause is cache-related. Keep content delivery separate from content display: they are different troubleshooting stages.

Short Publication Checklist

• The central Dashboard has the exact list of child sites approved for this content.
• Each checked site contains the required content type with the intended status.
• The author belongs to an approved role and the public byline does not conflict with editorial policy.
• The category leads to an appropriate section rather than an internal or irrelevant archive.
• The date does not disrupt a series chronology, promotion terms, or archive order.
• The public URL opens without authentication and shows the current outcome after cache has been taken into account.

Boundaries When Using Other MainWP Add-ons

Post Plus can be part of a content workflow, but it should not be expected to perform the work of adjacent extensions. If your team needs articles released gradually across a network at intervals, MainWP Post Dripper is more appropriate: its product page describes distributing posts or pages over a defined period. In that combination, the responsibility boundary is straightforward: Post Plus helps save and finalize the central content, while a scheduling distribution tool handles the timeline. Before combining them in a live campaign, test each stage with a staging group of sites.

When content differs only through repeated blocks, MainWP Boilerplate may be worth considering. It is intended for template-based content, while Post Plus is for drafts and random metadata. Do not confuse variable replacement with author selection: an author name in WordPress is separate metadata tied to a real user account. If a template includes contact details or a brand, do not assume Randomizer will make it local. Create appropriate template variations or exclude recipients with a different context.

For WooCommerce products, projects, testimonials, or other custom post types, Post Plus should not be treated as a replacement for MainWP Custom Post Types. That extension is intended to manage existing custom types on child sites and requires matching type definitions on Dashboard and recipients. The internal behavior of these add-ons is different. Choose the one that matches the content type rather than trying to make a standard post behave like a product or portfolio item.

Safe sequence for combined use: first confirm that content and metadata are correct in Post Plus, then pass the reviewed material into template or scheduled-distribution work. If a problem appears after the second add-on, do not change random rules until you have checked the handoff between the tools.

Editorial Policy for Authors, Categories, and Dates

A persistent MainWP Post Plus problem usually does not come from the buttons themselves. It comes from the absence of a rule defining when those buttons may be used. A team may have a technically functional Randomizer but no answer to three simple questions: who may be listed as the author, which sections suit the content, and what its date means to visitors. Until those answers are documented, randomness creates not variation but decisions that are difficult to explain. Before broad adoption, create a short metadata policy for the network.

The policy does not need to be a legal document. One page in the team knowledge base with three tables or lists is enough. The first lists permitted author roles and exclusions. The second identifies categories that can be selected for every content type. The third defines date cases: an explicit current date, an allowed historical range, a calendar-scheduled date, or a ban on random selection. At that point, the Post Plus draft no longer presents "a set of switches" but a clear implementation of an agreed rule.

Authorship: A Visible Byline and Real Responsibility

An author name on a WordPress site can serve several different purposes. On some projects, it is the editorial byline of the person who prepared the material. On others, the author represents a local editorial office or responsible specialist. On a third type of site, themes hide the author, while the item still belongs to a user in the administrative area. Do not treat these situations as identical. First review how the public theme displays authors, which author pages are available to search engines, and whether user profiles are completed. Then decide whether Randomizer is appropriate.

If authorship is personal, the item must be assigned to someone with an approved connection to the text. Random selection is not appropriate in that context. If authorship is editorial and several local editors are genuinely authorized to represent the same content type, Randomizer may be appropriate. Even then, exclude blocked, test, temporary, technical, and client accounts. Sites with internal roles often include users with high access levels who should never appear in a public author line.

The practical check is simple. For every role you plan to select in Set Random Author with privilege, open at least one account on each type of site. Check the display name, biography, author link, and status. If even one profile looks empty or unsuitable, do not rely on it being selected rarely. With enough publications, it will eventually be assigned. Either correct the profile or place it in a role excluded from the rule.

A Category Is Not a Decorative Label

A category affects a visitor's path. It may appear in menus, breadcrumbs, archives, internal links, and related-content blocks. A category should therefore not be selected according to the idea that "any category is better than none." Check every site for categories with identical names but different editorial meanings. For example, "Guides" on one site may mean real-world case studies, while on another it may mean step-by-step instructions. If an article suits only the second meaning, the matching name does not make the categories equivalent.

A suitable Randomizer policy is usually limited to similar educational content. The team approves two or three categories in advance, and each one can accept the publication. If categories are tied to different products, cities, funnel stages, or legal sections, do not use random selection. Divide the release into segments instead. This requires an extra action in MainWP, but visitors receive clear navigation and editors can explain why the material belongs in that particular section.

Date: A Visible Claim About Time

Visitors often perceive a publication date as a claim about freshness, even when the site uses it only for sorting. It affects archive order, "New" blocks, RSS, some metadata templates, and a reader's assessment of how current the material is. For that reason, Randomizer should not be enabled without a clear purpose. A random date may be acceptable for a previously prepared series of neutral reference articles if its historical window is honest and every possible date is acceptable. It is not appropriate for news, notices, announcements, changes to terms, promotions, or content whose text points to a particular period.

Before enabling Set Random Publishing Date, define the check in one sentence. For example: "Any date between the selected limits will not make this guide inaccurate or disrupt the series order." If you cannot say that confidently, leave the date explicit. Also check the time zone of Dashboard and the child site. You do not need to force every setting to match if the difference is intentional, but you should understand which time the interface and theme use to show the outcome. Randomness must be limited by meaning as well as by the calendar.

Four Decisions Before Clicking Publish

This framework does not replace testing, but it helps you stop before automation becomes a source of questionable metadata. When in doubt, choose an explicit value. MainWP Post Plus remains useful without enabling all three random options: saving Drafts and managing content from one place already reduce manual navigation. Using only some features is a sound choice if it makes publication more transparent.

The Post Plus Chain: Input, Rule, State, and Outcome

To troubleshoot publication confidently, it helps to divide Post Plus into four links. The first is input: the title, post body, selected child sites, and Randomizer settings entered by the editor in Dashboard. The second is the rule: the extension is allowed either to save a draft or to apply a selection from existing data on a specific child site to supported metadata. The third is the state change: a draft appears in the central dashboard, or a post is created at the destination with selected fields. The fourth is the observable outcome: the editor sees the status in the admin panel, and visitors see the page if it is published.

This model helps keep causes separate. When text is not saved as a draft, look at the transition between input and the central draft. When the author is wrong on only one site, check the rule and the local user pool rather than the publication HTML. When the author is correct in the editor but invisible to visitors, investigate the theme or cache. In each case, only one layer changes, making the action reversible and understandable to the team.

Draft Behavior: From Form to Repeat Editing

The input for Drafts is the MainWP standard post or page creation form. The editor enters the content and explicitly clicks Save Draft. The responsible component is the extension on Dashboard, which stores the working state so it can later be reopened from the Drafts list. The observable outcome is a saved item at MainWP > Posts > Drafts or MainWP > Pages > Drafts. Verification is simple: open the item with Edit and confirm that the title and main content return.

A failure symptom in this part of the workflow is an editor looking for a draft under the wrong content type or opening the standard published-post list. The safe fix is not to create a second copy, but to check both Drafts lists, search by title, and confirm the actual status on the selected child site. The limitation is that a draft is not an approval system with team-wide comments, revision history, or automated reminders. If those capabilities are critical, manage them in an external process and use Post Plus as the place to save a publication draft.

Random Author Behavior: From Role to Public Byline

Here, the input is the checked Set Random Author with privilege option and its role set. The rule limits candidates to existing users with selected roles on every child site. When the post is created, its author changes on the specific recipient. The observable outcome is a name in the WordPress author field and, if the theme displays it, on the public page. Verification includes the user list, the selected account's role, and the actual author page.

The failure symptom is an unsuitable name in the byline. The cause is usually not "bad randomness" but an overly broad set of roles or unprepared local accounts. The fix is to narrow the roles, disable the rule for that site group, correct the profiles, and run one repeat test. The limitation is that Post Plus does not account for a person's subject expertise, workload, profile language, or contractual obligations. That information must be addressed before it becomes the source of a random selection.

Category Behavior: From Local Taxonomy to the Visitor Path

The input is an enabled Set Random Category option. The rule selects an existing category on the child site. Once the post is created, its category assignment changes, and visitors encounter it through the archive, breadcrumbs, label, and theme links. Verification should proceed from the admin panel to public navigation: inspect the post metadata first, then open the archive and follow the visitor path. This distinguishes an incorrectly saved category from a theme that simply does not show it on the page.

The failure symptom is content appearing in an irrelevant section. The safe correction is to assign the proper category manually on the affected site and then review the recipient group. The limitation is that if category names match but their meaning differs, no technical selection can make them equivalent. Do not try to solve this with hidden substitution or database edits. Approve the taxonomy or separate publication into groups.

Date Behavior: From Range to Archive Placement

The input is the Set Random Publishing Date checkbox and, when needed, two range boundaries. The rule selects a date based on those settings. On the recipient, the publication-date field changes, while the visible outcome appears in the metadata line and archive sorting. Verification should include more than the page itself: open the archive, feed, and recent-post block if the site uses them. This shows how the change is experienced by an actual visitor.

The failure symptom is a correct article appearing in an unpredictable place in the feed. The fix is to adjust the date of the specific item, narrow the range, or abandon the rule. The limitation is that a range does not control the exact publication minute and does not know about a campaign running in another channel. It suits only a pre-approved window, not a precise editorial schedule.

Working Roles on the Team: Prepare, Review, Publish

Even a small team benefits from separating three workflow roles. The preparer creates the content and saves a draft. The reviewer compares the source data with policy: site list, author roles, categories, and dates. The publisher chooses the release point and confirms the outcome on recipients. One person can perform all three roles, but it is useful to go through them in sequence. Then, before clicking Publish, you have a distinct review of conditions rather than just a feeling that the item is ready.

The Preparer's Role

The preparer is responsible for the content and clarity of the draft. At minimum, they should not send a half-empty form to Drafts without a purpose or note. The title or task card should make clear what the material is, which site groups it was prepared for, and which fields still need a decision. The preparer does not have to verify every user's role personally, but must flag text that makes a random author or category questionable. Local contacts, references to a particular person, and calendar promises should stop a shared release.

The Reviewer's Role

The reviewer does not work as a copy editor but as the owner of the conditions. They open the draft, compare recipients with the working map, and inspect MainWP Randomizer. At this stage, four questions are useful: are all sites connected and synchronized, are all roles permitted, does every possible category fit, and will the text remain accurate for every allowed date? If one question has no clear answer, the reviewer returns the draft for revision or divides the release into groups. This is not a delay; it protects against the difficult-to-correct distribution of an error.

The Publisher's Role and the One-Representative Rule

The publisher launches the prepared item and records the fact. For a mixed network, it is useful to follow the one-representative rule: first publish to a site that represents one group of identical conditions, then verify the outcome in the admin panel and a public browser. Only then expand the release to the remaining sites in that group. If one site differs in roles, taxonomy, or theme, it forms a separate group and requires its own verification. This approach is particularly important when using MainWP Post Plus for the first time after an update, migration, or change in user roles.

The internal post-publication log should contain only what is needed: content title, groups, representative URLs, actual author, category, date, and review status. Do not include credentials, passwords, keys, or personal data that is unnecessary for editorial control. If a disputed publication is found later, this log lets the team reconstruct the sequence of actions without guesswork and without another random send.

When MainWP Post Plus Is a Good Choice

MainWP Post Plus is worth using when you already have a functioning MainWP network and need to prepare standard posts or pages from one dashboard in a controlled way. Its strength is not flashy automation but a clear combination of drafts, repeated review, and limited selection from existing metadata. The better your users, roles, categories, and site groups are prepared, the more useful the extension becomes.

Start small: one test site, one draft, one rule, and one public outcome. If that chain is transparent, move on to recipient groups and document your release criteria. Once preparation is complete and you understand the tool's limits, you can download the MainWP Post Plus archive and perform a safe test on your own network.