WEBマスターの知恵ブログ

ブログ

  • 【PHP】requireとincludeの違い

    PHPの「require」と「include」等の読み込み構文の違いについての覚書です。

    PHPにおいて、ファイルを読み込む言語構造には、次の4つがあります。

    ・ require
    ・ require_once
    ・ include
    ・ include_once

    上記の4つは、似た動作をしますが、微妙に挙動が異なります。
    結論から言うと、ベターなのは、「require_once」です。

    以下、それぞれ検討していきます。

    まず、これらの言語構造は、2つの観点から区別できます。
    一つ目は、エラー処理の仕方。
    二つ目は、ファイルの再読込の可否。

    ■　エラー処理の仕方について

    require系の二つと、include系の二つは、エラー処理の仕方が異なります。
    例えば、存在しないファイルを指定したとき、次のエラーとなります。

    ・　require系・・・fatal error　（実行が止まる）

    ・　include系・・・warning error　（実行は継続される）

    fatal error は、エラー時点で実行が止まります。これに対して、warning error では、実行が続いてしまいます。

    基本的には、エラーが生じた時点で処理を止めることが、バグの発生を防止します。
    ですから、この観点からいうと、require系の方がファイルの読み込みに適していると言えます。

    ■　ファイルの再読込の可否

    上記4つの構文には、_onceが付くものがあります。付かないものとの違いは、特定のファイルを二度以上読み込めるかということです。

    _onceが付いている構文の場合、同じファイルを二度以上読み込んでも、実際には最初の一度だけ読み込むことができます。

    これに対して、onceが付かない構文の場合には、同じファイルの複数回の読み込みが可能となります。もっとも、同じ関数やクラスを二度以上読み込むと再定義できない旨のfatal errorとなります。

    通常、ファイルの読み込みは一度だけ行えば足りるので、once系の構文が使われる傾向にあります。

    ■　結論

    結果として、requre_once 構文がベターということになります。

    ■　まとめ

    ・ require ・・・・・・・・・ fatal error、複数読込可能（但し、fatal error）
    ・ require_once ・・・ fatal error、複数読込無視
    ・ include ・・・ ・・・・・・warning error、複数読込可能（但し、fatal error）
    ・ include_once ・・・ warning error、複数読込無視

    以上です。

  • 【CORESERVER】サーバーの移動の覚書【XREA】

    この度、利用しているCORESERVERのサーバーが重くなったので、新サーバーに移動しました。

    旧サーバーから、新サーバーへの移動の手順を覚書の意味をこめて記しておきます。（参考は自己責任でお願いします。）

    【サーバー移動の概要】
    （所要時間：約1時間30分。運営サイトの量によります。）

    1.　CORESERVER のアカウントを追加で取得・作成
    2.　データベース、及び、ファイルのバックアップ（旧サーバー）
    3.　データベースの作成（以下、新サーバー）
    4.　ドメイン・ウェブの設定
    5.　ディレクトリ・ファイルをコピー
    6.　データベースの復元・インポート
    7.　サーバー依存情報（DBパスワード等）の書き換え
    8.　CRONの設定
    9.　メールの設定
    10.　サーバー提供サブドメインの設定
    11.　DNSの設定
    12.　CORESERVERの契約を移動

    【個別具体的な手順】

    ■1.　CORESERVER のアカウントを追加で取得・作成

    まず、サーバーの移動をするにあたり、新サーバーのアカウントを取得する必要があります。

    「無料のお試し登録」でよいので、「CORESERVER アカウントを取得・作成」画面において、セレクト・ボックスから希望するサーバーを選択します。

    coreserver1

    この際、希望アカウント名は、旧サーバーと同一のものにしておくのが良いでしょう。なぜなら、旧サーバーのアカウント名の設定を新サーバーでそのまま使うことが出来るからです。

    ちなみに、新サーバーの取得にあたっては、「障害情報」を前もってチェックしておくことが望ましいです。障害を示す赤色の帯が出ないサーバーを選択しましょう。新サーバーが障害気味では、移動の意味がありませんから。

    アカウントを取得・作成すると、新サーバーが数分で利用できるようになります。

    ■2.　旧サーバーのデータベース、及び、ファイルのバックアップ

    新サーバーが準備される時間を利用して、旧サーバーのデータをバックアップしておきます。

    ・　DBのバックアップは、次のどちらか、又は、両方を行います。

    1. 管理画面の「データベース」の画面で、「保存」を行い、dumpファイルを作成

    2. phpMyAdmin等の管理画面から、データベースをエクスポート

    望ましいのは両方を行うことですが、簡単なのは、1のdumpファイルを作成する方法です。

    ・　ディレクトリ・ファイルのバックアップは、次のような方法によります。

    1. 各ディレクトリを「ファイルマネージャー」よりダウンロード

    2. FTPソフトを使ってダウンロード

    簡単なのは、1のファイルマネージャーからダウンロードする方法です。zipファイルとして保存することができます。

    なお、ディレクトリ・ファイルについては、新サーバーから、「サーバー間コピー」という方法を使うことができるので、当該 zipファイルはとりあえず解凍しなくて大丈夫です。

    ■3.　データベースの作成

    バックアップが済んだら、新サーバーの管理画面にアクセスします。

    まず、データベースを利用している場合には、データベースを利用できるようにします。

    ・　PhpMyAdmin / PhpPgAdminをインストール

    coreserver4

    PhpMyAdmin 等のインストールは非常に簡単です。管理画面の「データベース」画面から、「インストール」ボタンを押すだけです。

    ・　MySQLの追加・編集

    次に、旧サーバーと同様に、「MySQLの追加・編集」を行います。旧サーバーと同じユーザー名のデータベースを「作成」していきます。

    coreserver5

    この際、パスワードは、新サーバーのものを使うと良いでしょう。文字コードについては、旧サーバーと同じものにします。

    ■4.　ドメイン・ウェブの設定

    DBの設定が済んだら、管理画面の「ドメイン・ウェブ」より、ドメインの登録をしていきます。

    coreserver6

    ここは、旧サーバーの管理画面のものと同じにすれば良いので、新旧両方の管理画面を見比べながら、コピーにより記入をしていけばよいでしょう。

    ちなみに、ここで、「ドメイン設定」のボタンを押すと、数分後に、public_html以下に当該ドメイン用のディレクトリが自動的に作成されます。

    ■5.　ディレクトリ・ファイルをコピー

    まず、非公開領域である、ルートディレクトリ直下（/）に、ディレクトリ・ファイルをコピーしていきます。次に、公開領域である、public_html以下にコピーします。

    public_html以下には、ドメイン・ウェブの設定により、ディレクトリが自動的に作成されているはずです。（なお、自動的にディレクトリが作成されない場合には、自分で、ディレクトリを作成します。）

    ディレクトリ・ファイルのコピーには、いくつか方法があります。

    1. 管理画面の「サーバー間コピー」を使う方法

    2. FTPソフトでアップロードする方法

    3. バックアップしたzipファイルをアップロードし、コマンドで解凍する方法

    ここでは、一番簡単な、「サーバー間コピー」を使います。
    転送方式は、「ミラー（削除なし）」で良いでしょう。これは、単純なコピーです。

    サーバー間コピーの注意点としては、ディレクトリ単位で実行されること（ファイル単位では不可）、また、ディレクトリが作成されていないとコピーできない等があります。

    ちなみに、CORESERVER以外からのコピーも出来るようですが、パーミッションが変更される場合があるで、その場合にはこれも注意事項です。

    「サーバー間コピー」をルートディレクトリから、一度にまとめてする方法もありますが、phpMyAdmin等のディレクトリまで上書きされてしまうので、個別のディレクトリごとに行うことをオススメします。

    ■6.　データベースの復元・インポート

    先の「サーバー間コピー」の作業において、旧サーバーのデータベースのdumpファイルをコピーして新サーバーにもってくると便利です。つまり、旧サーバーで、任意のディレクトリを作成して、dumpファイルをまとめて入れておき、そのディレクトリを新サーバーにコピーするわけです。

    このコピーしたdumpファイルをルート直下に移動して、「データベース」画面から、個別のデータベースごとに「復元」をすると簡単にDBを戻すことができます。

    なお、個別データベースにおいて、phpMyAdmin等からインポート等して復元することも可能です。

    （注意）
    サーバーにより「復元」の機能が上手く使えない場合があります。ここでつまずいたら、phpMyAdmin等でエクスポート・インポート機能を使う方が効率的に作業できます。

    ■7.　サーバー依存情報（DBパスワード等）の書き換え

    ここまでで、データベース、及び、ファイルがそろったので、パスワード等の書き換えを行います。

    DBを使っているサイトにおいては、DBの設定ファイルがあるはずです。その情報を新サーバーのパスワード等に書き換えます。

    また、WordPressを利用している場合ならば、「wp-config.php」内のパスワード等を書き換えます。

    ちなみに、アカウントを新旧で同一のものにした場合には、DBのユーザー名の書き換えは不要となります。

    ■8.　CRONの設定

    上記作業で、データベース、及び、ファイル等の作業はほぼ終了です。

    次に、CRONの設定をしましょう。（使っていない場合には不要です。）

    といっても、旧サーバーのCRONの管理画面と同様に記入していけばよいだけです。

    CRONに関する、shファイルやphpファイルにもサーバー固有の情報がある場合があるので、ここで確認しておくと良いでしょう。

    ■9.　メールの設定

    サーバーのドメインメール機能を利用している場合には、メールの設定も必要です。

    旧サーバーにおいて、メールのバックアップを行うとともに、新サーバーにおいて、「マイドメインのメール作成」等をすることが必要です。

    テキスト形式のファイルから一括で設定することもできるようなので、利用してみるとよいでしょう。

    ここでは、メールを使っていないので、説明は省略します。

    ■10.　サーバー提供サブドメインの設定

    サーバーが提供するサブドメイン、（bex.jpやgob.jp）を利用している場合には、サブドメインの設定も必要です。

    「CORESERVERアカウントの登録・管理・購入」画面から、旧サーバーのサブドメインの設定画面に入り、当該サブドメインを削除します。

    続いて、新サーバー側で、新たに、当該サブドメインを取得します。

    旧サーバー側で削除してからでないと、新サーバーに移動できないので、削除処理が先になります。

    ■11.　DNSの設定

    ここまでで、サーバー側の設定は、一通り終了しました。

    最後に、ドメイン側で、DNSの設定を行います。

    バリュードメインの管理画面「DNSレコード/URL転送の変更」画面から設定します。

    変更するドメインを選択し、設定画面に入ります。

    coreserver7

    coreserver8

    基本的に、「自動設定」で、新サーバーを選択すれば、DNSが新サーバーに反映されるようになります。

    ここは慣れない作業なので、自動設定にまかせるのがオススメです。
    DNSが反映されるのは、それほど時間はかからず、数分で済むと思います。

    反映されたかどうかは、新サーバー内のファイルを少しいじって「test」など書いて、それがきちんと表示されたかで、判別することができます。

    また、nslookupコマンドを使って、確認することも可能です。なお、windowsも可。

    nslookup example.com

    ■12.　CORESERVERの契約を移動

    DNSの変更が済んだら、最後にCORESERVERの契約を移動します。

    coreserver9

    一応、「無料お試し期間」が数日あるので、その期間内に契約を移動すれば、大丈夫です。

    なお、契約の移動をした場合、旧サーバーの利用はすぐに停止される訳ではなく、無料お試し期間の残日数程度は、利用を続けられるようです。

    ですから、その期間は、旧サーバーのデータを残しておき、新サーバーの利用に問題がなければ、随時、DBやファイル等を削除していけば良いと思います。

    もっとも、気になるデータがなければ、アカウントごと削除しても問題ないかもしれません。あるいは、放置して期限切れにより自動削除されるのを待つのも一つの方法かも。

    ■　反省点

    最後に一点、はまったことがあったので、記しておきます。

    パスワードの変更をファイルに記述する際、ファイルのパーミッションを400に絞っていたため、エディタで書き直したつもりが、変更されていないミスがありました。

    パスワードが新サーバーのものになっていなかったため、WordPressが500エラーになり、焦りましたが、パーミッションを変えてパスワードを記入したら、上手くいくようになりました。

    以上です。

  • 【PHP】サーバーの負荷を定期的にチェックする方法

    サーバーの負荷を定期的に調べて、メールで通知するための方法です。

    まず、定期的にスクリプトを実行するので、CRONを利用します。CRONの使い方は、こちらの過去記事を参照。
    http://webmaster.chielog.com/php/39.html

    サーバーの負荷を調べるには、Linuxのuptimeコマンドを利用します。

    もっとも、ここでは、CRONでshを起動し、そこからPHPスクリプトを実行する方法をとります。

    そのPHPスクリプトですが、次のようになります。

    <?php

