swichやwhile文で使うべきbreakがif文などにあるとこのエラーが出ます。PHP5系まではそのまま通ってしまいます。

PHPExcelはこのサイト（phpexcel.codeplex.com）での更新は止まっていますが、github（github.com/PHPOffice/PHPExcel）では修正されています。バージョンは1.8で同じですが、上記のエラーは出なくなりました。2017/1/9時点の最新版では、PHPの対応バージョンは5.2以上となっています。

結論から書くと、PHPのバージョンを5.4から5.6に変更していたことと、それに対応していないプラグインがあったことが原因です。ログインができないだけで、ページは一応表示できます。

環境は以下の通りです。

Coreserver(CORE-A)
Wordpress 4.5.3 （4.4.4でも同様）

CoreserverはドメインごとにPHPのバーションがコントロールパネルで変更できるので、一旦はログイン可能なバージョンに変更します。今回は5.5と5.6でログインできませんでした。また、5.4と7.0ではログインできました。

必要なバージョンアップを行い、一度バージョンを変えて試してみます。それでもログイン画面が表示されない場合は、プラグインを全てOFFにすると、おそらくログインできるはずです。

あとは、プラグインの変更や更新をした後、PHPのバージョンを戻してみて試します。

今回原因となったプラグインは、ZenCacheでした。プラグインの名称が変わり（Comet Cache）、ZenCacheそのものは更新が停止しています。

‘dir1/dir2/dir3’のような深いディレクトリを一度で作成する場合はmkdirに第3引数にtrueをつけて使用します。

$dirName = 'dir1/dir2/dir3';
$defaultUmaskNum = umask();
umask(0);
mkdir($dirName,0755,true);
umask($defaultUmaskNum);

mkdirの第2引数はパーミッションの設定です。数値で指定します。’0755’などのように文字列で指定するとエラーは出なくとも、おかしなパーミッションになることがあります。
また、umaskはデフォルトのパーミッションの設定です。mkdirに第2引数からumaskの値を引いた値が設定されるので今回は便宜的に0にして、処理後に戻しています。
PHP公式ではパーミッションの設定はumaskを変更するのではなく、chmodが推奨されていますが、作成される全てのディレクトリのパーミッションを同時指定することはできません。

表示したいディレクトリに「.user.ini」を設置します。

display_errors = On
error_reporting = E_ALL & ~E_NOTICE

error_reportingの値は適宜変更して下さい。設置したディレクトリとその下層ディレクトリで有効です。
coreserverのPHPはここ数年で変更がありましたので、過去の対応とは異なることがあります。これからも変化があるかもしれませんので、できれば公式の情報をあたることをオススメします。

比較は緩やかな比較(==)をしています。

左辺のキーと値で比較しています。左辺にあるものが右辺にあれば一致するとみなし、右辺にのみあるキーと値は無視します。
左辺にのみ存在する値は差分として表示します。
過不足無く配列の一致を確認する場合は、面倒ですが、左右入れ替えて実行します。

function diffMultiDemenion($arrrayLeft,$arrayRight){
//左辺の内容が右辺に含まれているか
//同一かどうかは左右入れ替えて確認する

//差が無ければfalse
$diff = false;
if (is_array($arrrayLeft)){
	foreach($arrrayLeft as $key => $item){
		if (is_array($item)){
			//配列なら再帰呼び出し
			$tempDiff = diffMultiDemenion($item,$arrayRight[$key]);
			if ($tempDiff){
				//差が無ければキーを作らない
				$diff[$key] = $tempDiff;
			}
		}else{
			if($item != $arrayRight[$key]){
				//配列[0]に左辺、[1]に右辺の値
				$diff[$key] = array($item,$arrayRight[$key]);
			}
		}
	}
}elseif($arrrayLeft != $arrayRight){
	//配列でなければそのま比較して異なる場合は右辺と左辺を表示
	$diff = array($arrrayLeft,$arrayRight);
}
return($diff);
}

使用例です。

$arrayA['b'] = 1;
$arrayA['c'] = 2;
$arrayA['a']['d'] = 3;
$arrayA['a']['f'] = 4;

$arrayB['b'] = 1;
$arrayB['c'] = 0;
$arrayB['a']['d'] = 3;
$arrayB['a']['f'] = 0;

$diff = diffMultiDemenion($arrayA,$arrayB);
print_r($diff);

その結果です。

Array
(
[c] => Array
	(
	[0] => 2
	[1] => 0
	)
[a] => Array
	(
	[f] => Array
		(
		[0] => 4
		[1] => 0
		)
	)
)

//画面にエラーを表示させない
ini_set(‘display_errors’, 0);
// ログに記録する
ini_set(‘log_errors’, ‘on’);
// ログの保存先
ini_set(‘error_log’, ‘/log/php_error.log’);

通常とは違う場所（ファイル）に分けて保存できます。書き込みができるよう、ディレクトリのパーミッションは適宜変更してください

