cwp content open
shipped 1.0.0cwp content open <slug> [env] [flags]
Acts on the local site. Name an environment to act there instead.
| Argument | What it is | Default |
|---|---|---|
<slug> | the page’s slug, as cwp content status prints it | |
[env] | environment to open it on (default: default_environment in cwp.yml) |
| Flag | What it does | Default |
|---|---|---|
--type <type> | narrow to one post type, when a slug belongs to several | |
--print | write the URL to stdout and open nothing | off |
--with-agent | with —dry-run on a host with no shell: install and remove the PHP agent so the plan is real | off |
Plus the shared flags --json, -v, --verbose, -q, --quiet and --dry-run.
What it does
Resolves a slug to the URL that site itself would use, and opens it.
It exists because of the two commands next to it.
cwp content status prints a table whose rows are pages. The next
thing anybody does with a row that says changed here is look at the page:
cwp content status
cwp content open ueber-uns # the local site
cwp content open ueber-uns dev # the same page on dev
[env] omitted is the local DDEV site, as everywhere else under cwp content.
The URL comes from WordPress, not from the site URL plus the slug. A child
page lives at /ueber-uns/team/. A permalink structure that is not “post name”
is nothing a client can reconstruct. So the command asks the site, through
get_permalink().
--print writes the URL to stdout and opens nothing, for a pipe or for a
machine whose opener cwp does not know. It does not combine with --json. The
two claim the same stream. When there is no opener at all, on a headless box or
a platform with no verified command, the URL goes to the human output and the
run still exits 0. Knowing the URL is most useful exactly there.
What it refuses
A slug that is two pages. A slug is unique per post type, not across them,
so termine can be a page and an event. Opening one of them at random is the
bug this refusal exists for:
✗ "termine" is 2 different pages on "dev": page, event
→ name the one you mean: --type page
A slug that is nowhere. The answer depends on whether the tree describes one. A typo and a page nobody has pushed yet differ exactly there:
✗ no page called "termine" on "dev"
→ the tree describes it (page), so it has not been pushed there yet —
`cwp content push dev --post termine`
The search space is the post types the content groups declare, the same set
--post uses. The command does not find a page outside content management
even when the site has one.
What it does not do
It does not render or capture anything. It opens a URL; the browser draws
the page. For a screenshot, --print gives you the URL to hand to whatever
capture tool you already have.
It does not find a page by uid or by post id. The survey prints the slug and a person reads it. The other two identify the same page, and neither is in front of you when you want it.
It does not tell you the page is a placeholder. A local site in Bricks’
coming-soon mode serves the maintenance template to visitors. cwp doctor and
cwp pull report that (F-068).