登録日
2010年12月13日

メンバー検索

  

build1024

名前(ニックネーム)
build
自分のconcrete5サイト
ホームページ
http://www.every-little.com/
自己紹介
2010年からオープンソースCMSを色々触っています。サイト制作経験のあるのはconcrete5, MODx, WordPress。
本家サイトでは別名義(hira)でやっています。concrete5の内容はconcrete5サイトに、それ以外は本家サイトに分ける予定(concrete5サイトは開発途上です)。
concrete5.org のユーザー名
concrete5 Slack Team ID
Twitterアカウント
@build_kobekko
フォーラム総投稿数
50

コミュニティバッジ

投稿

41から50までを表示 (計50)

Re: Re: パッケージ領域の優先順位について

taoさん、ありがとうございます。

要するに、パッケージのインストール時(controller.php の ***Package::install() 内)にブロックなら BlockType::installBlockTypeFromPackage()、テーマなら PageTheme::add() を呼び出して登録するように、おそらくhelperなどにも登録用のメソッドがあるだろうということですね。後日調べてみたいと思います。

# 試したところなぜかmodelも読んでくれない様子なので、きっと登録がうまくいっていないのですね…。

Posted on 1月 04, 2011 at 1:21 午前

パッケージ領域の優先順位について

concrete5.4.1.1用のパッケージ制作を試しているとき、表題の件について疑問に思ったので質問させてください。

concrete5 のシステム基本構造のページを見ると、例えばパッケージ領域内に tools/files/properties.php というファイルを作成してそのパッケージをインストールした状態では、ユーザー領域に tools/files/properties.php が無ければ、コアの tools/files/properties.php は読まずにパッケージ領域内のそれを読みに行くものと解釈していますが、実際にやってみると、どうもパッケージ領域のファイルを読んでくれないようなのです。(tools以外、例えばelementなども同様です)
パッケージのインストール自体はちゃんとできています。

Loader::helper() とか Loader::packageElement() など、$pkgHandle という引数をもつメソッドが鍵なのでは?と思ったりもしますが、これらを何らかの方法でパッケージの controller.php から呼び出せばよいのでしょうか?それとも、そもそも既存ファイルのオーバーライドはパッケージでは行えないものなのでしょうか?
どなたかご存知の方がいらっしゃいましたら教えていただければ幸いです。よろしくお願いいたします。

Posted on 1月 04, 2011 at 12:35 午前

Re: Re: ファイル名のマルチバイト文字対応

私も、日本語URLの動向を見てからでも遅くないと思います。本家との乖離が進み過ぎると危ないですしね。

「営業」というのは要するに、Katzさんが別スレッドでおっしゃっていた、本家にマルチバイト対応の重要性をわからせる、ということですね。
さしあたり、私も本家フォーラムに参戦し、その「別スレッド」の「ユーザー属性の表示をハンドル名から名前に戻せ」という件について、(私が実際に困ったということもありますので)投稿してみました。(あんな感じでいいんでしょうかね?) レイアウトの件については、自分が使ってないのでノーコメントという感じですが…。

とにかく、ひとたび参戦したので、後は本家フォーラムで色々言うのもそれほど苦にはならないかも…と思っています(英語の問題はさておき)。可能な範囲で協力させていただこうと思いますので、よろしくお願いいたします。

Posted on 1月 03, 2011 at 2:05 午前

Re: Re: ファイル名のマルチバイト文字対応

個人的にはサーバ上にはハッシュ等のユニークな名前で保存し、ダウンロード時に設定された元のファイル名でダウンロードする様にした方がよいかな?と考えています。

元のファイル名でダウンロードさせることについては、現に上で提示したものもそのような仕様にしてあります。
ただ、ハッシュを適用した名前でサーバー上に保存すると、既存システムに適用したときにファイルが呼び出せなくなると思い、現状では「Punycodeのエンコード結果を利用」という形にしています。

実は日本語のURLについてもずいぶん前に「urlencodeではなく、Punycodeではどうか?」という議論がありました。
Punycodeは%が入らなくて短く出来る点は良いのですが、エンコード、デコードにライブラリが必要でPHP標準関数では対応出来ない事と、そのために若干動作が重くなる事からURLencodeにしました。(URLはページを表示する度に何回も処理される部分なので...)

