MODX JAPAN

-----
ご利用のサーバ：CPI　Z2プラン
MODX Evoのバージョン：ver 1.0.5J-r3からver 1.0.6J-r8へのアップグレード済み
PHPのバージョン：PHP 5.2.8
MySQLのバージョン：MySQL5.0.45
ブラウザ：IE9、Firefox12、chrome
-----


MODXの5J-r3から6J-r7へアップグレードをおこなって、MODX Parse Errorにつき
推薦に従い6J-r8bにアップグレードしたが現象変わらずの件、
FTPをご推挙のFileZillaへ変えて、先ほど、まずもともとの5J-r3への「復旧作業」をおこなった。

結果、復旧は成功したように見受けられる。
eFormも正常に表示されているし、投稿画面も非HTML機能は出現した。　何のエラー画面も出ない。


よって、最新版のバージョン6J-r8に再度アップグレードをおこなった。
該当のバージョンでのアップグレード方法で書かれてある通りに。

しかし、全く同じ不具合状態となっている・・・

アップデートしてinstallフォルダも削除し、管理画面にログインすると、
CSSリンク切れ状態、画像リンク切れ状態の表示となっているので、グローバル設定の「更新」リンクをクリック。
すると、CSS切れ、画像切れが直って正常っぽく管理画面は表示。
しかし、やはり「QuickManagerをアップデートしてください。」と出ている。
投稿画面も同じで、非HMTLの投稿はできなくなっており、HTMLだけの投稿画面となっている。

また、ログインしたままでサイトトップページを開くと、MODX Parse Error画面が出る。
ログアウトするとサイトは表示されるも、eFormはやはり表示されず、代わりに
「注意! eFormのバージョン (version: 1.4.2)がインクルードされているファイルのバージョン (version: )と異なります。 同じバージョンのファイルであることを確認してください。」
と出る。

全く不具合の現象は変わっていないように見える。

以下、MODX Parse Errorの内容

------------------------------------------------------------
Undefined index: a

« MODX Parse Error »
MODX encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »
PHP error debug
Error : extract() [function.extract]: First argument should be an array
ErrorType[num] : WARNING[2]
File : /usr/home/mynum0001/html/assets/plugins/qm/qm.inc.php
Line : 39
Source : extract($params);
Basic info
REQUEST_URI : /
Resource : [1]ホーム
Current Plugin : Quick Manager+(OnParseDocument)
Referer :
User Agent : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
IP : xxx.xxx.xxx.xxx
Parser timing
MySQL : 0.0090 s (3 Requests)
PHP : 0.0308 s
Total : 0.0398 s


Backtrace

1 executeParser() index.php on line 135
2 prepareResponse() manager/includes/document.parser.class.inc.php on line 286
3 outputContent() manager/includes/document.parser.class.inc.php on line 405
4 parseDocumentSource() manager/includes/document.parser.class.inc.php on line 436
5 invokeEvent() manager/includes/document.parser.class.inc.php on line 1940
6 evalPlugin() manager/includes/document.parser.class.inc.php on line 3500
7 eval() manager/includes/document.parser.class.inc.php on line 1476
8 Qm() manager/includes/document.parser.class.inc.php(1476) : eval()'d code on line 23
9 extract() assets/plugins/qm/qm.inc.php on line 39
------------------------------------------------------------

modxfan さんが書きました:アップデートしてinstallフォルダも削除し、管理画面にログインすると、
CSSリンク切れ状態、画像リンク切れ状態の表示となっているので、グローバル設定の「更新」リンクをクリック。

ログイン直後に白っぽい管理画面が表示された感じですね。

まずeformの復旧から説明します。
最新版のinstall/assets/snippets/ フォルダにeform.tplというファイルがあるので、これをテキストエディタで開いて中身をそのまま管理画面のeForm編集画面に貼り付けて保存してください。その後、メール送信テストを日本語を混ぜて行なってみてください。

その他、DittoやWayfinderも同じフォルダにファイルがあるので、念のため同じように貼り付けるとよさそうに思います。ファイル名をみればだいたい分かると思いますが、分からなければまた聞いてください。