ご存じの通り、改行コードはUnix系がLF(\n)のみ、DOS系（Windows系）がCR+LF(\r\n)、Mac系がCR(\r)のみとなっています。

PHPでこれらを置換しよう思った場合、改行コードがいずれか一つであることが明確なら良いのですが、なかなかそうはいきません。

置換に使う関数はいくつかありますが、str_replaceとmb_ereg_replaceを比較しました。str_replaceは文字列の単純な置換を、mb_ereg_replaceはマルチバイト対応、正規表現で一致する文字列の置換を行います。

改行の消去と置換では微妙にコードに違いが出ますが、今回は半角スペースに置換しました。

比較したコードは以下の通りです。

//元の文字列:$original

//#1 mb_ereg_replace 一つずつ置換
$str1 = mb_ereg_replace("\r\n","\n",$original); //CR+LFをLFに
$str1 = mb_ereg_replace("\r","\n",$str1); // CRをLFに
$str1 = mb_ereg_replace("\n"," ",$str1);//LFを半角スペースに

//#2 mb_ereg_replace 3通りを置換
$str2 = mb_ereg_replace("\r\n|\n|\r"," ",$original);

//#3 str_replace 一つずつ置換
$str3 = str_replace("\r\n","\n",$original); //CR+LFをLFに
$str3 = str_replace("\r","\n",$str3); // CRをLFに
$str3 = str_replace("\n"," ",$str3);//LFを半角スペースに

//#4 str_replace 3通りを置換
$str4 = str_replace(array("\r\n","\n","\r")," ",$original);

同じ文章（約40KB）を1000回ほど置き換え、時間を計測しました。文字列の置換結果はいずれも同じですが、かかった時間はかなり違いました。
#1 : 0.92秒
#2 : 0.30秒
#3 : 0.11秒
#4 : 0.09秒

やはりstr_replaceは高速です。正規表現は汎用性も高く便利な機能ですが、時間はどうしてもかかってしまいます。mb_str_replaceのような関数が標準であると便利だと思います。

WordPressなどでは、、投稿や記事の中でPHPを実行するプラグインや拡張機能では通常evalコマンドでPHPが実行されます。

そんななか、JoomlaのJumiというエクステンションではPHPはまさにその記事のその部分でPHPが記述されるようで、Joomlaで使用されているセッションや変数をそのまま使用することができます。当然危険性も増えますが、便利な点も多くあります。

ちなみにevalはPHPのマニュアルで次のように警告されています。

eval() は非常に危険な言語構造です。 というのも、任意の PHP コードを実行できてしまうからです。 これを使うことはおすすめしません。

記事の編集の権限が不特定な場合は、このような機能は無効にすべきだと思いますので、くれぐれもご注意下さい。

標準で用意されているフォント以外を使う方法はWebで検索すると多数紹介されていますが、TCPDFの最新版（今回は6.2.3）でエラーが出てしまったので修正点を紹介します。

ライブラリのインストール方法等は割愛します。

以前の方法はTCPDFクラスからaddTTFfontを設定していましたが、新しいバージョンでは TCPDF_FONTS からaddTTFfontを呼ぶ必要があります。そのま実行するとCall to undefined method TCPDF::addTTFfont()とエラーが出てしまいます。

以前の方法
$pdf = new TCPDF("L", "mm", "A4", true, "UTF-8" );
$font = $pdf->addTTFfont('フォント名.ttf');
$pdf->SetFont($font , '', 32,'',true);
$pdf->Text(0, 0, "PDFに表示する文字" );


新しい設方方法
$pdf = new TCPDF("L", "mm", "A4", true, "UTF-8" );
$font = new TCPDF_FONTS();
$fontX = $font->addTTFfont('フォント名.ttf');
$pdf->SetFont($fontX , '', 32,'',true);
$pdf->Text(0, 0, "PDFに表示する文字" );


フォントを複数使う場合もフォントごとに新しいインスタンスを作ります。

shift-jisなら全角は2バイトと決め打ちしても良さそうですが、主流のUTF-8では全角は3バイト（一部2バイト）で、見た目とバイト数は一致しません。

mb_strwidthは全角文字（マルチバイト文字）は2、いわゆる半角英数は1で”文字列の幅”を返します。また、mb_strimwidthは同様に文字列の幅で切り取りを行います。第4引数に「・・・」などとすると、切り取った文字列のあとに「・・・」を足してくれます。（それくらいはPHPでもすぐにできるので、無くてもこまらない機能ですが。）

長さに関係なくレイアウトを維持したい場合などに有用でWeb向きの関数です。mb_strwidthで文字列の長さを確認して、mb_strimwidthで切り取るという感じで使うことが予想されます。ちなみにsubstrのように、後ろから何文字切り抜くというような使い方はできません。そのときはmb_substrを使うべきだと思います。

なお、エンコードの指定は確実に行いましょう。

リファレンス「mb_strwidth」
リファレンス「mb_strimwidth」