ApprenticeShip10thTeamProject　　ログイン画面実装編

Posted at 2026-01-26

📅 note公開日：2025-09-22 10:20
🔁 この記事はnoteで公開していた内容をQiitaへ移行・再掲したものです。（必要に応じて加筆修正しています）

ファイルlogin.phpをとりあえず、html,cssで見た目だけ作成した後、以下の機能を実装したく四苦八苦した記録を残します。
最後に完成した画面を載せています。

①実際にメールアドレスとパスワードを入力できる画面にしたい。
②メールアドレスとパスワードを入力後、ログインボタンを押すことでそれらを照合。
③照合の結果、合っていればログイン成功、間違っていれば「メールアドレスまたはパスワードが間違えています」の表示。

これらを実装するために
何をなんのためにどうすればいいか整理

①ルータを「login.php」に向ける。
理由：サーバーで照合するため
場所：public/index.php
＜以上を踏まえ、前提条件を確認する＞

②フォームでPOST→PHPが受け取って照合
理由：入力をサーバーに渡すため
場所：resources/views/set-login/login.php

③htmlを変更
理由：入力ができる形に変更するため
場所：resources/views/set-login/login.php

①ルータを「login.php」に向ける。

ルータ(rooting)とは？

リクエスト(/や?page=loginなど）を見て、どのPHPファイルを実行するか決める係のこと。
今回のファイル内でルータの役割を果たしているのは
public/index.phpのところです。

ルータを「login.php」に向ける理由

1,照合はサーバー側の仕事＝動的。login.htmlは「表示専用」＝静的であり、ロジックが動かない。
2,login.phpはPOSTを受け取り→メール/パスワードを照合→セッション保存→リダイレクトまで実装可能。＝動的
3,ルータ(index.php)がloginを受け取った時にset-login/login.phpを読み込む様にしておくことで、/?page=loginにアクセスした時にサーバー側のログイン処理が動く。

.html＝静的ファイル、.php=動的ファイル

.htmlはただの静的ファイル。サーバーは中身をそのまま配るだけで、コードは実行されない。
.phpは動的ファイル。サーバー(Apache/Nginx)が「これはphpだ！」と判断してPHPエンジン(php-fpmなど)に渡して実行する。
つまり、拡張子を.phpにすることで実行対象になる権利を得ることができる。

MVCとの関係性（このプロジェクトの立ち位置）

M（モデル）：まだDBは未実装
V（ビュー）：resources/views/…
C（コントローラー）：今はpublic/index.phpがフロントコントローラー兼ルータとしてpageの値を見て「どのビュー/処理を呼ぶか」を決めている。

＜以上を踏まえ、前提条件を確認する。＞

１、Apache/Nginxサーバーを使用する。
理由：動的ファイル.phpを読み込ませるため。
方法：Dockerのphp:8.x-apacheイメージを使用する。

２、MVCに対応するファイルを認識する。
M：未実装
V：resources/views/…
C：public/index.php　　[ルーターとコントローラー兼任]

public/index.phpの内容

// ① どのページかを読み取る（リクエスト解析）
$page = $_GET['page'] ?? 'start';

// ② そのページに対応する実ファイルを決める（ルート解決）
$viewsPath = '/var/www/resources/views/';
switch ($page) {
    case 'login':
        $file = $viewsPath . 'set-login/login.php'; // ← loginへのルート定義
        break;
    case 'start':
        $file = $viewsPath . 'start.html';
        break;
    // ...（他のcaseも同様）
    default:
        $file = $viewsPath . 'start.html';
        break;
}

// ③ 実ファイルを読み込む or 404（ディスパッチ）
if (file_exists($file)) {
    require $file;      // ← 実際にそのページの処理を実行
} else {
    echo "<p>❌ ページが見つかりません</p>";
}

②フォームでPOST→PHPが受け取って照合

作業場所：resources/views/set-login/login.php

まずGitで混在するファイルを削除＆Commitする。

public>login.htmlとresources>views>set-login>login.phpが存在しています。
拡張子を.phpに設定し、ApacheにPHPを認識させないとサーバー側で動的な動きを読み込めない＝表示させられない。
ということを知る前に、.htmlで作成してしまっていたlogin.htmlをGitを使用し安全に削除します。

Gitを使用し削除するメリット

１、狙った削除だけを”正確にステージ”できる
・git rm path/to/fileは、そのファイルの削除だけをインデックスに反映。
・うっかりgit add -Aで他の変更まで一緒に載せる事故を防げる。

２、履歴に”削除”という変更が明確に残る。

３、巻き戻しが簡単
・Gitの操作だけで安全にリカバリできる。

４、差分がわかりやすい
・git statusやgit diff --stagedに「D file」と表示され、レビュー観点が明確。

削除手順

# 削除
git rm resources/views/set-login/login.html

# 本当に削除だけ載っているか確認
git status
git diff --staged

# コミット & プッシュ
git commit -m "Remove legacy login.html (now using login.php)"
git push

次に「フォームでPOST→PHPが受け取って照合」を実現させるコードを書く
作業中のlogin.php内

タグ下に以下のコードを入れます。

<form method="post" action="/index.php?page=signin_verify" id="login-form" novalidate><!--PHPでは $_POST[...]で受け取る-->

form

→フォーム全体を囲むタグ。ユーザーが入力した内容をサーバーに送信するためのまとまり。

method="post"

→入力データをHTTP POSTメソッドで送信。

action="/index.php?page=signin_verify"

→送信先の処理を指定。
index.phpが呼ばれ、URLパラメータpage=signin_verifyに応じた処理が実行される

id="login-form"

→このフォームを一意に識別する名前。JSやCSSからフォームを操作する時に使用。
例えば、document.getElementById("login-form)でアクセス。

novalidate

→ブラウザのHTML５フォームバリデーション（必須チェックやメール形式チェックなど）を無効化。

因みにindex.php内のsignin_verifyはこちら。
これはPHP組が書いてくれてます。

case 'signin_verify':
  if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    (new signinController())->authenticate();
    exit;
  }
  header('Location: /index.php?page=login');//POST以外でアクセスされた場合はloginに戻す
  exit;

③htmlを変更

変更後（変更前を消してしまいました。すみません）

<ul class="menu">
  <li class="login-field">
    <label class="login-label" for="email">メールアドレス</label>
    <input id="email" class="login-input card-input" type="email" name="email" placeholder="hello@example.com" required />
  </li>
  <li class="login-field">
    <label class="login-label" for="password">パスワード</label>
    <input id="password" class="login-input card-input" type="password" name="password" placeholder="8文字以上" required />
  </li>
  <li class="login_actions">
    <button type="submit" class="card">ログイン</button>
  </li>
</ul>

input タグを作成し、入力ができる様に変更しました。
以下、解説

「明示的関連付け（label-inputペア）」

この書き方は「明示的関連付け（label-inputペア）」と呼ばれています。
とを一致させて明示的に関連付けをすることで以下のメリットがあります。
・ラベルをクリックすると対応する入力にフォーカスする
・アクセシビリティに対応、音声操作ソフトも指定可能。
・とを離して配置しても関連付けを維持できる。

あとは、実務の鉄則でとはセットで書くものなんだそうで。。。

以下の部分を抜き出して内訳を見ていきます

<label class="login-label" for="email">メールアドレス</label>
<input id="email" class="login-input card-input" type="email" name="email" placeholder="hello@example.com" required />

タグの中に
css用のclass="login-label"
明示的関連付け用のfor="email"

タグの中に
明示的関連付け用のid="email"
css用のclass="login-input card-input"
ユーザー入力サポートのtype="email"
サーバーPHPの$POST['email']へ渡すためのname="email"
入力例のplaceholder="hello@example.com"
html標準の必須チェックrequired

この編集で出来上がった画面が以下です。

ログインボタン大きすぎたのでちいさくしました。

感想

も＆も今回のチーム開発でどんどん使えそうなので、たくさん応用させていきたいと思いました。あとは、PHPのことは知識が乏しいですが、POST送信の仕組みだけでも理解しておかないと、自分の画面が正確に繋がっているのか？動いているのか？確認したかったので、学習してよかったです。

Conclusion

今回は、ログイン画面を「表示だけの静的HTML」から「POSTで送ってサーバー側で照合できる構造」にするために、ルーティングをlogin.phpへ向けることと、フォーム送信（POST）を成立させることを整理しながら進めました。
今後はこの流れをベースに、エラーメッセージ表示やセッション周りの確認も含めて、画面と処理のつながりをさらに理解していきたいです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

ApprenticeShip10thTeamProject ログイン画面実装編