確かに重さの点は重要ですね。現段階での仕様としては、データベースにはマルチバイト入りのファイル名をそのまま格納しており、サーバー上のファイルを呼び出すときにその都度変換を施しています(よってデコード処理を一切使っていません)。データベースの構造を変えなくていいので楽ですが、負荷の面は考える必要がありますね。
ただ、日本語URLと違い、ファイル名の場合はurlencodeだとファイルシステムの限界(255バイトなど)を簡単に超えそうで怖いのです(日本語1文字に対して、UTF-8では典型的には3バイトで、1バイトが %81 のように変換されるので、エンコード結果は都合9バイトになりますね。30文字弱で限界を超えます)。もちろんサーバー上のファイル名としてハッシュ関数の結果を使うならこの限りではありませんが。

今回の5.4.1.1でも日本語ファイル名の対応は議題にあがりましたが、時間切れで次期バージョンに保留となってしまいました。
なので、もし可能であればconcrete5版のアドオンなりパッチなりを作成して頂き、次期バージョンのリリースまでに検証出来れば嬉しいです。

そうですね、エンコード方法の選択やその長短も含めて議論の余地があるでしょうから、次期バージョンのリリースまでにゆっくりと、という感じになるでしょうか。

Posted on 1月 03, 2011 at 1:40 午前

ファイル名のマルチバイト文字対応

5.4.1.1がひとまずリリースに至りましたね(まだ問題もあるようですが)。開発陣の皆さんお疲れ様でした。

一段落したところで(早い)、タイトルの件についての提案です。(日本語URLへの対応にも関連して…)
ファイルマネージャに日本語などマルチバイト文字を含むファイルをアップロードすると、現状ではマルチバイト文字が削除されて登録されます。(「写真1.jpg」 → 「1.jpg」 のように)
開発者 or 管理者の立場からいえば、マルチバイト文字を含むファイル名はトラブルのもとというのは当たり前なのですが、それをconcrete5で構築したサイトのユーザーひとりひとりにまで強制するのは困難だと思いますし、やはりマルチバイト文字を使えたほうが便利には違いないでしょう。でもサーバーにはマルチバイト文字を含むファイル名をもつファイルを置きたくない。

というわけで、試しにスクリプトに改造を施してみました。(5.4.1.1用です)
http://hira.hopto.org/software/concrete5/mb_filename.xhtml
(私のWebサイトです[concrete5製じゃないです;;]。こことは別名義でやっています)
PEARのNet_IDNA2ライブラリを用いて、オリジナルのファイル名をPunycodeでエンコードしてサーバーに置く方法を採用しています。Punycodeを使った理由は

1. 既存システムとも互換性がとれる(英数文字のみのファイル名ならエンコードしてもそのまま)
2. ファイル名が長くなりすぎない(URLエンコードでも1.は満たしますが、ファイル名のバイト数が最大3倍になってしまうし、%を含むファイル名だとURLに変換するときにさらにURLエンコード(% → %25)が必要になって面倒)

というものです。既存の枠組みを活かしながらなので実装が少々雑ではありますが、皆さんのご意見をお聞かせいただければ幸いです。
(これってむしろ本家フォーラムに投稿すべきことのような気もしますが)

添付ファイルは上記URLで配布しているZIPファイルです。

添付: mb_filename.zip
Posted on 1月 02, 2011 at 10:09 午後

Re: concrete5のアップグレード方法について

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Tokyo' for 'JST/9.0/no DST' instead in /(サーバの階層)/public_html/concrete5/concrete/libraries/cache/default.php on line 91

エラーメッセージが言うには「date.timezoneを設定するかdate_default_timezone_set()関数を使え」ということですね。
というわけで、date.timezoneを.htaccessから設定してしまうのはいかがでしょうか。concrete5ルートの.htaccess(なければ新規作成してください)に
php_value date.timezone Asia/Tokyo

の1行を追加して保存してみてください。

ただ、使用条件のページには
PHP 5.2.0 以上推奨 (PHP5.3はバージョン5.3.3以降で対応。5.3.1.1以降から PHP 5.1.0以上になりましたが、タイムゾーンのサポートをしている5.2.0以降を推奨しています。)

と書いてあります。要するに、concrete5.3.2はPHP5.3.3には対応しないということですね(concrete5とPHPのバージョン番号が近いのでややこしい…)。その旨を理解された上で運用されるか、concrete5をバージョンアップする必要があると考えられます。concrete5とPHPのバージョンが適合していれば、.htaccessの設定はしなくても大丈夫ではないかと思います。

またアップグレードはphpのバージョンを上げる前にconcrete5のアップグレードから行ったほうが良いのでしょうか?

concrete5のバージョンと要求されるPHPバージョンの兼ね合いを考えると、「concrete5のアップグレード→PHPのアップグレード」のほうが無難なのかもしれません。逆だからできないということはないと思いますが。