プラグインもinstall/assets/plugins/ディレクトリに同じようにファイルがあるので、手作業で貼り付けると完了です。

CPIの担当者さんとは今まで何度か個人的にもやりとりしてますので、今回の件は報告を入れてみます。話が進みそうであれば、できるだけ同じ環境でテストしてみます。

●スニペット
おこなうと書かれていたeform.tpl、ditto.tpl、wayfinder.tplは済み。
weblogin.tplとtopicpath.tplは書かれていないのでおこなっていない。


●プラグイン
dashboard2-yourinfo.tpl、dashboard3-online.tpl　は、管理画面のスニペットに存在しないので貼り付けはおこなっていない。
ForgotManagerPassword.tplも、ForgotManagerLoginという違う名称のものがあるだけだったので、同じくおこなっていない。
manager_tpl.tpl、
mgrmgr.tplはバージョンを比較すると同じだったので貼り付けしていない。
qm.tpl、tinymce.tpl　は貼り付けした。


【結果】
スニペットの貼り付けが終わった段階では何も変わりませんでしたが、
プラグインの貼り付けが終わった段階でサイト表示をすると、
全てOKなのか不明ですが、現象の改善が見受けられました。

(1) ダッシュボードで「警告」というタブが出ているが、書かれている通りに
　　　信じて対応して大丈夫でしょうか。
　　　※以下内容転載

------------------------------------------------------------
警告 管理画面テンプレートファイル

assets/templates/manager/ディレクトリの使用は1.0.6J-r8以降は推奨されなくなりましたので、ディレクトリごと削除してください。すでにカスタマイズを加えて使用している場合は、同ディレクトリ内のファイルの拡張子を「.tpl」に変更し、manager/media/style/テーマ名/template/ディレクトリに上書きしてください。

警告 特権ロールでログインしています

特権ロール(Administrator)でログインしています。このロールは、グループ管理機能の制御対象にならない・ファイル管理機能においてmanagerディレクトリなど重要な領域にアクセスできる・全てのプラグインの効力を無効とするセーフモードログイン(ユーザ名の末尾に「:safemode」を付ける)を可能とするなど、通常のコンテンツ管理には向かない特殊な性質を持っているため、常用にはおすすめしません。緊急対応用のアカウントとして利用してください。
------------------------------------------------------------


(2) eFormトラブル有り
eFormが表示されたので、日本語を混ぜて送信テストしたところ、管理者側の自動返信メールにおいて
Subjectが途中で切れています。
※送信者への自動返信メールにはトラブル見受けられない

途中までは正常に出力されているのですが、「リ」というカタカナからうしろが消えており、修繕したいです。


(3) このような、アップデート方法に存在しない「貼り付け作業」がアップデート作業に必要になってしまうのは何故でしょうか？


宜しくお願い致します。

modxfan さんが書きました:(2) eFormトラブル有り
eFormが表示されたので、日本語を混ぜて送信テストしたところ、管理者側の自動返信メールにおいて
Subjectが途中で切れています。
※送信者への自動返信メールにはトラブル見受けられない

途中までは正常に出力されているのですが、「リ」というカタカナからうしろが消えており、修繕したいです。

(3) このような、アップデート方法に存在しない「貼り付け作業」がアップデート作業に必要になってしまうのは何故でしょうか？

上記については、実際にサーバを調べてみないと分からないです。今回のCPIサーバに関しては過去にMODX導入の件でCPIの担当者さんから相談を受けたことがありますが、UTF-8アプリになじまない基本設定のため難航しました。
サーバ側に問題があってもできるだけMODX本体で対応できるようにしたいですが、難しい場合はサーバ設定を調整することでとりあえず対応できると思います。
また機会を見つけて処理を見直してみますので、もし可能であれば検証に協力いただけると助かります。

(1) はノーコメントなのでそのままやって良いと理解しました。作業開始します。


