wordpress

意外と見られていた旧ブログ ブログをHugoにリニューアルし、WordPressの方はずっと放置していた。 先日ふっと思い立ちこのブログにもアナリティクスを導入した。その時ちらっと見たWordPressのアナリティクスの数字は自分の想像を遥かに絶するものだった。 さすがにこれはもったいないと、お引越しをすることにした。 幸いWordPressブログなのだが、記事はGitで管理していた（使わなかった…）。 これ幸い、引っ越しを始める。 記事一覧の取得 まずは記事一覧の取得を行っていく。 WordPressの拡張機能であるExport All URLsを使い、URLを出力した。 Post ID Title URL Categories Tags Published Date 42 GithubActionを使用してエックスサーバーにデプロイする https://media.nove-web.com/42/ Github Github, Github Action, Wordpress, エックスサーバー, 効率化 2021/11/28 16:24 こんな感じの一覧が出力された。 次に出力したタイトルをパスパラメータ―に変換していく。 これが本当にしんどいけど、Chat GPTが全部やってくれました。 記事ファイルをxmlに変換する WordPressの管理画面からxml形式にエクスポートをする。 エクスポートしたファイルをxml-to-markdownというフォルダに格納し、npx wordpress-export-to-markdownを実行する。 ? Path to WordPress export file? name.WordPress.2024-06-07.xml ? Path to output folder? output ? Create year folders? No ? Create month folders? No ? Create a folder for each post? No ?...

WordPressのテーマをどう管理するか Local（旧Local by Flywheel）を使用してワードプレスのテーマを作成する時、フォルダ構成とかをどうすればいいのかいつも悩んでいた。 作成したテーマをGithubで管理する場合は、Local（旧Local by Flywheel）のフォルダ構成の中にテーマフォルダを作成し、その中をGit管理し、node_modulesもそこで管理していた。 ただ本当にそれでいいのかしら。 テーマの中にnode_modulesがある場合はワードプレスにアップロードする時はnode_modulesは削除したりして運用していたが、面倒くさい。 そんな時に、いまさらながらと思われるかもだが、シンボリックリンクを知った。 シンボリックを使用してみる シンボリックリンクを作成すれば、 . ├── .git ├── node_modules ├── package.json ├── src └── theme-name ├── assets ├── index.php └── ...etc 上記のようなディレクト構成にし、開発ディレクトリのsrcにあるSassとtsのようなコンパイルが必要なものを theme-nameにビルドすることで、theme-nameに不要なものを格納せずに済む。 そのうえで、theme-nameをLocal（旧Local by Flywheel）のwp-content/themes/theme-nameとリンクさせれば、良い。 コマンドプロンプトを管理者で開き、下記コマンドを実行する。 mklink /D "C:\Users\USER_NAME\Local Sites\SITE_NAME\app\public\wp-content\themes_link" "C:\Users\USER_NAME\デスクトップ\SITE_NAME\wp\wp-content\themes/theme-name" 上記はシンボリックを作成するコマンドで mklink /D <シンボリックリンクのパス> <リンク先のパス> となる。

WordPressのバージョン管理はSubversion で行われるのだが、なかなか慣れずに更新が億劫になってきたので、Githubで更新できるようにしてみた。 過去関連記事 Subversion (SVN) を使用し承認されたWordPressプラグインをリリースしてみる Github Actionを使用する 10up.comがWordPress.orgのプラグインリポジトリにデプロイするGitHub Actionsを公開してくれているので、それを活用させていただく。 Github リポジトリを作成する ディレクトリ構成 まずはいつも通りGithubのリポジトリを作成する。 本当にいつも通りで問題ないけれど、WordPressのスラッグのとリポジトリ名を揃えた方が後々ほんの少しだけ楽になる。 ディレクトリ構成は下記のようにする。 . ├── .wordpress-org │ ├── banner-772x250.png │ ├── icon-128x128.png │ └── screenshot-1.png ├── README.md ├── plugin-sample.php └── readme.txt .wordpress-orgにSVNリポジトリのassetsフォルダの中身をコピーする。 Github Action を作成する リポジトリのActionsへ行き、New workflow → set up a workflow yourself でYAMLファイルの作成画面に行く。 ファイル名はわかりやすい名前（ex:wordpress-plugin-deploy）を指定する。 次にaction-wordpress-plugin-deployページにあるExample Workflow Filesの内容をコピペする。 name: Deploy to WordPress.org on: push: tags: , "*" jobs: tag: name: New tag runs-on: ubuntu-latest steps: - uses: actions/checkout@master - name: Build # Remove or modify this step as needed run: | npm install npm run build - name: WordPress Plugin Deploy uses: 10up/action-wordpress-plugin-deploy@stable env: SVN_PASSWORD: ${{ secrets....

