Projects and partners

A copy editor does not need every store-administration capability

List what the editor must actually do: prepare wording, change specified content, publish approved changes or perform a separately identified administrative task. On a single WordPress site, the default Editor can publish content without the Administrator's plugin, theme, options and user-management capabilities. Choose access against those tasks and the site's actual capabilities. An agreed list of pages limits the work contractually; it does not prove the chosen role technically restricts the person to those pages or files.

For: A research-only store owner assigning WordPress content work while retaining control of software, settings and publishing decisions.

Updated 2026-10-01

Describe actions before choosing the role

A request to update copy does not specify who will enter it, approve it or publish it. Name the affected URLs and content surfaces, then allocate each action. Someone who only supplies revised wording may need no WordPress account. Someone who must enter approved changes needs the capabilities for those objects. Someone authorized to publish needs publishing access as well.

Separate content approval from access approval. The merchant may approve a sentence while another authorized person publishes it. Record both owners so the editor does not infer that a login grants authority to change a refund commitment, shipping promise or description of the research-only audience.

Location also matters. Wording on a public page may be entered as page content, or it may belong to a template or a plugin setting. Establish the actual editing location. Do not grant broad administration because a content editor cannot find a sentence that lives elsewhere.

Compare the documented roles with the work

WordPress's roles documentation distinguishes default content powers from single-site administration. An Administrator can manage users, plugins, themes and options. An Editor can publish content without receiving those administration capabilities. That distinction supports a content assignment without automatically handing over the controls used to install plugins or switch themes.

Treat Editor as a role to assess, not an automatic minimum for every writing job. If the person only prepares wording for approval, publishing access can exceed the task. If the person needs to edit a particular store object or extension screen, the role label alone does not establish access to it. Ask the site administrator to identify the capability that the actual task requires and confirm what the proposed account can do.

Plugin installation, theme switching and options management are separate administrative actions. If one is genuinely necessary, describe it as its own task with an owner rather than folding it into a general copy-editing permission. An authorized administrator may complete that dependency while the editor retains only the access required for content work.

Keep the page list separate from the permission boundary

The project should state exactly which pages, images and wording may change. That is a work instruction. The default role comparison does not establish an arbitrary allowlist of those pages, ownership of repository files, or a boundary around a contractor's folder. Do not promise that assigning Editor enforces those limits.

If a technical restriction to particular objects is essential, have the administrator demonstrate the restriction that is actually configured. Until that is established, record it as unverified. A written scope and a role name are insufficient evidence of that narrower control.

Record the account's effective capabilities on this site, especially if its roles have been customized. Keep the single-site scope explicit: the documented comparison here is not a complete authority map for a WordPress network. An unresolved capability question calls for a narrower handoff, such as having the merchant publish the approved copy, rather than an unsupported claim that access is isolated.

Authorize the handoff and the end of access

Before access is granted, record the publishing task, capability needed, proposed role, person who authorizes it and condition that ends the access. An expiry condition can be a named delivery milestone or a specified review date chosen for this actual project. Writing that condition in a worksheet does not make WordPress revoke access automatically; name the administrator responsible for acting on it.

At handoff, compare the published wording with the approved content and exact page list. Then have the owner review whether the account still needs its project permissions. Do not share an administrator password just to avoid deciding which tasks belong to which person.

Prism's checkout consultation can define the pages, questions and follow-up before work, while the merchant decides which updates to make. Include any requested access or publishing work in the agreed scope, fees and terms. Send the website, research-only products and question through the public inquiry; keep credentials and customer records out. The form leads to email follow-up and does not itself authorize a publishing engagement.

Content-access scope

Use this scope with the actual task list and account-capability record. Record an answer for every task, including work that needs no login. A role proposal is not confirmed until the site administrator has checked it; the page list and expiry condition require their own owners.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

Content-access scope. The last column is for temporary notes.
Access decisionEvidence to gatherHow to limit the assignmentYour task-specific decision
Publishing taskExact URL or content object and whether the person drafts, enters, approves or publishes the wording.Separate these actions; providing copy alone need not require a store login.
Required capabilityAdministrator's identification of the capability needed for the actual page, template or extension screen.Do not infer the requirement from a public page's appearance or a job title.
Proposed roleDocumented role capabilities compared with the effective capabilities of this site's account.Default Editor supports publishing without single-site Administrator powers; confirm whether it exceeds or misses the actual task.
Administrative dependencyAny necessary plugin, theme, options or user-management action, with its own purpose.Assign that action explicitly instead of granting all administration for routine copy work.
Approved content boundaryMerchant-approved page list, assets to preserve and wording changes.A scope list does not itself create a technical restriction to pages or files.
Technical restriction, if requiredAdministrator's evidence of the particular object restriction actually configured.Keep any unproved restriction marked unverified; do not infer it from Editor membership.
Approval ownerPerson approving the content and person authorizing account permissions.Distinguish permission to use the software from authority to publish a particular business claim.
Expiry conditionAgreed project milestone or review date, and administrator responsible for removing unneeded access.A worksheet date is a handoff instruction, not evidence of automatic revocation.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.

Limits

  • The documented Administrator and Editor comparison is for default roles on a single WordPress site. Confirm the effective capabilities of the actual installation.
  • A WordPress role does not establish arbitrary file ownership or a project-specific page allowlist.
  • Content publishing access does not confer authority over payment accounts, underwriting decisions or legal approval of claims.
  • Keep passwords, API secrets, customer records and payment-card details out of the worksheet and public inquiry.

Sources

  • WordPress roles and capabilities — checked 2026-09-21. On a single WordPress site, an Administrator can manage users, plugins, themes and options; an Editor can publish content without those default administration capabilities. This role comparison does not establish a project-specific file boundary.
  • Prism: How it works — checked 2026-09-21. A Prism consultation defines the pages, questions and follow-up before work; scope, fees and terms are confirmed and the merchant chooses which updates to make.
  • Prism solutions — checked 2026-09-21. Prism's public support includes storefront review, processing preparation and help with provider website questions. Scope is discussed before work; eligibility and account terms remain provider decisions.
  • Prism contact — checked 2026-09-21. The inquiry asks for the website, products and question and excludes passwords, payment-card details and customer records. Follow-up is by email; a request does not book an appointment, purchase work or submit a processing application.

Discuss my store project

Planning, moving or taking over a store?