サーバの方だとすると、そういえば思い出したことがあるので
これが問題に絡んでいるかわかりませんが一応お伝えしておきますと、
本サイトはサーバが提供していた（今はなくなっている）「簡単インストーラー」というモノでインストールしました。
MODX Japanサイトで案内されている手動インストールでインストールしてはいませんでした。
関係するかわかりませんが・・・

サーバ側に問題があってもできるだけMODX本体で対応できるようにしたいですが、
難しい場合はサーバ設定を調整することでとりあえず対応できると思います。
また機会を見つけて処理を見直してみますので、もし可能であれば検証に協力いただけると助かります。

はい、できることは何でも協力いたします。
サーバ設定の調整ですか。こちらでできるのならばやってはみますが、何をおこなえばいいでしょうか。
ただ、eForm問題はこのままにはしておけませんので、近々に直らないようならまた旧バージョンに戻さないと
まずいことになります。
旧バージョンに戻してしまったら、新バージョンの検証はできなくなりますよね。
そこが気になりますが

modxfan さんが書きました:本サイトはサーバが提供していた（今はなくなっている）「簡単インストーラー」というモノでインストールしました。

なるほど。CPIの場合は簡単インストーラを使ってMODXをインストールすればサーバ設定がきっちり整備されるので、それでその時は問題が起きなかったのだと思います。アップデートに関してはその時は相談を受けませんでしたが、問題があるということかもしれませんね。ダメでもともとでCPIさんに交渉してみます。

modxfan さんが書きました:eForm問題はこのままにはしておけませんので、近々に直らないようならまた旧バージョンに戻さないと
まずいことになります。
旧バージョンに戻してしまったら、新バージョンの検証はできなくなりますよね。

これもたぶん、eForm自体ではなくサーバ設定が関係していると思いますので、eFormを元に戻しても変わらないと思います。しばらくお時間ください。一日待ってCPIさんからお返事がなければ、サーバ側の設定を再確認してみます。

過去の情報を確認してみたところ、.htaccessとphp.iniのバックアップがとってあればなんとかなりそうな感じです。なければまた作る必要がありますが、いかがでしょうか？

php.iniに関しては、もしバックアップがある場合はファイルサイズも確認してみてください。CPIのサーバでUTF-8アプリを動かすためのphp.ini設定は、多めの分量になるので、数KB程度のサイズしかない場合はすでにおかしくなっている可能性があります。その場合はCPIのマスターを取得して手作業で作り直すことができます。

アップデート前にバックアップしておりますので、
.htaccessも、php.iniも、正常時のJ5-r3のときのバックアップならばあります。

php.ini　は46KBです。
ここのサーバは、コントロールパネル内に本ファイルの中身を掲載している画面があって、
それをコピペしてphp.iniファイル自体を作る方式でした。

そして、そこから何かいじったかどうかまでは記憶が定かでなかったので、
ひととおり中身を見ていったのですが、
もしいじったとしても画像データのアップロードの容量を変更したり戻したり、といったことだけだった気がするのですが。
これくらいしか案内できませんが、これで壊れているか否かの判定になりますか？

※冒頭説明通り、CPIのマスターも新たにGETできます

http://z.document.secure.ne.jp/tools/php/php02.html
CPIは他のレンタルサーバと違って、.htaccessとphp.iniを組み合わせて使う必要があるみたいです。バックアップをとってある.htaccessの先頭部分は「suPHP_ConfigPath」という記述から始まっているでしょうか？そうであれば、これは使えると思います。

.htaccessとphp.iniを元の場所(MODX設置ディレクトリ)に転送し直して、eFormの送信テストをもう一度試してみていただけますでしょうか。それでもタイトルが途切れる場合は、MODX側で対応を考えてみます。

あと、念のため今の時点でバックアップ画面でスナップショットをとっておくと安心だと思います。

感謝申し上げます。

スナップショット、便利ですね。ショットをいたしました。

「suPHP_ConfigPath」ですが、先頭ではなかったです・・・
二つ目に記述されています。
suPHP_ConfigPath /home/z2xxxxxxx/html/

