AfieldIn this article
If a marketer needs to edit and schedule the next article without a developer, start by testing WordPress. If the article changes alongside product documentation and the team already reviews pull requests, test the repository route. The useful comparison is one ordinary publishing day.
Follow one article through both routes
| Job | WordPress | GitHub repository |
|---|---|---|
| Write and edit | A writer edits a post in the publishing interface. | A contributor changes the content file used by the site. |
| Approve changes | Use the site’s editorial roles and draft or pending-review status. | Use a pull request to inspect the diff and discuss changes. |
| Choose publication time | WordPress includes scheduled publication; check the configured time zone. | Publication depends on the site’s build and deployment process. A merged change and a live page are separate checkpoints. |
| Fix the live page | Update the post, then inspect the public URL. | Commit the fix, run the site’s checks and inspect the deployed URL. |
These describe the basic publishing routes, not every plugin or hosting arrangement. WordPress documents its post status and scheduling controls; GitHub documents pull-request review and GitHub Pages. A repository does not, by itself, give a nontechnical writer a visual editor.
A practical split for a small team
Here is an illustrative ownership plan for a team with a marketer and a developer:
| Content | Owner | Release condition |
|---|---|---|
| Customer-facing articles in WordPress | Marketer | Product claims checked; preview approved; publication time confirmed. |
| API documentation in the product repository | Developer | Code examples checked; pull request approved; deployment checked. |
| Links between articles and documentation | The person making the change | The destination exists and the link still describes it. |
The split works only when each piece has one authoritative copy. Keeping the same article independently editable in two systems creates a new problem: which version should the next writer update?
Try this before moving the blog
Take an existing article. Ask its normal writer to correct a paragraph, replace an image, preview the result and publish at a specified time. Record each point where they need help. Then ask the developer to correct a broken layout without losing the writer’s text.
Check the final title, description, canonical URL, images and mobile layout on the public page. If URLs will change, prepare an old-to-new redirect map before migrating. Choosing a new editor is not a reason to discard working article URLs.
For Afield-assisted work, the direct CMS route is an authorized WordPress.com connection. Afield’s separate self-hosted WordPress connector is currently unavailable; for that destination, prepare the reviewed copy and paste it into the site’s editor. A repository change follows its own review and deployment steps. Confirm the article in the chosen destination before treating the publishing task as finished.