ワードプレスのメディアにアップロード出来ない時の解決方法まとめ

本番サイトで、寄稿者権限のコンテンツライターさんに記事を直接下書き納品してもらう事があります。

その時、メディアのアップロードが出来ないと連絡をいただきました。

運営者として自分でコンテンツを追加する時は、ローカル開発環境のVCCWで問題が無かった為に気付いていませんでした。

本番サイトの環境はKUSANAGIです。開発環境と本番環境でステージング環境を整える必要が有りますが、Vitualbox/Vagrantの場合、残念ながらパーミッションの再現性を開発環境と本番環境で等しく出来ないです。

この記事は、VPSのconoha KUSANAGI Nginx php-fpmの本番環境にwindowsパソコンでFileZillaやTeraTermを使ってssh接続した例で説明しています。

※サーバーによってディレクトリ構造が異なる場合がありますが、Linuxを採用しているレンタル共有サーバー等であれば参考にしていただくことが出来ます。

※Windowsのフォルダは、概ねLinuxでディレクトリと言われます。

ディレクトリのアクセス権についてエラー文章が出る

本番サイトでワードプレスのメディアに画像ファイルをアップロードしようとしたら出来ない！

という時、下記の様なメッセージがダッシュボード画面の下部に出てくることがある思います。

ディレクトリ wp-content/uploads/2016/10 を作成できませんでした。この親ディレクトリのアクセス権はサーバーによる書き込みを許可していますか ?

英語の場合

Unable to create directory wp-content/uploads/2016/10. Is its parent directory writable by the server?

ワードプレスでは比較的に起こりやすい問題ではないでしょうか。

パーミッション755と再帰的で解決

パーミッションとは？

UNIX 系の OS で、ディレクトリやファイルに対する アカウント ごとのアクセス権のことをいいます。他の系列のOSにも同様のアクセス権が設定できるものもありますが、パーミッションと呼ぶ場合は一般にUNIX系のOSに限られます。

⇒お便利サーバー.comより引用。やや強引ですがLinux≒UNIXと考えてください。

手元のパソコンがwindowsの方は、FileZilla等でパーミッション操作が可能なLinuxユーザーでLinuxのサーバーに接続を行ってください。

そして、

/home/kusanagi/任意のプロファイル・ディレクトリ名/DocumentRoot/wp-content/uploads

のuploadsの上で右クリック⇒「ファイルの属性」をクリックします。

上記の様な「ファイルの属性を変更」の小さなウィンドウが出てきたら、①の様にパーミッション数値を755に変えます。

②「サブディレクトリの中の再帰」にチェックを付けて、「すべてのファイルとディレクトリに適用」にもチェックを入れます。

最後に「OK」をクリックしてください。

ポイントは「再帰的（さいきてき）」です。upoloadsディレクトリの中にある全てのファイルとディレクトリの権限を755に変えるという事になります。

再帰的を指定しないとuploadsディレクトリだけ755になり、ディレクトリ内のものがすべてパーミッション変更されません。

uploads/2016/10など、ディレクトリが深層まであるので、再帰的にパーミッションを設定してください。

wp-contentでパーミッション変更をしない

メディアのアップロードだけの問題なのに、wp-contentでパーミッション変更をする事はやめましょう。

セキュリティリスクが無駄に増えます。

パーミッション制限範囲の緩和は最小限に抑える事がセキュリティの基本です。

パーミッション変更Linuxコマンド

FileZillaを使わない場合、TeraTermやCygwin等で本番環境に接続して、nginxの動作ユーザーでコマンド操作していることを確認して以下のコマンドを使います。

//wp-contentまで移動
cd /home/kusanagi/任意のプロファイル・ディレクトリ名/DocumentRoot/wp-content/
//wp-contentデイレクトリ内にuploadsディレクトリが存在しているか＆パーミッション状態確認
ls -al
//再帰的にuploadsデイレクトリ内全部を0755に変える
chmod -R 755 uploads

windows serverのIISやLinuxのubuntuでもユーザーやパーミッションの設定状態により同じ問題が起こる様です。

ubuntuは詳しくわかりませんが、IISの場合、windowsのGUI操作でコマンド無しで簡単にパーミッション設定を出来た記憶があります。

解決できない場合

ファイルの容量制限機能が働いている

画像の容量を増減しながらアップロードを試してみてください。

1KB（キロバイト）＝1024バイト
1MB（メガバイト）＝1024KB
1GB（ギガバイト）＝1024MB
1TB（テラバイト）＝1024GB

phpで画像の転送容量に制限がかかっている

php.iniファイルで調整します。

vimというコマンド画面内専用のエディタ（windowsのメモ帳の様なもの）で書き換えを行います。

やや難しいですが「vimコマンド　使い方」などで検索すると出てきます。

※php.iniファイルの変更後は、必ず再起動をしてください。