もし不明な点があれば気軽に返信してくださいね。100%回答できる自信はありませんが。

Posted on 12月 29, 2010 at 11:51 午後

Re: 5.4.1.1.b5 日本語版アップ

b2, b4についてのテスト結果を報告した者です。b5でもチェックしてみました。

> 1) 管理画面の「ユーザー・グループ管理」で表示される属性名など
ユーザー・グループ管理、ファイルマネージャとも、以前指摘した点の修正を確認しました。

> 2) 「ファイルマネージャ」やページの「バージョン」でのタイムスタンプ表示
こちらも修正されていることを確認しました。

ということで、以前報告した部分に関しては大丈夫なようです。ありがとうございます。

それと、

> 5) 管理画面のダッシュボードの文字化け
については、Ubuntu 10.10 (XAMPP 1.7.3a, Apache 2.2.14, MySQL 5.1.41, PHP 5.3.1) でもローカルでテストしてみたところ、デフォルトで特に問題ありませんでした(OSの文字コードもUTF-8ですし)。Windows特有の問題でしょうね。

最後に1つ、また気になったことを。
管理画面の「ファイルマネージャー」で表示されるセットですが、星マークを点灯させたファイルを絞り込むセット「Starred Files」が英語のままになっています(日本語訳だと「スター付きファイル」とか?)。大勢に影響はないかと思いますが。

軽くチェックしてみた限りはそんなところです。お忙しい中での対応、改めて感謝します。

Posted on 12月 29, 2010 at 11:12 午後

Re: Re: Re: Re: 5.4.1.1.b4 日本語版ベータ配布開始!

と言うか是非日本語版のコミッターになりませんか?
Usagi Projectに入って頂くだけでOKなんで。

こういう動作テストなどでよければ、協力は惜しみません。メインの開発メンバーというわけにはいかないと思いますが…(あくまでユーザー寄りの立場での意見になるかと思います)。
ただ即決するのもどうかと思いますので、少し考えさせてください。
加入しようと思えば「メンバー募集中」から必要事項を送信すればよいのですかね?

.htaccessの設定ですが、internalencodingの他にlanguageの設定が必要です。

教えていただいた設定を行ってみましたが、どうも変わらないようです。
ただ、たとえ文字化けせずに表示されたとしても「03:50 午後」のようにちょっと間抜けな表示になるので、config/site.php あたりで日時表示のロケールをいじるほうがいいのか(例えばen_USにするとか)と思ったりもします。日付のところが(strftimeの %x で返される日付が)「12/24/10」のようなフォーマットになってしまうので、それはそれで日本人にとっては変ではあるのですが。
調べてみると「iconvを使って対応せよ」という情報があったりもしますが、これだとスクリプト自体の変更になるので、あまり気が進まない感じではあります(ロケールくらいならsite.phpでやってもいいですが…)。

ちなみに、ベータ版なのでローカル環境にしかインストールしていませんが、本番環境で使うサーバー(symphonic-net.com)でstrftime関数の挙動を調べますと、%P が「午前」「午後」ではなく「AM」「PM」を返しましたので、このような文字化けの問題はないと思われます。

何度もお手数をおかけします…。

P.S.
ロケールの設定はプロセス単位に影響が及ぶようなので、共有サーバーでかつPHPがモジュールモードで動いているとまずいかもしれませんね…。
ちなみにsymphonic-netサーバーでは
setlocale(LC_TIME, 'ja_JP.UTF8');

でOKのよう(strftimeの %x が「2010年12月24日」のように日本語に展開され、%P の文字化けも問題なし)ですが、Windowsではこの設定が反映されないようでした。

Posted on 12月 24, 2010 at 5:03 午後

Re: Re: 5.4.1.1.b4 日本語版ベータ配布開始!

b2の問題を報告させていただいたbuild1024です。b4にアップグレードしてみましたので、先日報告した点について再確認した結果を書いておきます。
実行環境は以前と同様(Windows 7, XAMPP 1.7.3, Apache 2.2.14, PHP 5.3.1, MySQL 5.1.41)です。

> 1) 管理画面の「ユーザー・グループ管理」で表示される属性名

ユーザー一覧ページや「ユーザー編集」の画面については修正を確認しました。しかし、まだ同様の問題が起こっている箇所があるようで、