WordPressの記事管理に頭を悩ませてきた。 で、行きついた先が、今後のことを考え、WordPressの記事をGitで管理しGithubに一元管理することにしただったのだが、色々運用を決めていくとどうにも面倒で仕方なくなってきた。 Githubでの運用方法 書きたい題材が見つかった時にIssueをたてる Issueからブランチをきり、記事を作成する プルリクを作成する 記事をWordPressにコピペ 公開 プルリクを承認する という手順を自らに課したせいで、更新が億劫で仕方なかった。 そんなときに救世主であるWordPress PostというVSCodeの拡張機能にであった。 WordPress Postとは？ この Visual Studio Code 拡張機能は、WordPress に記事を投稿するアクションを提供します。これは、人々が Visual Studio Code を使用して Markdown で WordPress 記事を作成するのに役立ちます。 簡単に言うと、VSCodeで記事を書き、WordPressの管理画面を開くことなく、公開まで持っていける。 という最強の拡張機能！ 使い方は作者のブログに詳しい。 これにより先ほどの手順が驚くほど簡略化された。 WordPress Postを使った公開手順 記事を下書き設定で書く WardPressからカテゴリ・タグ・アイキャッチ画像を選択 公開 WardPressからカテゴリ・タグ・アイキャッチ画像を選択 は個人的に独自の手法を使っているのでまあ仕方ない。 管理画面に行かなくてはいけないものの、相当簡略化された。 さらに当然Git管理も問題ない。 来世でも使うと思われるVisual Studio Codeの拡張機能をまとめてみた間違いなく、こちらの記事に更新をかけ、追加するべき拡張機能である。 だがしかし、過去にこれで管理してないファイルはどのように対処する必要があるのか…? たぶん、過去のは二元管理になるかしら。 とは言え、この拡張機能が素晴らしいことは間違いない。

まず大前提としてWordpressの初心者である。 いや、初心者は言い過ぎだろうか、いや、そんなことない、初心者である。 自作テーマはいくつも作ってきたが、それをWordpressの公式テーマとして申請したこともなければ、プラグインの申請をしたこともない。 全て野良で行ってきた。 つまり、Wordpressに関してまったくの初心者であると言っても過言ではない。 そんな私が一からWordpressのプラグインを公式配布するまでの手順を調べてみたので、ここに残しておく。 大前提だが、プラグインは作っておく必要がある 言うまでもないと思うのだが、念には念を入れ言っておくと、プラグインは作った状態で以降進んでいく。 いやプラグインの作り方がわからないのだが、というのであればそれはまた別の記事にするので見てほしい。 ただ記事にしない可能性もあるので、気長に待つよりは他の人の作成方法を見たほうが得策かもしれない。 さて、つまりこの段階でプラグインが完成しているという前提で次の話にいく。 WordPress.orgのアカウントを作成する これはプラグインの申請に必須なアカウントになるので、まず最初にやっておくことにする。 WordPress.org ログイン ｜ WordPress.org 日本語 作成は上記リンクからできる。 何回か通信が遮断されてストレスを感じたけど、特に難しいことなくアカウントを作成できた。 しかしまったく管理するアカウントが増えて仕方ない。 が必要なのであればそれは仕方ない。 申請用にreadme.txtを準備する アカウントができたら次に進む。 「readme.txt」に書かれた内容が、公式サイト個別プラグインのページや管理ページからのインストール画面に表示されるらしい。 申請に必須かどうかわからないけど、とりあえず埋めることのできる箇所は埋めてみた。 書き方に関しては「Plugin Readme Generator」なるものがあったので、そちらを利用した。 でき上がったのが、 === Create Eye Catch For Classic === Contributors: nove2b Tags: eyecatch,ogp You can read the title of the entered blog article and automatically generate a featured image. こんな感じ。 まあ、これじゃインストールされないだろうけれど、とりあえず今できる最低限の情報は入力した。 後は無事に申請が通った後に拡張していくことにする。 ちなみに英語はできないので、Google翻訳のお世話になった。 Readme Validatorにかけ、readme.txtのバリデーションをする Readme Validator 上記公式のバリデーションに書けることで「readme.txt」の記入漏れ、記載ミスを見つけることができる。 早速、バリデーションをすると、警告が表示された。 曰く、 Tested up to フィールドを入力してください。 Stable tag フィールドがありません。ヒント: /trunk/ を安定版として扱う場合は Stable tag: trunk と入力してください。...