#!/bin/bash


# wp-cliインストールスクリプト

set -euo pipefail

WP_CLI_BIN_PATH="/usr/local/bin/wp" # wp-cli実行ファイルのパス

# wp-cliが既に存在するか確認し、存在しなければダウンロード・配置

if ! command -v wp &>/dev/null; then
    echo "wp-cliをダウンロードしています..."
    curl -o /tmp/wp-cli.phar https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

    if [[ ! -f /tmp/wp-cli.phar ]]; then
        echo "エラー: wp-cli.pharのダウンロードに失敗しました。" >&2
        exit 1
    fi

    chmod +x /tmp/wp-cli.phar
    sudo mv /tmp/wp-cli.phar "$WP_CLI_BIN_PATH"
    echo "wp-cliが $WP_CLI_BIN_PATH にインストールされました。"
else
    echo "wp-cliは既にインストールされています。"
fi

# シェルのPATHにwp-cliのパスが含まれているか確認

if ! echo "$PATH" | grep -q "$(dirname "$WP_CLI_BIN_PATH")"; then
    echo "警告: wp-cliのパス ($(dirname "$WP_CLI_BIN_PATH")) がPATHに含まれていません。"
    echo "手動で追加するか、フルパスで実行してください。"
fi

# インストール確認

wp --info

#!/bin/bash


# WordPressデータベースバックアップ＆最適化スクリプト

set -euo pipefail

# --- 変数定義 ---

WP_PATH="/var/www/html/wordpress" # WordPressのルートディレクトリ
BACKUP_DIR="/var/backups/wordpress_db"
DB_USER="wp_user"
DB_PASS="your_db_password" # 環境変数やシークレット管理ツールで扱うのがより安全

# --- 一時ディレクトリの設定とクリーンアップ ---


# mktemp -dは一時ディレクトリを作成し、そのパスを出力する

TMP_DIR=$(mktemp -d -t wp-db-XXXXXXXX)

# trapでスクリプト終了時に一時ディレクトリを削除

trap 'echo "一時ディレクトリ ${TMP_DIR} を削除しています..."; rm -rf "${TMP_DIR}"' EXIT

# --- 作業ディレクトリへの移動と権限確認 ---

if [[ ! -d "$WP_PATH" ]]; then
    echo "エラー: WordPressディレクトリ $WP_PATH が見つかりません。" >&2
    exit 1
fi
cd "$WP_PATH" || { echo "エラー: WordPressディレクトリに移動できませんでした。" >&2; exit 1; }

# WordPressのファイルオーナーと実行ユーザーが異なる場合、sudo -uで実行


# 例: Webサーバーユーザー (www-data) でwp-cliを実行


# sudo -u www-data wp ...


# または、スクリプト実行ユーザーに適切な権限を付与する。


# ここではスクリプト実行ユーザーがwp-cliを実行できる前提。

# --- バックアップディレクトリの作成 ---

mkdir -p "$BACKUP_DIR"

# --- データベースのバックアップ ---

echo "WordPressデータベースをバックアップしています..."
BACKUP_FILE="${BACKUP_DIR}/wordpress_db_$(date +%Y%m%d_%H%M%S).sql"

# wp db export コマンドは、デフォルトで.sqlファイルを標準出力に出力しない。


# 直接ファイルに書き込むオプションも持つが、一時ファイル経由も安全。

if wp db export "${TMP_DIR}/current_db.sql" --user="$DB_USER" --pass="$DB_PASS" --path="$WP_PATH"; then
    mv "${TMP_DIR}/current_db.sql" "$BACKUP_FILE"
    echo "データベースバックアップが $BACKUP_FILE に保存されました。"
else
    echo "エラー: データベースのバックアップに失敗しました。" >&2
    exit 1
fi

# --- データベースの最適化とクリーンアップ ---

echo "WordPressデータベースを最適化し、不要なリビジョンをクリーンアップしています..."

# 投稿リビジョンを最新の3つ以外削除


# dry-runで確認後、--yesで実行

wp post delete $(wp post list --post_type='revision' --format=ids --allow-root | head -n -3) --force --path="$WP_PATH" --yes

# wp post list --post_type='revision' --format=ids --path="$WP_PATH" | xargs -r wp post delete --force --path="$WP_PATH" --yes # こちらの方がより安全


# 上記コマンドはpost_type='revision'の投稿をすべて取得し、そのうち最後の3つを残して削除する。


# 特定のpost_idを削除するのではなく、リビジョンを削除する場合は `wp revisions delete` を使用するほうが正確。


# 例: wp revisions clean --keep=3 --path="$WP_PATH"


# 今回は一般的なクリーンアップとして wp post delete で代替


# もしくは wp option update "blog_public" 0 でサイトを一時的に非公開にするなども検討

# データベースの最適化

if wp db optimize --path="$WP_PATH"; then
    echo "データベースの最適化が完了しました。"
else
    echo "警告: データベースの最適化中に問題が発生した可能性があります。" >&2
fi

echo "WordPressデータベースの管理スクリプトが正常に完了しました。"

#!/bin/bash


# WordPressプラグインの更新と通知スクリプト

set -euo pipefail

# --- 変数定義 ---

WP_PATH="/var/www/html/wordpress"
WEBHOOK_URL="https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX" # 通知先Webhook URL
SITE_URL="https://your-wordpress-site.com"

# --- 作業ディレクトリへの移動 ---

cd "$WP_PATH" || { echo "エラー: WordPressディレクトリに移動できませんでした。" >&2; exit 1; }

# --- プラグインの更新チェックと更新 ---

echo "利用可能なプラグインの更新を確認しています..."

