See the whole site Free
WP-CLI and CI checks
wp lumtera scan, check, stats, issues and rules — with exit codes, baselines that fail only on new issues, and SARIF or JUnit output for your pipeline.
Updated for Lumtera 1.2.2 and Lumtera Pro 1.1.1.
Overview
Lumtera adds a wp lumtera command with five subcommands. scan checks posts and stores the results exactly as saving them would. Pass post IDs, or --all, optionally narrowed with --post_type and --status, or --parts to check the template parts, synced patterns, navigation menus and widget areas every page shares. Output can be a table, JSON, CSV, or --format=summary for totals only, and an interactive terminal shows a progress bar.
check reads HTML and stores nothing: a file, standard input (pass "-" or pipe it in), or --page with a URL or path on this site, such as --page=/about/. Whole documents are checked as pages, including the theme's markup around the content, and block markup is rendered first. --format can be table, json, sarif (SARIF 2.1.0, for GitHub code scanning) or junit. It exits with status 1 when it finds an issue at or above --fail-on, and status 2 when the input cannot be used.
Baselines let a pipeline fail only on new problems: --write-baseline=<file> records every current finding, and --baseline=<file> leaves those out, so only new findings count towards the exit status; SARIF keeps the old ones, marked "unchanged". check and issues both take them. stats prints the site totals and the most frequent problems. issues lists every stored open issue, filtered by --rule, --severity and --post_type, and streams CSV, JSON, SARIF or JUnit. rules lists every check with its WCAG criterion, level, severity and the setting chosen in Lumtera.
Why does it matter?
Theme and template changes can introduce accessibility errors on hundreds of pages at once, and nobody opens the editor to notice. Developers need the same checks in the terminal and in their deployment pipeline.
What do you get?
- wp lumtera scan: check everything, a post type, specific posts, or with --parts the site parts every page shares.
- wp lumtera check: check a file, standard input or a page URL on the same site; exits with an error code when it finds issues at or above the --fail-on level (errors by default).
- Baselines: --write-baseline records today's issues, and --baseline makes the build fail only on new ones.
- --format=sarif for GitHub code scanning, or --format=junit for other CI tools.
- wp lumtera stats and issues: site totals, and every stored issue as a table, CSV, JSON, SARIF or JUnit.
How does it work?
-
Run a scan
wp lumtera scan --all brings the site report up to date.
-
Record a baseline
wp lumtera check --page=/ --write-baseline=.lumtera-baseline.json records the issues the page has today.
-
Check in CI
wp lumtera check --page=/ --baseline=.lumtera-baseline.json --format=sarif fails the job only when a new issue appears, and writes a file GitHub code scanning can read.
Who is it for?
-
Developers shipping theme changes
Run wp lumtera check --page against key pages on staging after a deploy, with a baseline, and fail the pipeline only if new errors appear.
-
Agencies taking on a new site
wp lumtera scan --all --format=summary builds the first set of results in one command, without keeping a browser tab open.
-
Teams using GitHub code scanning
Write SARIF from check or issues and upload it to your repository's code scanning, with a baseline so issues you already know about do not block new work.
Good to know
How it behaves, what it needs, and where its limits are.
- Fail only on new issues
- Record a baseline once with --write-baseline, commit it, and pass it with --baseline in CI. An earlier SARIF log also works as a baseline. A file that cannot be read as a baseline exits with status 2.
- Default threshold
- For check, only errors return status 1 by default. Use --fail-on=warning to include items that need review, --fail-on=notice to include tips, or --fail-on=none to report without failing. For issues, --fail-on is none unless you set it.
- How --page fetches
- Only http or https addresses on this site's own host are fetched, with at most three redirects that must stay on the site, a 15-second wait and a 5 MB limit. The page is fetched as a logged-out visitor, so drafts and private pages cannot be reached this way.
- check stores nothing
- Results from check do not appear in the Overview or Content report; use scan to update stored results. With --page, --stored also includes the last whole-page results a browser saved for that address, for the contrast, keyboard and layout checks that need a real browser.
- Whole pages
- On a full page, the "H1 inside the content" check is skipped, because the theme usually supplies the page's H1. Without saved browser results, color contrast is judged only where the markup itself sets both colors.
Questions
Something else on your mind? Contact support
Can it check pages from other sites?
No — --page accepts URLs on the same site, which keeps it from being used as an open fetcher.
Why is the option called --page and not --url?
--url is WP-CLI's own global option for choosing a site. Lumtera uses --page so the two never clash.
Can I scan only published pages?
Yes: wp lumtera scan --post_type=page --status=publish. The post type must be enabled in Lumtera's settings, and --status accepts publish, draft, pending, private and future.
How do I tell failed checks from bad input in CI?
Status 1 means issues at or above --fail-on were found. Status 2 means the file, standard input, URL or baseline could not be used, for example a refused address or an HTTP error, or that an option was wrong, such as an unknown --rule or a --post_type Lumtera does not check. A typo never looks like issues found.
More in “See the whole site”
-
Free
Site-wide report and bulk checking
Check every post, page, product and site part, then see the score, errors, review coverage and the issues that repeat across the site. Export it as CSV.
-
Free
Fix at the source, with site parts
Headers, footers, menus, synced patterns and widget areas are checked on their own, so a problem on every page is shown once and fixed once.
-
Free
Honest coverage meter
Next to every automated score, a meter shows how many WCAG 2.2 A/AA criteria the checks cover, how many have evidence and how many need a person.
Start with the free plugin today
All 69 content checks and 33 whole-page checks, fixes you approve with undo, and the site report — free, with no account and no page limits.