Day17 Topページとその他修正

#トップページ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/ae55195b-32d7-db30-5f22-d23f9387cfe4.png)
トップページは背景画像と新規登録・ログインフォームしかなかったため、サービスやコンセプトの説明ページを付け足した。

#その他修正
##マイグレーションファイルのエラー
本番環境のみ、エラーが出てしまうマイグレーションファイルがあった。String型からint型に変更するマイグレーションファイルだったが、Postgresだと下記のようにint型であると明示しなければエラーになるらしい。
**Before**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/fbb991b5-eac1-9c6b-aea2-30f4d1225532.png)
**After**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/c7d6a75f-7dfb-96d1-784d-affca1499ab2.png)
またこのエラーのせいでrails db:seedsが本番環境ではできなかったがそれも問題なくできるようになり、本番環境でサンプルユーザが使えるようになった。

##存在しない画像の拡大表示（コメント）のエラー
画像の拡大表示は、/image/:idというURLだが、:idに画像が存在しないIDを入れられてしまうとエラーがでてしまっていた。画像のIDとは、コメントテーブルのレコードのIDのことである。コメントのレコードにコラムとしてimageがある。
拡大表示のコントローラでは、存在チェックがされておらず、変数.image_urlで出力しようとしてなにもないから出てしまっているエラーだったので下記のように修正した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/3abae531-aca4-22eb-7429-c9f10f6bc323.png)
これでコメントがありかつ、それに画像がある時のみ拡大表示のビューがよばれ、そうでない時はエラーは出ずに、プロフィールページにリダイレクトするようにした。
##ユーザー一覧で存在しないページが表示される問題
ユーザー一覧のページネートで、存在しないはずのページ数まで表示されてしまう。
これは非表示ユーザ分のページが通常ユーザの一覧画面に表示されてしまっているということだった。コントローラ側では非表示ユーザのみが入っている変数を用意していたので、なぜかわからなかったが、ページネートの定義の部分が間違っていた。
**コントローラ**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/9755b6f8-eefb-b985-f775-1902ea325f49.png)
@usersに公開ユーザがすべて入っている。
**ビュー**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/0621e2e8-8684-c796-c15a-19b8eb5b90bc.png)
ここで本来であれば@usersでなければならないのに、非表示ユーザも含まれる変数をページネートの対象？（このwill pagenateの詳細な挙動については調べる必要あり）にしていたため、非表示ユーザ文のページが含まれていた。なお非表示ユーザの名前等が表示されなかったのは、表示のeach文ではちゃんと@usersで正しい対象にしていたからだった。
下のように修正して、問題は解決した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/56729ced-30ee-a902-ab3c-179bb61943c4.png)
##文字が要素を突き抜けてしまう問題
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/efd689a5-9124-384f-ab89-6ef2129b7d36.png)
このように日本語など以外のテキストを連続で入力すると、通常では改行しないというルールのため、そのまま要素を突き抜けてしまう。そこで、その要素に  word-wrap: break-word;とどんな文字でも改行するというルールを足してやると、解決する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/7c17b1cb-773c-0be7-6819-d46b1fbd16c3.png)
※この解決方法だと単語の途中でも問答無用で区切られてしまうので、入力されるのが英語であるときなどは推奨されない。
https://qiita.com/gcyata/items/353658a7bdc1e7395337
#存在しないコメントを削除した時のエラー
コメント削除に、存在チェックが入っていなかったために存在しないIDからコメントを探す段階でエラーがでてしまっていた。下記のように、correct_userのBefore_actionに、コメントが存在している場合としていない場合の処理を追加した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/af970138-d23c-e330-eb73-7dc04fb8ef40.png)
→画像ではただflashがでるだけで、リダイレクトがないためフラッシュが出たのちにアクションが実行されてしまっていた。リダイレクトを追加して修正した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/9b876521-cfc5-58b9-0509-0372510c3f2f.png)

これで例えば複数タブで開いて、一方でコメントを削除した後に別タブで削除が行われても、エラー画面は表示されずに、フラッシュが表示される。
#存在しないユーザを削除した時のエラー
これも上のコメントと同じようなエラーで、存在チェックがされていないために発生していたため、こちらではBefore_actionのexistがそのまま使えそうだったのでそれで対応した。
**destroyメソッド**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/14bf9ff6-29ba-1b84-8718-56b84004c88e.png)
>
destroyメソッドでは整合性を保つために、もし削除対象のユーザがいいねをしていた、もしくはされていた場合にそのいいねデータも削除されるようにしてある（Likesテーブルは単独のテーブルで、Usersテーブルに対して外部キーなどをもっておらず、userが削除された時にどうじに削除されるよう定義できないため）が、いいねデータは存在チェックがされていないのにエラーがでない。コンソールで見ても空の配列がでるだけでエラーは出ない。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/c8b9823e-a7fb-9899-022d-ef54866b8415.png)
一方でUserの場合は、存在しないIDをもとに探す段階で下記のようにエラーが出る。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/b6d00804-e31b-a608-41a3-dec7dc4da8eb.png)
これはwhereで抽出すると、なにもなければ箱だけ用意されて、箱がdestroyされるという動きになり、Findだとオブジェクトすらないからエラーが出るのだろうか。

**Before_action**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/565105/fe0401d5-0fb8-2517-ca7d-377ac9ddd2bf.png)
このようにすることで、複数タブで同一ユーザに削除が行われてもエラーがでないようになった。