先頭にあるのは、
AddHandler x-httpd-php528 .php
です。
これは、CPIサーバにおいてPHPファイルを動かすためのもので必要だそうで、
先頭に入れていました。
「suPHP_ConfigPath」が先頭でないのでこれだと使えませんですかね。
怖いのでまだ上書きアップしておりません。

いや、よく考えますと違いました。
htaccessとphp.ini　、なるほどそうかと思って行動しておりましたが、
よく考えると、そもそも既に、現在の新バージョンであるJ6-r8の状態にも、
.htaccessとphp.iniは、J5-r3のものを使っていました。
なので、もとよりそうなっていると思われます。

というのも、新バージョンのダウンロードファイルには
.htaccessも、php.ini　も存在しないので、この二つのファイルについてはもとからある、
つまり、正常時のj5-r3でアップしたままのファイルをそのまま維持していたのです。
新たに作る必要性が無いと思っていたのでした。

了解です、それではphp.iniの下記の部分だけいちおう確認いただけますでしょうか。
php.ini内で上記のように設定されていれば、php.iniとしては問題ないです。

eFormのsubject切れですが、送信主宛てのメールは途切れないというのが気になるので、少し調べてみます。やりようによっては解決できそうですね。

MODXのアップデートが今回うまくいかなかった原因は今のところ分からないです。昔からCPIさんは対応が難しくて、やっと問題なく使えるようになったと思っていたのですが・・

有難う御座います。
以下、チェックいたしました。しかしひとつだけ変でした。
mbstring.substitute_character
が二つあったのです。
最初に記載されていた方は、
mbstring.substitute_charactor=
となっていて、
後の方に再度登場した方は、
mbstring.substitute_character = none;
となっていました。これは正常なんでしょうか・・・

display_errors=Off

register_globals = Off

magic_quotes_gpc = Off

default_charset=UTF-8

mbstring.language = Japanese

mbstring.internal_encoding=UTF-8
mbstring.substitute_charactor=

mbstring.http_input=pass
mbstring.input_encoding=pass

mbstring.http_output = pass
mbstring.output_encoding=pass

mbstring.substitute_character = none;

MODXのアップデートが今回うまくいかなかった原因は今のところ分からないです。昔からCPIさんは対応が難しくて、やっと問題なく使えるようになったと思っていたのですが・・

私はサーバの詳しいところはわからないのですが、サーバによっても大変なことがあるのですね。
色々お手数をお掛けいたします

mbstring.substitute_characterは「mbstring.substitute_character = none;」のほうだけ残して、値のないもう片方は削除してみてください。CPIさんは値のないほうで検証とってますが、noneのほうが(諸説あるようですが)一般的には正しいと思います。

php.iniで指定したとおりにサーバが動作しているかどうかは、管理画面のヘルプで確認できます。管理画面右上の「ヘルプ」をクリックするとヘルプ画面が開くので、supportタブをクリックしてください。
下のほうに、
mbstring
mbstring.detect_order
mbstring.encoding_translation 0
mbstring.func_overload 0
mbstring.http_input pass
mbstring.http_output pass
mbstring.internal_encoding
mbstring.language neutral
mbstring.strict_detection 0
mbstring.substitute_character
こんな感じで設定値が出力されていると思いますが、この内容を教えていただけますでしょうか。

次に、メールまわりのパッチを作りましたので試していただきたいです。少し手順がありますが・・
添付のファイルを解凍して、２つのファイルを manager/includes/controls/ に上書きしてください。念のため、上書きではなく元のファイルをbak_modxmailer.inc.phpなどにリネーム退避もよさそうに思います。
片方、class.phpmailer.phpのほうはccsenderで送るメールにメッセージIDを付加しないバグを修正したものです。（たまたま見つけました）
もう片方がeFormなどMODXのメール送信機能の要となるファイルで、class.phpmailer.phpの機能を上書きする形で動作するものです。
とりあえずこれらのファイルはディレクトリに転送するだけです。

