[Rookie Dev]

URL関係でadd_rewite_ruleという関数もあります

コチラの関数はWordPressに「このようなURLが来たら、実際はこの内容を表示して」と教える機能です。
詳細は下記です

/**
* WordPressにカスタムURLリライトルールを追加する
* 
* @param string $regex URLにマッチさせる正規表現パターン
* @param string $query 内部的なWordPressクエリ文字列（$matches[n]でキャプチャグループを参照可能）
* @param string $after ルールの優先順位 ('top'=最優先, 'bottom'=最後)
* @return void
*/
add_rewrite_rule($regex, $query, $after);

[Rookie Dev]

.htaccessファイルをどこのディレクトリに置くかについて説明します！

.htaccessは設置したディレクトリおよび下位のディレクトリに対して設定が適用されます。

.htaccessは「そのディレクトリへのアクセス」をキャッチして処理するため、
リダイレクト元のURLが属するディレクトリ、もしくはより上位のディレクトリに置く必要があります。

そのうえで「必要最小限の影響範囲で設定する」という意味でリスクが低いのは、
より下層のディレクトリになります。

またドキュメントルートに1つ配置して、全体をまとめて管理する運用もあるかと思います。

[Rookie Dev]

いくつか選択肢があります！

• WordPress関数wp_redirectを使用する

  wp_redirect('/new-page/', 301);
  exit;

  この関数はログインの制御やフォーム送信後のリダイレクトなどで使用されます
  動的処理に向いてます。

  内部的にはPHPのheader()です

• プラグインではRedirection、Simple 301 Redirects等が簡単に使用できます
• .htaccessでもリダイレクトの設定は可能です
  固定的なURL、大量なリダイレクト、高速処理
  処理タイミングがになりますWordPressが起動する前になります。

[Rookie Dev]

リダイレクト用のWordPressのプラグインもあるので、
活用できそうであれば！

https://ja.wordpress.org/plugins/eps-301-redirects/

[Rookie Dev]

パーマリンクを投稿名を含んだものにして、文字に日本語が含まれると
URLが異常に長くなる（日本語1文字 = 約9文字のエンコード）のが問題ですね

パーマリンク設定を投稿名から英数字ベースに変更が推奨ですが、
既存記事が多い場合は段階的アプローチが現実的です。

パーマリンク設定は投稿名のまま維持して、新規記事のスラッグのみ手動で英数字に変更します。これで既存記事のURLは変わらず、リンク切れを回避できます。

既存記事は重要度に応じて順次対応し、スラッグを英数字に変更後、旧URLから新URLへ301リダイレクトを設定します。

理論上は全記事移行完了後にパーマリンク設定自体を数字ベースに変更できますが、
実際には投稿名設定のまま運用継続することが多くなります。

[Rookie Dev]

パーマリンクの本質はクエリを見やすいURLに変換する機能です！

WordPressダッシュボードの「設定 > パーマリンク設定」で切り替え可能です。

どのパーマリンク設定を選んでも
投稿オブジェクトは変わらずURLの見た目だけが変わるだけです

[Rookie Dev]

originとはリモートリポジトリの名前です。

HEADだけだと今ローカルで作業しているブランチを指します。

origin/HEADはoriginという名前のリモートリポジトリのデフォルトブランチを意味します！

デフォルトブランチとは
GitHubなどで「初期表示・初期チェックアウト」に使われるブランチです（mainやmaster）

[Rookie Dev]

generateStaticParams は Next.js の「予約済み関数」です。関数名を変えると動作しません

next build 実行時に generateStaticParams() が呼ばれます。
一般的には下記のように動的ルート [param] に対し、静的に生成するパスを定義します

（例）

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await fetch('https://example.com/api/posts').then(res => res.json());
  return posts.map((post) => ({ slug: post.slug }));
}

参考記事
https://nextjsjp.org/docs/app/api-reference/functions/generate-static-params

[Rookie Dev]

WordPressとTailwind CSSの相性が悪い理由

• CSS Reset（Preflight）の競合
  Tailwindが全てのデフォルトCSSをリセット → WordPressの既存スタイル・プラグインCSSが破綻
• 動的コンテンツとの不整合
  WordPressは投稿内容やプラグインが動的にHTMLを生成 → Tailwindは事前にクラス名を書く必要がある
• ビルドしたCSSファイルがGit管理でコンフリクトを起こす
  開発者ごとにNode.jsのバージョンが違う
  npm install時のパッケージバージョンが微妙に異なる
  ビルド時刻やハッシュ値がファイルに含まれる