・「ユーザー検索・一覧」にある「検索」のフォームで、+ ボタンを押すとフィールド名を選択するボックスが追加されますが、そこの属性名はハンドル名のままです
・同じく「ユーザー検索・一覧」で、ユーザーIDをクリックして「ユーザー表示」に切り替えると、「その他情報」の欄がやはりハンドル名表示となっています(こちらは「週刊 concrete5 vol.11」の2時間10分あたりで確認していただきましたね)

という状況でした。さらに、ユーザー管理のみならず、

・「ファイルマネージャ」のファイル一覧での検索フォーム(+ ボタン)、一覧見出し右端「検索をカスタマイズ」をクリックしてダイアログを表示したとき「追加属性」欄に表示される属性名についても、ユーザーのときと同じくハンドル名が出ています

ということもわかりました。「週刊 concrete5」で「何をお考えなのですか本家は」との発言がありましたが、同感です…。もしかすると他にもまだ同様の箇所があるのかもしれません。気づきましたら報告します。

> 2) 「ファイルマネージャ」やページの「バージョン」でのタイムスタンプ表示

こちらはどうも修正されていないようです(message.poの16262行目の Y/j/n となっている箇所が問題のようです)。

> 3) 「ファイルマネージャ」でのファイルの設定

修正を確認しました。ありがとうございます。

> 4) 管理画面の「下書き」

そのままにしておくという結論でしたが、了解しました。確かに修正するほどかと言われればそうでもないという気もします。

> 5) 管理画面のダッシュボード

concrete5直下の.htaccessに、
php_value mbstring.internal_encoding UTF-8
を追記してみましたが、どうも改善されないようです。キャッシュを消去してみたり、Apacheの再起動をしてみたりしましたが同じでした。
phpinfo(); を呼び出すPHPファイルをconcrete5のルートに置き、ブラウザからアクセスしてみますと、確かに当該項目はUTF-8に変更されているのですが…。もう少しあれこれ試してみたいと思います。

以上、b2で指摘した箇所に関する追加報告でした。調査をよろしくお願いします。

Posted on 12月 24, 2010 at 4:07 午後

Re: Re: 今度は 5.4.1.1.ja.b2 日本語版ベータ

はじめまして、concrete5.4.1.1.ja.b2をWindows 7上のXAMPPでテストしております。
(XAMPP 1.7.3, Apache 2.2.14, PHP 5.3.1, MySQL 5.1.41)
概ね問題なく動作しているようですが、気になったところをいくつか挙げてみます。主に管理画面関係です。

1) 管理画面の「ユーザー・グループ管理」で表示される属性名
「ユーザー検索・一覧」や「ユーザー表示」で、属性の名前がハンドル名で表示されているようです。
(「他のメンバーからのメッセージを受付ける」ではなく「Profile Private Messages Enabled」と出ます)
concrete5.4.0.5のときはちゃんと出ていましたが、本家の仕様が変わったのでしょうか?

2) 「ファイルマネージャ」やページの「バージョン」でのタイムスタンプ表示
例えば「2010年12月13日 午後10時56分」が「2010/13/12 10:56 PM」という書式で表示されています。月と日が逆の方が読みやすいと思いますので、翻訳でカバーしていただけるとありがたいです。

3) 「ファイルマネージャ」でのファイルの設定
ファイルを選択して「設定」を表示すると、「登録日」の欄が「2010年11月29日 at 21:0に追加」のように、常に「分」の部分が0と表示されてしまっています。いろいろ調べると、message.poの14800行目で「G:i」とすべきところが「G:I」となっているのが原因のようです。調査をお願い致します。(5.4.0.5でもそうなっていたと思います)

4) 管理画面の「下書き」
「○○さんの下書きセット」という表示がありますが、ユーザーIDが小文字で始まっていても先頭が大文字になります。日本で使う分には小文字のままのほうがいいのではと思いますが、いかがでしょうか。(こちらも5.4.0.5の頃からそうでした)
(concrete/elements/block_area_add_scrapbook.php の60行目の ucfirst を外して対応しています)。

5) 管理画面のダッシュボード
「サイトアクティビティー」のところですが、「ログイン日時」と「最終更新」の欄で、時間の後ろに文字化けしたような変な文字列が付いています。調べてみると concrete/controllers/dashboard/modules/activity.php の17行目の書式文字列がポイントとわかりましたが、どうもこれはconcrete5ではなくPHPの問題のようです(strftime関数が、%pに対応してShift-JISコードで「午前」or「午後」という文字列を吐くようです)。

いろいろ一度に書いてしまいましたが、concrete5の開発に期待しておりますので、どうかよろしくお願い致します。(また何か気づいたら書きます)

Posted on 12月 13, 2010 at 11:03 午後
« 前12345次 »