wordpress-plugin-publish

Gunakan keterampilan ini saat menerbitkan, mengirimkan, mengunggah ulang, memverifikasi, mengemas, memeriksa, mendemokan, atau merilis plugin WordPress.org dengan Pressship. Ini mencakup…

npx skills add https://github.com/automattic/pressship --skill wordpress-plugin-publish

WordPress Plugin Publish

Use Pressship for WordPress.org plugin submission and release work. Prefer npx pressship unless the user explicitly wants the local checkout version or the WP-CLI package (wp ship).

Install Surfaces

Use the install surface the user asks for:

npx pressship verify .
wp package install f/pressship
wp ship verify .
npm install -g pressship
pressship verify .

For agent skill installation:

npx skills add f/pressship --skill wordpress-plugin-publish -a codex
npx skills add f/pressship --skill wordpress-plugin-publish -a claude-code

Safety Rules

  • Never publish, submit, reupload, or release without first running a dry run, unless the user explicitly says to skip it.
  • Do not push git commits or tags unless the user explicitly asks.
  • Report Plugin Check findings clearly. Do not hide them just because Pressship can continue.
  • Use repeatable excludes for large or source-only files. Prefer .pressshipignore when the project already has one.
  • Use --no-verify only when the user explicitly asks to bypass readme validation and Plugin Check.
  • If Pressship prompts interactively, answer only with user-approved or obvious plugin metadata.
  • If authentication fails, run npx pressship login and let the user complete WordPress.org login.
  • For approved-plugin SVN releases, expect Pressship to verify before SVN changes, reject already-published versions, and ask for a generated WordPress.org SVN password when needed.

Orientation

From the plugin directory:

npx pressship whoami
npx pressship verify .
npx pressship status .
npx pressship info .
npx pressship info --remote

Use status to determine whether publish will target a pending submission reupload or an approved SVN release. Use verify when you need readme validation and Plugin Check without creating a zip.

Local Playground Test

Start a local WordPress Playground with the plugin mounted:

npx pressship demo .

Useful options:

npx pressship demo . --port 9401
npx pressship demo . --wp 6.8 --php 8.3
npx pressship demo . --reset
npx pressship demo . --skip-browser

Verify And Package

Run the publishing checks without creating a zip:

npx pressship verify .

Create a validated WordPress-installable zip without uploading:

npx pressship pack .

For projects with bulky assets or source-only files, pass explicit ignores:

npx pressship pack . --ignore "assets/**" --ignore "src/**" --ignore "node_modules/**"

pack, publish, submit, and SVN release verify by default. If the user explicitly chooses to bypass checks, use the unified flag:

npx pressship pack . --no-verify
npx pressship publish . --no-verify

Inspect package file count and included paths. Make sure the ZIP contains runtime PHP, built assets, readme.txt, and any required examples or static assets. Confirm .pressship-svn is never included.

Submit Or Reupload Pending Review

Use this for new plugins or WordPress.org submissions still awaiting review.

Dry run first:

npx pressship publish . --dry-run -y

Then upload:

npx pressship publish . -y

When the project contains large non-distribution directories, repeat the same ignore flags in both commands:

npx pressship publish . --dry-run -y \
  --ignore "assets/**" \
  --ignore "src/**" \
  --ignore "scripts/**" \
  --ignore "package.json" \
  --ignore "package-lock.json" \
  --ignore ".github/**" \
  --ignore "node_modules/**" \
  --ignore "dist/**"

npx pressship publish . -y \
  --ignore "assets/**" \
  --ignore "src/**" \
  --ignore "scripts/**" \
  --ignore "package.json" \
  --ignore "package-lock.json" \
  --ignore ".github/**" \
  --ignore "node_modules/**" \
  --ignore "dist/**"

After upload, confirm:

npx pressship status .

Release Approved Plugin

Use this only when the plugin is already approved and the user wants a WordPress.org release.

For an existing WordPress.org plugin, the normal SVN-based edit flow is:

npx pressship get my-plugin ./my-plugin
cd ./my-plugin
npx pressship version patch
npx pressship publish --release --dry-run -y
npx pressship publish --release -y

Pressship treats the SVN checkout root as the project root and edits trunk/. It should stop with "No version change detected" if the target tag already exists.

Dry run first:

npx pressship publish . --release --dry-run -y

Then release:

npx pressship publish . --release -y

If Pressship cannot infer the slug or username:

npx pressship release . --slug my-plugin --username WpOrgUser --dry-run
npx pressship release . --slug my-plugin --username WpOrgUser -y

If svn is missing, let Pressship detect the OS and offer installation, or pass --no-install-svn only when the user wants manual setup. If the SVN password is missing, Pressship points to the user's WordPress.org SVN password page and saves the generated password locally after they provide it.

Version Bumps

Only run version bumps when the user asks:

npx pressship version patch .
npx pressship version minor .
npx pressship version major .

After a version bump, review changed plugin headers, readme.txt stable tag, and changelog.

Final Report

Always include:

  • Whether a dry run was run.
  • Whether verify ran and whether validation was bypassed.
  • Package size and notable included/excluded files.
  • Plugin Check result summary.
  • Upload/release status and slug.
  • SVN checkout/tag status for approved releases.
  • Whether git was left untouched or changed.

Lebih banyak skill dari automattic

wp-phpstan
automattic
Gunakan saat mengonfigurasi, menjalankan, atau memperbaiki analisis statis PHPStan di proyek WordPress (plugin/tema/situs): pengaturan phpstan.neon, baseline,…
official
wp-playground
automattic
Gunakan untuk alur kerja WordPress Playground: instance WP cepat yang dapat dibuang di browser atau secara lokal melalui @wp-playground/cli (server, run-blueprint, build-snapshot),…
official
wp-plugin-development
automattic
Gunakan saat mengembangkan plugin WordPress: arsitektur dan hooks, aktivasi/deaktivasi/pencopotan, antarmuka admin dan API Pengaturan, penyimpanan data, cron/tugas, keamanan…
official
wp-project-triage
automattic
Gunakan saat Anda memerlukan inspeksi deterministik terhadap repositori WordPress (plugin/tema/tema blok/WP inti/Gutenberg/situs penuh) termasuk perkakas/pengujian/versi…
official
wp-rest-api
automattic
Gunakan saat membangun, memperluas, atau men-debug endpoint/rute REST API WordPress: register_rest_route, kelas WP_REST_Controller/controller, skema/argumen…
official
wp-wpcli-and-ops
automattic
Gunakan saat bekerja dengan WP-CLI (wp) untuk operasi WordPress: pencarian-pengganti yang aman, ekspor/impor db, manajemen plugin/tema/pengguna/konten, cron, pembersihan cache,…
official
wpds
automattic
Gunakan saat membangun antarmuka pengguna yang memanfaatkan WordPress Design System (WPDS) dan komponen, token, pola, dll.
official
woocommerce-finalize
automattic
Audit kesehatan kode dan ketertelusuran pra-rilis untuk plugin WooCommerce. Dijalankan setelah tinjauan kode -- berfokus pada kode mati, duplikasi, kompleksitas struktural, dan…
official