画像表示の不具合(d3diary_0.18)


投稿ツリー


前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2011/7/22 12:18 | 最終変更
ほんだ 

なーおんさん、いつもお世話になっています。

0.18で画像表示の不具合ありまして、また教えていただければ幸いです。

ホダ塾 のCube Legacy 2.1.6
サーバは ヘテムル Apache 2.0.xx
データベース MySQL5
PHP PHP5.2

・_detail.html、index.htmlなどで、画像が表示されません。
・画像はアップロードされていて、サーバにあります。
・プレビューの際は、画像も表示されます。

・upimgなどのフォルダのパーミッションは、777、705などで試してみましたがいずれもNGでした。
・ソースをみると、テンプレートの

PhotoBoxの部分が入っていないので、

  if $yd_photo.0.pid|count_characters>0

が上手く動いていないのかな?という感じです。

なにか原因がありますでしょうか。

投票数:0 平均点:0.00
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2011/7/22 13:14
なーお  長老   投稿数: 1580

ほんださん、こんにちは。

ご報告ありがとうございます。

画像表示ができない件、以下の項目をご確認いただけますか。

  1. テンプレートの変更
    <{if $yd_photo.0.pid|count_characters>0}>
     ↓
    <{if $yd_photo.0.pid}>
    これで表示されるかどうか。 されなければ、そもそもアサインされていないということですね。
  2. プレビューせずにアップロードした時、画像がサーバーにあるか確認。
  3. プレビューした後に登録したとき、画像がサーバーの「prev」フォルダーに残っているか、upimgフォルダに移動しているか確認。
  4. phpmyadminなどを使って、「phpto」テーブルにデータがあるか確認

以上、よろしくお願いします。

投票数:0 平均点:0.00
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2011/7/22 17:15
ゲスト 

なーおさん、確認してみました。

画像表示ができない件、以下の項目をご確認いただけますか。

  1. テンプレートの変更
    0}&gt;
     ↓
    
    これで表示されるかどうか。 されなければ、そもそもアサインされていないということですね。

表示されませんでした。

  1. プレビューせずにアップロードした時、画像がサーバーにあるか確認。

画像はサーバにあります。
サムネイルもできています。

  1. プレビューした後に登録したとき、画像がサーバーの「prev」フォルダーに残っているか、upimgフォルダに移動しているか確認。

プレビューで画像表示されたあと、登録しました。
画像は「prev」フォルダーに残っていません。

  1. phpmyadminなどを使って、「phpto」テーブルにデータがあるか確認
phpmyadminで確認しようと思ったのですが、「phpto」テーブルが見つかりませんー??

今回のd3diary_0.18は、0.16→0.17→0.18と、2回バージョンアップしました。0.16のときには、画像は普通に登録できていました。

投票数:0 平均点:0.00
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2011/7/22 18:10
なーお  長老   投稿数: 1580

ほんださん、こんにちは。

引用:
phpmyadminで確認しようと思ったのですが、「phpto」テーブルが見つかりませんー??

なんですってえ? :-o

アップデートで消えたとすると、(trust)/modules/d3diary/onupdate.phpの中に

141
142
143
144
145
146
147
148
149
150
151
152
    // 0.18
    // modify photo `tstamp` column data type from timestamp to datetime
    $result = mysql_query("SELECT `tstamp` FROM ".$db->prefix($mydirname."_photo")) ;
    $field_type  = mysql_field_type($result, 0);
    if ( $field_type == "timestamp" ) {
        $db->queryF( "ALTER TABLE ".$db->prefix($mydirname."_photo")." modify `tstamp` datetime NOT NULL" ) ;
        // for NULL tstamp, copy from diary's create_time
        $sql = "UPDATE ".$db->prefix($mydirname."_photo"). " p 
                INNER JOIN ".$db->prefix($mydirname."_diary")." d USING(bid) 
                SET p.tstamp=d.create_time WHERE (p.tstamp IS NULL) OR (p.tstamp = '0000-00-00 00:00:00')";
        $result = $db->queryF( $sql ) ;
    }

があるはずですので、これが悪さをした可能性、、 なのかなあ。。

対処方法としては、最新のバックアップからこのテーブルをリストアいただき、もう一度アップデートしてみる、ということしか思いつかないです。。

投票数:0 平均点:0.00
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2011/7/22 18:42
ほんだ 

むむむ、バックアップとってないかもです~

これからバックアップして、
一度モジュールをアンイストールのうえ、再インストール、で、リストアでも大丈夫ですよね?

投票数:0 平均点:0.00
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2011/7/22 18:47
なーお  長老   投稿数: 1580

ほんださん

バックアップなかったですかー。

バックアップ・リストアは慎重に、、

リストアの時に、バックアップ時に無かったテーブルがリストア先であった場合はそのテーブルは残るはずなので、空のphotoテーブルは残るはずですね。。

それか、現状でcreate table で photoテーブルを作るという方法もありますね。

投票数:0 平均点:0.00
返信する

このトピックに投稿する

題名
ゲスト名
投稿本文
  条件検索へ