個人的にGit管理でコンフリクトはクリティカルかと

[Rookie Dev]

npm iはnpm installの短縮形で、パッケージをインストールするコマンドです。
実行すると、package.jsonに記載された依存関係をnpmレジストリからダウンロードし、node_modulesフォルダに保存します。

チーム開発では、実際のファイル群（node_modules）ではなくpackage.jsonをGitで共有します。
受け取った人がnpm iで環境を再現します。

つまり、メンバーが新しいライブラリを追加してpackage.jsonが更新されたら、他のメンバーはnpm iを実行して環境を同期する必要があります。

[Rookie Dev]

このエラーの原因は、
SSHキーがGitHubに登録されていないか、
SSHエージェントに読み込まれていないためですね！

以前は接続てきていたようなので、以下の通りすれば解決

• SSHエージェントを起動
  eval "$(ssh-agent -s)"
• SSHキーのファイルの状況を確認
  ls ~/.ssh/ -la
• SSHキーをエージェントに追加
  ssh-add ~/.ssh/[your-key]
• キーが正しく追加されたか確認
  ssh-add -l
• GitHubとの接続テスト
  ssh -T git@github.com
• プッシュ
  git push -u origin main

[Rookie Dev]

以下の通りで、順調にいけば30分くらいで導入可能です！

• インストール

  # 1. Docker DesktopのWSL統合を無効化（GUI操作）
  # 2. 必要パッケージ確認（既にインストール済み）
  sudo apt-get update
  sudo apt-get install ca-certificates curl gnupg lsb-release
  
  # 3. Docker公式GPGキー追加
  sudo mkdir -m 0755 -p /etc/apt/keyrings
  curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
  
  # 4. Dockerリポジトリ追加
  echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
  
  # 5. Dockerインストール（次のステップ）
  sudo apt-get update
  sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

• ユーザーをdockerグループに追加

  # ユーザーをdockerグループに追加
  # これにより sudo なしで docker コマンドを実行可能になる
  # $USER は現在のユーザー名(wida)を表す環境変数
  sudo usermod -aG docker $USER
  
  # Dockerサービス（デーモン）を開始
  # systemctl は systemd でサービスを管理するコマンド
  # docker デーモンがバックグラウンドで動作開始
  sudo systemctl start docker
  
  # Dockerのバージョン確認
  # インストールが正常に完了し、dockerコマンドが使えることを確認
  docker --version

• 起動について

  # WSL2を再起動するたびに以下が必要 
  sudo systemctl start docker

  手動起動のまま使ってみて、面倒に感じたら後で自動起動に変更 を検討したらいいかと思います！

[Rookie Dev]

WebページのURL変更でほかにすべきこととしては以下の通りです！

• 内部リンクを更新
  こちら対応しなくても、.htaccessでリダイレクトによってリンク切れせず、
  ページは表示されます。
  しかし「古いページ → リダイレクト → 新しいページ」という2段階の処理が発生し、
  わずかですが読み込み時間が増加します、、
  また.htaccessファイルに問題が生じた場合に、内部リンクが一斉に切れてしまうリスクもあります
  主要なナビゲーション（メニューやフッター）だけでも更新しておくと安心です。
• Googleサーチコンソールでサイトマップ・インデックス登録

  

  基本的に検索エンジンの認識を「早める」ための手段なので、
  301リダイレクトが正しく設定されていれば、必須ではないです

  しばらく経って検索結果に表示されなければ必要に応じて対応を検討すれば十分かもしれません

[Rookie Dev]

オプションについて補足します！

• R=301は
  HTTPステータスコード「301（恒久的な移動）」を返します。
  なお、このオプションがないとリダイレクトしても、
  ブラウザのURLが /old-urlのままでとなります。

  そのため、このオプションを設定し/new-urlを外部的に表示することで、
  検索エンジンに正しく認識されます！
  

• Lオプションは「このルールを適用したら、他のルールは見ないで処理を終了してね」という指示です。
  これがないと予期しない連鎖リダイレクトが発生する可能性があります。
  無難につけておくのが一般的です。

[Rookie Dev]

Apacheが使用されている前提の話で進めます！

リダイレクトの書き方

RewriteEngine On
RewriteRule ^old-url$ /new-url [R=301,L]

内容としては

• RewriteEngine Onで
  Apache のmod_rewriteモジュールを有効化して、
  URL書き換え機能が動作するように設定
• RewriteRule [マッチパターン] [リダイレクト先] [オプション]のように記述

[投稿者]

投稿