次に、簡単なプラグインを作ります。プラグイン新規作成画面を開いて、 とだけ記述し、システムイベントイベントタブでOnWebPageInitにチェックを入れ、適当にプラグイン名をつけて保存・閉じます。

次に、グローバル設定の「システムエラーをメールで通知する」を念のために「いいえ」にしておいてください。今回のデバッグ機能はまだ完全ではないので、大量にエラーメールを管理者宛てに送信してしまう可能性があるためです。

ここからダミー送信テストです。問い合わせフォームのページを開いて、通常どおり送信テストをしてみてください。
$modx->debugがtrueになっているため、実際にはメールは送信されず、管理画面の「レポート」「イベントログ」に蓄積されます。
このイベントログの内容を（一部伏せ字でもよいので）教えていただけますでしょうか。
送信テストをしたら、このまま忘れるとメールが送信されない状態のままなので、先ほどのプラグインの編集画面を開いて「プラグインを停止」にしておいてください。

ちょっとCPIのphp.ini は妙です。
まず、スペルが違うんです。
mbstring.substitute_charactor=
ですが、charactorとなっています。characterが正ですよね。
こうなっている上で、最下部あたりに
mbstring.substitute_character = none;
と、正しいスペルだと思うのですが記述がなされています。
最初の方の
mbstring.substitute_charactor=
はひとまず
; mbstring.substitute_charactor=
としてコメントアウトしておきました。
当方、知識が無いのでこのファイルは基本的に何もいじっていませんので
当然この箇所を当方が追記したはずはありません。

それから、気になって、今、CPIのコントロールパネルで掲載されているphp.iniが勝手に更新されているのではないか？と
想像し、見てみると、まさかまさかで内容が違っています。もちろん更新されたなどの連絡はCPIから来ておりません。

例えば、
mbstring.internal_encoding=UTF-8
だったのが
mbstring.internal_encoding = EUC-JP
に変わっていたり、
そもそも
mbstring.substitute_charactor=
の記述が消えていたり、
また、同じ行にあるべきものが全然違う行に書かれてあったりと、中身が違うんです。

現在、CPIに電話では受けられないと言われて保留のままにされたので、至急質疑メールを送っておりますが、
新のphp.ini　に差し替えた方がいいのかも知れないですよね。よって作業開始は待機とします。確認しますのでお待ちいただけますでしょうか。

サーバ会社からの返答を待っている間に、参考になるかわかりませんが、
現在アップし直ししたphp.ini のヘルプ→Support→mbstringの情報を掲載しておきます。

現在アップしたphp.iniは、
J5-r3でバックアップしていたphp.ini　を、御指示あった更新を加えたものです。

; mbstring.substitute_charactor=
として、
mbstring.substitute_character = none;
だけを残した。

mbstring
mbstring.detect_order auto
mbstring.encoding_translation 1
mbstring.func_overload 0
mbstring.http_input pass
mbstring.http_output pass
mbstring.internal_encoding UTF-8
mbstring.language Japanese
mbstring.strict_detection 0
mbstring.substitute_character

mbstring
mbstring.detect_order auto
mbstring.encoding_translation 1
mbstring.func_overload 0
mbstring.http_input pass
mbstring.http_output pass
mbstring.internal_encoding UTF-8
mbstring.language Japanese
mbstring.strict_detection 0
mbstring.substitute_character

ありがとうございます。mbstring.detect_order auto・・ここがちょっと気になります。

http://memo.xight.org/2007-02-14-1
autoを指定していても結果オーライで文字化けが起きないサーバも多いですが、いちおう正しく指定しておいたほうがよいかも？

mbstring.detect_order = UTF-8,JIS,EUC-JP,SJIS,ASCII
上記のように書くとよいと思います。普通はutf8・euc-jp・jisの順番にすることが多いと思いますが、euc-jpを使うことは実際はほとんどなく、メールではjisを使うので第2優先にしてます。

mbstring.detect_order = UTF-8,jis,eucJP-win,SJIS-win
こちらのほうが（ほんの少しだけ）確実かも？