# wp plugin update --all は、更新があるプラグインのみを更新するため冪等


# --dry-run でまず確認することもできる

UPDATE_OUTPUT=$(wp plugin update --all --format=json --allow-root)

# --allow-root はDocker環境などで必要になることがあるが、通常運用では非推奨。


# 特定のユーザー (例: www-data) で実行するべき。 sudo -u www-data wp plugin update ...

UPDATED_PLUGINS=$(echo "$UPDATE_OUTPUT" | jq -r '.[] | select(.update_status == "Success") | .name')

if [[ -z "$UPDATED_PLUGINS" ]]; then
    MESSAGE="WordPressのプラグインに利用可能な更新はありませんでした。"
    echo "$MESSAGE"
else
    MESSAGE="WordPressプラグインが更新されました:\n${UPDATED_PLUGINS}"
    echo -e "$MESSAGE"
fi

# --- サイトの健全性チェックと通知 (curl) ---

echo "サイトの可用性をチェックしています..."

# curlのオプション:


# -sS: Silent but show errors


# --retry 5: 5回までリトライ


# --retry-delay 3: リトライ間の待機時間 (秒)


# --retry-connrefused: 接続拒否でもリトライ


# --max-time 10: 最大10秒でタイムアウト


# --fail-early: 最初の失敗ですぐに終了 (リトライと組み合わせると少し挙動が変わる)


# --output /dev/null: 出力を破棄


# --resolve: DNSルックアップをオーバーライドする (テスト環境などで便利)

if curl -sS --retry 5 --retry-delay 3 --retry-connrefused --max-time 10 --output /dev/null "$SITE_URL"; then
    STATUS_MESSAGE="WordPressサイト (${SITE_URL}) は正常に動作しています。"
    echo "$STATUS_MESSAGE"
else
    STATUS_MESSAGE="エラー: WordPressサイト (${SITE_URL}) が利用できません。または応答が遅延しています。"
    echo "エラー: $STATUS_MESSAGE" >&2

    # Webhook通知にエラーメッセージを追加

    MESSAGE="${MESSAGE}\n${STATUS_MESSAGE}"
fi

# --- Slack Webhookへの通知 ---

if [[ -n "$WEBHOOK_URL" ]]; then
    echo "Slackに通知を送信しています..."

    # jqでJSONペイロードを生成

    PAYLOAD=$(jq -n --arg msg "$MESSAGE" '{text: $msg}')

    # curlでWebhookにPOST


    # -H "Content-Type: application/json": JSON形式で送信


    # -X POST: POSTメソッド


    # -d @- : 標準入力からデータを読み込む (PAYLOAD変数をechoでパイプ)

    if echo "$PAYLOAD" | curl -sS -H "Content-Type: application/json" -X POST -d @- "$WEBHOOK_URL"; then
        echo "通知が正常に送信されました。"
    else
        echo "エラー: Slackへの通知に失敗しました。" >&2
    fi
fi

echo "WordPressプラグイン更新と通知スクリプトが完了しました。"

[Unit]
Description=WordPress Database Backup and Optimization
Documentation=https://your-documentation-link.com

# After=network-online.target はネットワークが必要な場合に指定


# 今回はDBへのアクセスなので不要な場合も

[Service]
Type=oneshot

# ExecStartPreはExecStartの前に実行されるコマンド


# これにより、スクリプト実行前に必要な環境変数を設定したり、ログディレクトリを作成したりできる


# ExecStart=/bin/bash -c "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /path/to/your/wp-db-backup.sh"


# 環境変数を明示的に設定してスクリプトを実行

ExecStart=/bin/bash -c 'WP_PATH="/var/www/html/wordpress" /usr/local/bin/wp-db-backup.sh'

# 環境変数をスクリプト内で定義済みの場合は、単純にスクリプトパスを指定


# ExecStart=/usr/local/bin/wp-db-backup.sh

# User と Group を指定することで、指定されたユーザー権限でスクリプトが実行される


# これにより、root権限での実行を避け、最小権限の原則を適用できる


# 例: Webサーバーを実行しているユーザーを指定 (例: www-data, nginx)

User=www-data
Group=www-data

# WorkingDirectory はスクリプトが実行されるカレントディレクトリを設定


# スクリプト内で cd している場合は不要だが、設定しておくとより明確

WorkingDirectory=/var/www/html/wordpress

# RestartPolicy は、サービスが失敗した場合の再起動ポリシーを定義


# 今回のType=oneshotの場合、OnFailureが適切

Restart=on-failure
RestartSec=5s # 5秒後に再起動を試みる

# StandardOutputとStandardErrorでログの出力先を制御


# syslogに送信 (journalctlで確認可能)

StandardOutput=syslog
StandardError=syslog

# PrivateTmp=true: サービス専用の一時ディレクトリを作成し、終了時に自動削除

PrivateTmp=true

[Install]
WantedBy=multi-user.target

[Unit]
Description=Run WordPress Database Backup and Optimization daily

[Timer]

# OnCalendarはタイマーを起動する日時を指定


# "daily": 毎日


# "hourly": 毎時


# "*-*-* 02:00:00": 毎日午前2時 (システムが起動していれば)

OnCalendar=*-*-* 02:00:00

# Persistent=true: システム停止中に期限が過ぎた場合、起動後にすぐに実行される


# (OnCalendarで指定された最後の実行時刻を記憶)

Persistent=true

# AccuracySec=1h: 起動時刻の精度を1時間単位にする（リソース節約）


# 厳密な時刻が必要な場合はコメントアウトするか、より短い時間を設定

AccuracySec=1h

[Install]
WantedBy=timers.target