//php.iniファイルのあるディレクトリに移動
cd /etc
//php.iniを見る（確認コマンドです。書き換えてしまう事は無いので、思い切ってコマンドしてください）
cat php.ini
//php.iniファイルでファイル容量制限の数値を修正　vim立ち上げ
vi php.ini
//vimを開いたらノーマルモードから編集用のインサートモードに切り替える
i
//該当箇所を次のように修正、修正が終わったらESCを押してノーマルモードに戻る
memory_limit = 256M//メモリ使用量上限
post_max_size = 256M//POSTデータの最大アップロードサイズ
upload_max_filesize = 256M//1ファイルあたりの最大アップロードサイズ
//ノーマルモードにしたらvimをセーブして終了
:wq
//php-fpm KUSANAGI再起動
kusanagi restart
//php-fpm再起動（KUSANAGIではない場合、必要に応じて）
sudo service php-fpm restart//php5-fpmとphp7.0-fpmなどを使い分けてください。
//nginx再起動（KUSANAGIではない場合、必要に応じて）
sudo service nginx restart

レンタル共有サーバーの場合、php.iniファイルの設定はサーバーコントロールパネルなどの中から行う為、vimやコマンド操作の必要が無い場合もあります。

nginxでpostサイズ制限がかかっている

/etc/nginx/conf.d/default.confあたりでclient_max_body_sizeの数値を確認

※defaultの部分は、サーバー設定者によって自由に命名されている可能性があります。

//conf.dのディレクトリに移動
cd /etc/nginx/conf.d
//再帰的に該当ソースコードの有無と行数を拡張子.confのファイルだけ確認
grep -rn client_max_body_size *.conf

ご参考としてKUSANAGIのデフォルトは16メガバイトです。

client_max_body_sizeを含んだファイル名がdefault.confの場合

//vimを立ち上げファイルを編集する
vi default.conf
//書き方
example.conf: client_max_body_size 16M;
//vimで修正したらセーブして終了
:wq

上記の設定ファイルで数値の書き換えで対応します。

jetpackプラグインによるimgタグへのsrcset属性付与「画像を私たちのサーバーから提供」が開発環境でONになっている

OFFにしてください。srcset用のjetpackのキャッシュ的な機能は、Aレコードが正しく設定されていないと機能しません。開発環境では特に気を付けましょう。

その他原因

/wp-admin/includes/image.phpのファイルが壊れている

ファイルを修復しましょう。

image.phpファイルの容量がゼロになっていないか確認したり、同じバージョンのワードプレスを新たにダウンロードして壊れていないか見比べてみてください。

ソースコードの差分確認はwindowsの場合、WinMergeが使いやすくてお勧めです。

※diffコマンドなどでも確認出来ます。

php.iniファイルのセーフモード

offにする

セーフモードとは？

 

プログラムファイルの所有者が、プログラム内の関数によって処理されているファイル及びディレクトリの所有者と同一かの確認を行う設定をします。

⇒Xサーバーより引用

※php.iniファイルの変更後は、必ず再起動をしてください。

//php.iniファイルのあるディレクトリに移動
cd /etc
//php.iniを見る（確認コマンドです。書き換えてしまう事は無いので、思い切ってコマンドしてください）
cat php.ini
//php.iniファイルでファイル容量制限の数値を修正　vim立ち上げ
vi php.ini
//vimを開いたらノーマルモードから編集用のインサートモードに切り替える
i
//該当箇所を次のように修正、修正が終わったらESCを押してノーマルモードに戻る
safe_mode = Off
//ノーマルモードにしたらvimをセーブして終了
:wq
//php-fpm KUSANAGI再起動
kusanagi restart
//php-fpm再起動（KUSANAGIではない場合、必要に応じて）
sudo service php-fpm restart//php5-fpmとphp7.0-fpmなどを使い分けてください。
//nginx再起動（KUSANAGIではない場合、必要に応じて）
sudo service nginx restart

メディアの格納先パスの確認

コア（ワードプレス本体）のバージョンが3.4以下の場合、格納先パスの変更が出来るので/wp-content/uploadsに変更する

プラグインやテーマに原因がある

1つずつプラグインを無効化したり、テーマを変えてみてください。

VCCWデフォルトのプラグイン「Dynamic Hostname」が原因という事もある様です。

SELinuxを使っている

セキュリティ的に非推奨ですが、SELinuxをoffにする方法があります。

SELinuxを使われている場合、エンタープライズでセキュリティ対策の為にわざわざ利用している可能性もあると思います。

そのため、offではなく正しい方法を学習しないとまずい状況という可能性もあると思います。

SELinuxを導入した理由を知っている人にoffにしていいかどうか？確認することをお勧めします。

修正を外注する場合

ワードプレスでメディアのアップロードが出来ない場合、多くの原因が考えられます。

ワードプレス本体/テーマ/プラグイン/サーバー（apacheやnginx）/phpなど、多種多様です。

メディアのエラーメッセージは、ダッシュボードで「設定」⇒「一般」⇒「サイトの言語」で日本語と英語に変更できます。

「表示される英語のエラーメッセージ」と「どこまで自分で検証したのか」を正しく専門業者に伝える事で解決までの時間が速くなります。

シンプルに試してみるべきこと

別種類ブラウザのシークレットウィンドウを使ってメディアにアップロードしてみてください。