もしかしたらCPIさんから何か新しい情報があるかもしれませんね。こちらではメールまわりをよく見直しておきます。

サーバ会社からの返答はまだなのですが、php.ini　を見比べておりましたところ、記憶が蘇ってきました。

サーバ会社のphp.ini　をもとにして当方が変更を加えていたことがあるのを思い出しました。

リソース作成で画像を投稿する際に、画像が自動縮小されず、単に縮小表示されるだけになっているので
質問したりしたときに、「こう記述してください」という話を聞いて変更したことがある気がします。
混乱させて申し訳ありません。

CPI純正と、変更を加えたものの相違箇所を以下にまとめました。
問題あれば修正します。なければ
mbstring.detect_order = UTF-8,jis,eucJP-win,SJIS-win
にしたうえで、おっしゃっておられる作業を開始したいと思います。
お手数お掛けいたします。


●相違箇所１
------------------------------------------------------------
CPI純正
display_errors = On

J5-r3
; display_errors = On
display_errors=Off
------------------------------------------------------------


●相違箇所２
------------------------------------------------------------
CPI純正
magic_quotes_gpc = On

J5-r3
; magic_quotes_gpc = On
magic_quotes_gpc = Off
------------------------------------------------------------


●相違箇所３
------------------------------------------------------------
CPI純正
default_charset = "iso-8859-1"

J5-r3
;default_charset = "iso-8859-1"
default_charset=UTF-8
------------------------------------------------------------


●相違箇所４
------------------------------------------------------------
CPI純正
upload_max_filesize = 100M

J5-r3
; upload_max_filesize = 100M ( Default Settei )
upload_max_filesize = 2M
------------------------------------------------------------


●相違箇所５
------------------------------------------------------------
CPI純正
mbstring.internal_encoding = EUC-JP

J5-r3
; mbstring.internal_encoding = EUC-JP
mbstring.internal_encoding=UTF-8
------------------------------------------------------------


●相違箇所６
------------------------------------------------------------
CPI純正
mbstring.http_input = auto

J5-r3
; mbstring.http_input = auto
mbstring.http_input=pass
mbstring.input_encoding=pass
------------------------------------------------------------


●相違箇所７
------------------------------------------------------------
CPI純正
mbstring.http_output = pass

J5-r3
mbstring.http_output = pass
mbstring.output_encoding=pass
------------------------------------------------------------

詳細情報ありがとうございます。いろいろ参考になりそうです
以下、私自身の確認も含めてコメントしますね。

> display_errors=Off
ここはたしかMODX本体内で値を変更できるようになっていて、管理者モードでアクセスしている時はOn、一般のゲストがページを見る時はOffになってたと思います。
開発者でなければOffが基本的に無難だと思います。ここがOnだと、エラー時にサーバのパス情報などをそのまま表示してしまいますので・・

> magic_quotes_gpc = Off
Offが正解ですね。ここがOnだと投稿時に不要なスラッシュが挿入されたり、いろいろ不具合の元になります。（いちおうMODX本体ではこの設定の影響を受けないように特別な処理を加えてます）

> default_charset=UTF-8
これもutf-8で正しいですね。今後のPHPはiso-8859-1ではなくutf-8がデフォルトになると思います。

> upload_max_filesize = 2M
ここは修正を加えたほうがいいかもしれません。2Mだと最近のデジカメ写真だとアップロードできないと思うので、少なくとも8Mは必要だと思います。WordPressみたいに同時に複数の画像をアップロードできるCMSだと、8Mでも少なくて24MBくらいを指定するのが普通かもしれません。

> mbstring.internal_encoding=UTF-8
> mbstring.http_input=pass
> mbstring.input_encoding=pass
> mbstring.http_output = pass
> mbstring.output_encoding=pass
上記も正しいと思います。特にmbstring.http_inputはMODX本体内の処理で変更できないので、この設定値が原因で問題が起きる場合は、php.iniや.htaccess内で指定する必要があります。

というわけで、eFormの件とは関係ないですが、今回はupload_max_filesizeだけ修正するとよいかな？と思います