This is a plugin that extends Gutenberg's blocks.
Free version : https://github.com/vektor-inc/vk-blocks Rro version : https://github.com/vektor-inc/vk-blocks-pro ( Private )
- XAMPP 7.4 系をインストール
- Composer をインストール
- VS Code で Git Bash を使えるようにしておく
- Docker
- @wordpress/env をグローバルインストール(
npm install -g @wordpress/env
) - NodeJS、NPM
npm install
npm install -g @wordpress/env
composer global require wp-cli/wp-cli-bundle
npm start
// 本番環境用
npm build
// 翻訳のみ
npm run translate
// 開発用(開発者ツールのconsoleでログが追いやすくなる)
npm run build:dev
// リリース用(石川専用:gulp dist して zip に圧縮してそのzipファイルをvwsのパッケージディレクトリに移動している)
bin/dist_kuru.sh
// CSS、JSの監視
npm run watch
// .pot ファイル生成、.po ファイルから翻訳用JSONを生成
npm run translate
翻訳は PoEdit などを使って .po
ファイルを開いて編集するが、
新たに翻訳箇所が追加された場合はメニューから「potファイルから更新」を選んで更新する
composer install
npm run phpunit
npm run test:e2e
GUI無しの場合
npm run test:e2e-no-gui
wp-env の port を変更している場合
WP_BASE_URL='http://localhost:xxxx/' npm run test:e2e
単体で動かしたい場合
npm run test:e2e ./test/e2e-tests/specs/xxxx.test.js
wp-env の port を変更していて、単体でテストしたい場合 (spacerの例)
WP_BASE_URL='http://localhost:xxxx/' npm run test:e2e ./test/e2e-tests/specs/spacer.test.js
準備
npm install
wp-env start
Playwriteは操作を自動的トラッキングしてコードを出力してくれます。 以下のようにテスト対象のURLを指定して叩くと、ブラウザが起動してトラッキングを開始します。
npx playwright codegen "テスト対象のURL"
例えばWordPressのログイン画面からの動作テストを作る場合は以下のようになります。
npx playwright codegen "http://localhost:8889/wp-login.php"
全てのテストの実行
npx playwright test
ブラウザは chrome だけで良い場合
npx playwright test --project=chromium
操作のスクリーンショットが見たい場合 --trace on を追加
npx playwright test --trace on
npx playwright test --trace on --project=chromium
npx playwright show-report
プッシュ時にphpのformat、phpcsのチェック、 コミット時にlintが実行されます。 それぞれ、エラーがある場合コミットやプッシュができません。
fix:バグ修正 hotfix:クリティカルなバグ修正 add:新規(ファイル)機能追加 update:機能修正(バグではない) change:仕様変更 clean:整理(リファクタリング等) disable:無効化(コメントアウト等) remove:削除(ファイル) upgrade:バージョンアップ revert:変更取り消し
develop ブランチにマージされると自動でテストサーバー https://vk-block-test.vs4.nagoya/ にデプロイされます。
[ prefix ]_[ ブロック名 ]
[ prefix ]_[ ブロック名 ]_[ divのクラス名 ]
※ 当初は下記のように必ずすべての階層を記載していたが、運用が難しかったので version 1.17 以降は途中の div のクラス名は省略可に変更
[ prefix ]_[ ブロック名 ]_[ divのクラス名 ]
[ prefix ]_[ ブロック名 ]_[ divのクラス名 ]_[ 子のdivのクラス名 ]_[ 孫のdivのクラス名 ]
[ prefix ]_[ ブロック名 ]-[ 属性名 ]-[ 属性値 ]
[ prefix ]_[ ブロック名 ]_[ divのクラス名 ]-[ 属性名 ]-[ 属性値 ]
ちなみに 線の あり/なし など 「属性値なしで -border とかだけでいいんちゃう?」 と思うケースがあるが、今後も属性値の拡張がありえない場合、たとえば 線でも あり/なし だけではなく 直線/点線/二重線 など拡張が想定される可能性がありそうな場合は -border-solid としておき -border-dotted -border-wave とする事ができるようにしておく。 何がなんでも あり/なし 以外以外発生しないというケースの場合は -border-true あるいは例外的に -border など属性名だけでも可
- 'is-style-' はコアがブロックの一番外側のタグに対してつけるものなので、もし使用するならブロックの一番外側のタグでのみ使用可
- VK Blocks でしか使わないスタイル名に対して追加するなら vk_[ ブロック名 ]-style-[ 属性名 ]
スマホ
@media (max-width: 575.98px)
タブレット
@media (min-width: 576px) and (max-width: 991.98px)
PC
@media (min-width: 992px)
イレギュラー : 管理画面側での指定はなく、CSSでブレイクポイントが一つの場合(モバイル/PC など)以下の設定がありえる
@media (min-width: 768px)
VK Blocks の現在のデプロイフローは以下の通り [ ★ ] の部分が手作業
現状以下のような課題があるので、更に抜本的な見直しが必要
- master で pre_ ナシの本タグでプッシュする人為的ミスが起こりうる
- e2eが自動で走っていない
- まだ手作業部分が多い
- GitHubリリースされたデータがそのまま配信されるわけじゃない
- リリースnoteなどが自動で作成したい
- .huskey で lint チェック
- lint チェック
- deprecated チェック
- ( e2eテスト( 調整中 ) )
- PHPUnit テスト
- 確認用サーバーにデプロイ
編集画面を開くと Deprecated が走ってしまうので、まずは表側を確認する
- [ ★ ] 公開画面目視確認(表示崩れがないか)
- [ ★ ] 編集画面目視確認(Deprecatedなど発生していないか)
- 翻訳の変更が必要な場合は翻訳
- バージョン番号を変更してコミット
- master へプルリクエスト
- [ ★ ] vk-blocks-pro/master マージ
- [ ★ ] vk-blocks-pro/master をローカルでプル
- [ ★ ] タグ付け
git tag pre_*.*.*.0
からのgit push origin pre_*.*.*.0
※ プラグイン内のバージョン番号は数字だけだが、ここで処理工程の都合上 pre_ をつける
(→ 無料版のデプロイフローも自動実行される)
タグを消して付け直せば良い
git tag -d pre_*.*.*.*
でタグ削除
git push origin :pre_*.*.*.*
でリモートタグ削除
- build -> composer install -> dist
- zip 化して GitHub リリース作成
- VK Block Pro 単体動作確認サイトに送信 -> Fatal Error があれば通知メールが届く
- Lightning G3 Pro Unit 動作確認サイトに送信 -> Fatal Error があれば通知メールが届く
- [ ★ ] GitHub のリリースの zip ファイルをダウンロード
- [ ★ ] デモサイトなどにアップして確認
修正して再度プルリクになるが、ここでの不具合修正はもともと「決定済みの期待する動作」の修正なので、プラグインに記載のバージョン変更の必要はない。 但し、予定外の変更を加える場合は内容に応じて変更&変更箇所を readme.txt に記載する必要がある
- [ ★ ] タグ付け
git tag *.*.*.0
からのgit push origin *.*.*.0
*.*.*.*
のタグで実行される
- build -> composer install -> dist
- VWS 配信サーバーにデプロイ
- [ ★ ] デモサイトなどで管理画面からのアップデート確認
vk-blocks-pro のリポジトリで pre_*.*.*.*
のタグで実行される
- Pro版ディレクトリ内に無料版をGitHubからクローン
- vk-blocks-pro/bin/deploy-free.sh 実行 この時タグ情報も deploy-free.sh に送る
- クローンした無料版のディレクトリ名変更
- 無料版のディレクトリに移動
- 無料版 src/ を一旦削除
- Pro版ディレクトリに移動
- Pro版関連のファイルを除外して無料版ディレクトリに複製
- 無料版ディレクトリに移動
- vk-blocks.php のプラグイン名を書き換え( VK Block Pro から VK Blocks へ )
- Pro版のブロックのPHPファイル読み込みを削除(inc/vk-blocks/vk-blocks-functions.php)
- Pro版のjs読み込みを削除(src/blocks/bundle.js)
- 無料版の composer install --no-dev
- 無料版をビルド
- 無料版をコミットしてプッシュ
- 無料版のタグ付けをしてプッシュ
- composer install -> PHPUnit
- VK Block 単体動作確認サイトに送信 -> Fatal Error があれば通知メールが届く
- Lightning G3 無料版 動作確認サイトに送信 -> Fatal Error があれば通知メールが届く
- [ ★ ] GitHub のリリースの zip を落とし デモサイトなどにアップして確認
readme.txt の stable のバージョンを上げずに一旦リリースする
- vk-blocks/master でタグ付け
*.*.*.*
- vk-blocks/.github/workflows/wp-plugin-deploy.yml で .org に配信される
- [ ★ ] プラグインベータテスターを使ってアップデートして確認
- [ ★ ] バージョン番号の末尾の数字を上げる (
*.*.*.0
->*.*.*.1
) - [ ★ ] readme.txt の stable のバージョンを上げてコミット
- [ ★ ] vk-blocks/master でタグ付け
*.*.*.1
- vk-blocks/.github/workflows/wp-plugin-deploy.yml で .org に配信される
- [ ★ ] デモサイトなどでアップデートして確認