http://www.visser.com.au/blog/thumbnail-generation-php-memory-limit-nextgen-gallery/
こちらの情報から
#vi gd.thumbnail.inc.php
164 //@ini_set(‘memory_limit’, ‘128M’); （当方のラインNo164）をコメントアウトするも
改善されませんでした。
以上です。
http://ja.forums.wordpress.org/topic/9293
こちらのトピックで『アップロードも正常に行なっているように見えます。ファイル名などはあるようなのですが、実態が無いような状況です。』と書いていますが、Manage Galleryのギャラリーの編集画面で、ファイル名や画像サイズが表示されている状態なのでしょうか？
『* picture(s) successfully added [Edit gallery]』というメッセージが表示される場合は、おそらく正常にアップロードされていると思います。
実際にアップロードされているかどうかは、アップロード先のディレクトリの中を確認してみてください。
画像がアップロードされていない場合、そちらに関しては分かりませんが、サムネイルが表示されない問題に関しては、OptionsのSelect graphic libraryを正しく設定すれば表示できるかもしれません。
同じサーバーで同じPHPを使用して問題なく動作しているのでしたら、そちらの設定と同じにしてみてください。
GD拡張が使用できない場合、プラグインチェックの「Test image functionでは×になりますが、ImageMagickを使う場合は、ここの表示は気にしなくても大丈夫です。
ギャラリーの編集画面で、リスト上の任意の画像にマウスオーバーしてEdit thumbをクリックすると、後からでもサムネイル画像を変更できます。
画像の範囲を選択してからUpdateを実行しますが、選択した範囲によってはサムネイル画像の作成に失敗することがあります。
混乱を招く表現になっていました。申し訳ありません。
障害は2つあります。
①画像がアプロード出来ないです。WordPressアップローダーからもFlashアップローダーからもできません。（3.3.1アップデート以降）
②NextGEN Galleryのサムネイルが表示されません。（3.3.1以前からです）
※プラグイントピックに統一した理由は、NextGEN Galleryの管理画面で[プラグインチェック]を実行すると☓となり、「画像作成が出来ません。memory limitを確認して下さい。」というメッセージが出るので、それぞれの問題の根元がここにあるのかなと勝手に想像しこちらにも取り上げました。
本日気が付いたのですが、同一Server内別ディレクトリの正常に稼動しているWordPressを確認してみたところ、[プラグインチェック]は同様に☓となってエラーが発生しています。
ですので、障害を起こしているアプロードとサムネイルが表示されない件とは関係なさそうなので、この件は別途検討したいと思います。＜–[プラグインチェック]
＜アップロードの不具合の件は自己解決です！＞
アップロードされるディレクトリ
http://my.domain/wp/wp-content/uploads/2012/03/file.jpg
内部を調べてみると残念ながらファイルがありません！
/wp-content/uploads/2012/03 ← 画像が格納されているディレクトリ
# cd /wp-content/uploads/2012
# ls -al 内部の確認
drwxr-xr-x 2 root root 4096 3月 13 14:04 .
drwxr-xr-x 5 apache apache 4096 3月 13 14:04 ..
だったので、
#rm -rf 03 ディレクトリの削除
# ls -al 内部の確認
drwxr-xr-x 2 apache apache 4096 3月 13 14:04 .
drwxr-xr-x 5 apache apache 4096 3月 13 14:04 ..
これはいけるぞと思い、
再度WordPressからアップロードしましたら正常にアップ出来ました。
※ディレクトリ内のドットファイル（隠しファイル）のパーミッションがrootだった！
お騒がせしました。
NextGEN Gallery はまだ問題を抱えていますが、一旦解決とさせて頂きます。
サムネイル画像が表示されないのは、画像ライブラリが入っていない為です。
NextGEN GalleryはGDでもImageMagickでもどちらでも大丈夫なのですが、WP本体の機能ではGDを使用しているようですので、GD拡張を入れた方がいいかもしれません。
Linuxの知識になりますが、.（ドット1つ）はカレントディレクトリ、..（ドット2つ）は一つ上のディレクトリを表します。
HTMLの相対パスの表記と同じです。
パーミッションの一つ目の文字で、ファイル・ディレクトリ等の種別が判断できます。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060228/231068/
最初の1文字はファイル，ディレクトリ，シンボリック・リンクのいずれであるのかを示している（下表）。
記号 意味
– ファイル
d ディレクトリ
l シンボリック・リンク
cd で「wp-content/uploads/2012」に移動後、ls -alで内部の確認、
drwxr-xr-x 2 root root 4096 3月 13 14:04 .
drwxr-xr-x 5 apache apache 4096 3月 13 14:04 ..
その後rm -rf 03で「03」ディレクトリを削除してから、再度ls -alで内部の確認を行って問題がなくなったようですが、上記の手順を省略して書いたでしょうか？
「wp-content/uploads/2012」の所有者およびグループの変更を行っていないのに、「root root」から「apache apache」に勝手に変わっているのがちょっと気になったもので。
省略しただけなのでしたらいいのですが、誤解を招かない為にも重要な箇所は省略しないで報告した方が、他の方にも参考になると思います。
ご指摘ありがとう御座います。
NextGEN Gallery、サムネイル等の不具合はそもそも、GDのインストールに問題がありました。
この件については既にそちらの方でもご報告していますが、
# yum install gd
この操作で、GDがインストールされたと思い、長い間何の疑いもなくNextGEN Galleryを使用していました。生成されていなかったサムネイルが生成されたのでした。
その後、更に別のディレクトリにWordPressをインストールし、同様にNextGEN Galleryをインストールをしてもサムネイルが生成されませんでした。
結果的には、GD拡張を入れるべきところを全く気にせず使用していたのが間違いでした。
そこで、
# yum install php-gd とするもエラーが発生し、調べたところ、PHPバージョン : 5.3.3は
# yum install php53-gd
で解決しました。
二つ目の所有権の件ですが、（パーミッション）
これも、肝心なことを省いてしまいました。
# rm -rf 03 でディレクトリを削除し、
# mkdir 03 としようと思ったのですが、あえてこれをせず！
※NextGEN Galleryのアップローダーで再度同様のMediaをアップロードしてディレクトリを作らせたというのが今回の手順でした。
以上です。