//1.uptimeコマンドを実行
$output = `uptime`;

//2.結果を分割
$pieces = explode(":", $output);

//3.宛先・タイトル代入
$to      = 'name@example.com;
$subject = '(server no)-- '.$pieces[3];

//4.送信処理
mail($to, $subject, $output);

//end

    ■１
    上記のLinuxコマンドは、バッククオートで実行していますが、shell_exec()と同様なので、どちらを使っても良いと思います。

    ■ ２
    結果を分割していますが、件名に負荷の値だけを表示したいので、時間の区切り文字で結果を分割して、最後の値だけを、３で付け足しています。メールの中身を見ずに、タイトルだけで、負荷の値を知ることが出来ます。

    ■ ３
    件名には、負荷の値を表示するようにしています。

    ■ ４
    メールの送信処理です、特に日本語は含まれないので、mail関数を使っています。

    PHPスクリプトは以上です。

    後は、このスクリプトをCRONから実行するために、CRONタブの設定をします。上記リンクを参考にどうぞ。

    また、shスクリプトもあわせて設置してください。

    PHPスクリプト、CRONの設定、shスクリプトの設置がすめば、設定したメールアドレス宛に、サーバーの負荷の値が定期的に送信されてきます。

    ちなみに、当該メールの到着時間を見れば、メールサーバーの調子も推測できます。遅延したりした場合には、対処が必要になるでしょう。

    以上です。

  • 【書評】WebデザイナーのためのCakePHPビューコーディング入門

    ■　書評対象：WebデザイナーのためのCakePHPビューコーディング入門

    ■　良い点

    ・　サンプルコードが豊富
    ・　結果画面がきちんと表示されている
    ・　コード箇所と解説が番号で対応している（前半部分）
    ・　ビュー（特にヘルパー）に詳しい（後半部分）

    ■　悪い点

    ・　誤字・脱字が結構、目立つ
    ・　セキュリティの解説が薄い
    ・　後の解説部分が前に来ることがある

    ■　総評

    全体として内容が濃く、満足できるCakePHPの解説本です。

    前半の1章から3章までは、CakePHPの全体像をサンプルアプリの制作を通して基礎から学べます。2章では、簡素化したCRUDシステムを学び、続く3章では、応用的に、「ユーザーからの問い合わせフォーム」と、それを管理するための「管理者用のシステム」を構築します。ログイン認証も学べます。

    この前半部分で、CakePHPのおおよその使い方をマスターできます。

    後半の4章から6章にかけては、「ビュー」にスポットを当てた解説となっています。

    4章では、ビューについて掘り下げ、5章では、ヘルパーを中心に解説されています。最後の6章では、実践的にビューをデザインしていきます。

    5章は、少しリファレンス的な要素になっていて読むのが大変なので、ざっと目を通して、6章のビューデザインをメインに読むことをお勧めします。

    ところで、この本は、前半部分は、滝下氏、後半部分は、原氏が担当していると思われます。そのため、前半と後半で、少し解説の方法が異なるので違和感を感じるかもしれません。共著であり、二分冊と思えば、ある意味お得ですね。

    プログラマー視点では、前半部分が読みやすいですが、デザイナー視点では、後半が読みやすく感じるのかもしれません。

    なお、この本を読むにあたっては、多少のPHPの知識があったほうが良いかも。全くのPHPの初見だと、何をしているのか理解できないと思います。

    ちなみに、WEB開発周りのGitの解説なども付いていてお得です。

  • 【PHP】モジュール版とCGI版の注意点【CORESERVER】

    XREA/CORESERVERでは、PHPをApacheのモジュールとして動かすか、CGIとして動かすかの選択ができます。
    http://www.coreserver.jp/help/index.php/phpcgi/

    よく知られていることに、モジュール版では、セーフモードがOnであり、CGI版では、セーフモードがOffになるというものがあります。

    しかし、これ以外にも、PHPの挙動が異なることがあるので注意が必要です。

    その一つが、内部文字エンコーディングの設定です。

    通常のモジュール版（PHP Version 5.2.5）では、
    mbstring.internal_encoding　の設定は、UTF-8　となっています。

    これに対し、CGI版（PHP Version 5.3.27）では、
    mbstring.internal_encoding　の設定は、no value　となっています。

    CGI版のno value　というのは、サーバーのデフォルト値が使われるのであり、結果として、EUC-JP　が使われていると思われます。ちなみに、ファイルマネージャーのテキストエリアの初期設定は、EUC-JPです。

    このことは、モジュール版からCGI版に切り替えた時に、不具合となって現れる可能性があります。

    たとえば、文字数をmb_strlenでカウントする場合、引数にエンコードを指定していなければ、モジュール版のUTF-8とCGI版のEUC-JPとでは、異なった結果を返します。

    このように、mb_・・・　系の関数の使用で問題になるわけです。

    この対策としては、CGI版で動かすファイルの先頭に次のように設定してやると上手くいきます。

    mb_internal_encoding('UTF-8');

    なお、文字エンコーディングが、サイト全体（アプリ全体）で、統一されていなければ、文字化けの現象をおこす危険もあります。この観点からも、モジュール版とCGI版の間での移行は慎重に行った方がよいと思います。

    以上です。