【SQL】【WordPress】SQL文を学んだので以前躓いたWordPressのエラーの原因を確認してみた

# はじめに
初めてQiitaを執筆します。Nodaです。

早くも新卒2か月目になりました。
怒涛の技術研修も折り返し地点を過ぎ、部署配属の話が最近の私のトレンドになりつつあります。

そんな中で執筆する今回の記事は、技術研修の折り返し地点を過ぎたということで一度振り返り、アウトプットすることを目的としたものになっています。

内容としては研修中に、AWSでWordPressを立ち上げたときにうまくいかなかった原因を最近学んだSQLで解決していこうというものになります。

# WordPress構築中のエラー

AWSのEC2を用いてWordPressを立ち上げましたが、その手順は簡単に言うと以下の通りになっています。

  -  EC2でLinuxサーバーを立ち上げる
  -  WordPress用のデータベースを作成
  -  WordPressをインストール

ここまでは順調に進めることができていました。しかし、トラブルはこの後に置きました。

### WordPressの管理画面に入れない・・・

![スクリーンショット (58).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4087277/5c3b6cf3-38a7-458a-b5de-2b1afcde9300.png)

WordPressのセットアップを完了した直後に、Elastic IPをEC2インスタンスに関連づけたところ、突然WordPressの管理画面が開かなくなりました(WordPressのサイト自体は開きます)。
## 原因の詳細
Elastic IPを設定したことで、インスタンスの**グローバルIPアドレスが変更された**のが原因でした。
つまり、Elastic IPを割り当てる前にWordPressをインストールしてしまったことで、WordPressのデータベースには、古いIPアドレスが登録されたままになっていたのです。
その状態でブラウザからElastic IPににアクセスしても、WordPress側の設定と一致しないため、ページが正しく表示されなくなっていました。

SQL文の練習も兼ねてWordPressのデータベースを実際に操作しながらデータベースを直接書き換え、エラーを解決したいと思います。

実際に行う際は**バックアップ**をとることを忘れないでください。

# WordPressのデータベースを確認

データベースはMariaDBを利用しています。
まずは、WordPressのデータベースにあるテーブル一覧を見ていきましょう。
```SQL: MariaDB
use wordpress; 
show tables;
+-----------------------+
| Tables_in_wordpress   |
+-----------------------+
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_termmeta           |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
```
沢山ありますね、
具体的なテーブルの中身は以下のサイトに記載されていたので、興味がある方は見てみてください。

https://wpmake.jp/contents/security/database/

# サイトのURLの確認

``` SQL:MariaDB
 show columns from wp_options;
 +--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI |         |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   | MUL | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+
select option_name from wp_options where option_name like '%url%';
/*各種設定[wp_options]から設定の名前[option_name]の一部が「url」の設定を照会する*/
+-----------------+
| option_name     |
+-----------------+
| mailserver_url  |
| siteurl         |
| upload_url_path |
+-----------------+
 select * from wp_options where option_name = 'siteurl';
 /*サイトurlを照会する*/
 +-----------+-------------+-----------------------+----------+
| option_id | option_name | option_value          | autoload |
+-----------+-------------+-----------------------+----------+
|         2 | siteurl     | http://54.238.***.*** | on       |
+-----------+-------------+-----------------------+----------+
```
ここで、現在のElastic IPを確認する。

![スクリーンショット (57).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4087277/6862f22e-37fb-4c8c-b83c-ab4a9eb1d172.png)

WorePressはインストール時にデータベース(wp_optionsテーブル)にサイトURLとしてその時点のIPアドレス(**54.238.**)がデーターベースに登録されていました。
しかし、その後Elastic IP(**54.250.**)が割り当てたため、アクセスに使用するURLとWordPressの内部に保存されているURLが一致しなくなってしまいました。
このURLの不一致によりWordPressが正しく表示されなくなりました。

## サイトURLの修正

では、WorPressのサイトURLをElastic IPの方に書き換えてみましょう。
```SQL:MariaDB
 update wp_options set option_value='http://54.250.***.***' where option_name='siteurl';
 /*siteurlをElastic IPに書き換える*/
 select * from wp_options where option_name = 'siteurl';
+-----------+-------------+---------------------+----------+
| option_id | option_name | option_value        | autoload |
+-----------+-------------+---------------------+----------+
|         2 | siteurl     | http://54.250.***.*** | on       |
+-----------+-------------+---------------------+----------+
```
これでWordPressはElastic IPの方でも管理画面が開けるようになりました。

![スクリーンショット (60).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4087277/ac93da3f-1e9b-4b43-8c17-d678d0a3fb02.png)

# 余談:全件上書きして壊した話
実は一度、コマンドのミスでデータベースとWordPressを削除する羽目になりました。
原因は、サイトURLを変更するために実行したSQLの間違いです。正しくは以下のようにWHERE句で指定するべきでした。
```SQL:MariaDB
 update wp_options set option_value='http://54.250.***.***' where option_name='siteurl';
```
しかし、私はWHEREをつけずに以下のようなコマンドを実行してしまいました。
```SQL:MariaDB
 update wp_options set option_value='http://54.250.***.***' ;
```
この結果、wp_optionsテーブル内のすべてのoption_valueがURLで上書きされてしまい、管理画面はもちろんのことサイト本体も表示されなくなりました。

**UPDATE文には必ずWHERE句を!!**


# おわりに

今回の記事を執筆することで、AWSやSQLの知識を実際に手を動かしてアウトプットするいい機会になりました。
操作ミスで一時はかなりヒヤッとしましたが、逆にこうしたトラブルを経験できたことが大きな学びになったと感じています。

この記事が、同じような環境でハマっている方の助けになれば幸いです。
ご覧いただきありがとうございました。

# 参考にしたサイト

https://qiita.com/umaaaaa/items/95db02130d79f30274b7