top of page

WordPressマルチサイトでのUpload/URL Path問題


  1. WordPress 4.7.2

  2. マルチサイト

  3. 3.5以前から運用

  4. 2017-02現在

はじめに

  1. https://codex.wordpress.org/Multisite_Network_Administration#Uploaded_File_Path

Regardless of WP version, these locations cannot be changed by site admins. Only the network admin can make changes on the site settings page.

(WPのバージョンにかかわらず、これらの場所(注:PATHとURL)はサイト管理者が変更することはできない。ネットワーク管理者は管理画面から変更が可能である)

しかし’Upload path’と’Upload Url path’は無効でありかつ/または自動的に変更されています。これはなぜで、何が起きているのでしょうか?

要素

  1. WPを3.5にアップデートする際、ms_files_rewritingが作成されませんでした。

  2. ms_files_rewriting

  3. この値が “1” の場合、管理画面で設定した値は無効となります。

  4. db_version と wp-includes/upgrade.php

  5. db_versionが “21823” 以下の場合、”1″ が設定されます(wp-includes/upgrade.phpによる)。

  6. WPのアップデートはしていたのですが、db_versionは更新されていませんでした。この問題には他の条件やパターンが影響している模様です。

  7. wp-includes/ms-default-contstants.php

  8. ms_files_rewritingが*_optionsor*_sitemetaテーブルに存在しない場合、”1″ が設定されます。

  9. ms_files_rewritingはアップロード関連の定数を設定するのに使用されます。 例)UPLOADBLOGSDIR、UPLOADS、BLOGUPLOADDIR

  10. wp-includes/functions.php

  11. アップロードPATHやURLを設定するのにms_files_rewritingが使用されます。

  12. upload_path

  13. アップロード先を指定する変数です。

  14. 3.5で廃止されています。

条件とパターン

条件とパターンが結構存在する模様です。 (間違っていたらすみません)



ありうる選択肢

  1. パターン#1: オリジナルのまま使用する

  2. やるべきこと:

  3. 無し

  4. 結果:

  5. アップロード先 = ‘wp-content/blogs.dir/(blog_id)/files’

  6. URL = (site url) +’/(blog name)/files’

  7. 注意事項:

  8. ‘Upload path’、’Upload Url path’は無効になります。

  9. パターン#2: 管理画面の値を使用する

  10. やるべきこと:

  11. *_optionsテーブルにms_files_rewritingを追加しoption_valueを “0” に設定

  12. db_versionを最新版に設定

  13. 結果:

  14. アップロード先 = ‘Upload path’ + ‘sites/(blog_id)’

  15. URL = ‘Upload Url path’ + ‘sites/(blog_id)’

  16. 注意事項:

  17. ‘Upload path’、’Upload Url path’は使用されますが、文字列が追加されます

  18. パターン#3: 定数UPLOADSを使用する

  19. やるべきこと:

  20. *_optionsテーブルにms_files_rewritingを追加しoption_valueを “0” に設定

  21. db_versionを最新版に設定

  22. 定数UPLOADSを設定

  23. 結果:

  24. アップロード先 = UPLOADS + ‘sites/(blog_id)’

  25. URL = (site url) + UPLOADS + ‘sites/(blog_id)’

  26. 注意事項:

  27. ‘Upload path’、’Upload Url path’は無効になります。

Q. なぜ定数UPLOADBLOGSDIRを使用しないのですか? A. ms_files_rewritingが “0” に設定されている場合は無視されるためです。

各パターンの問題

パターン#1にある既存の問題

  1. このパターンはレガシーで複雑な互換性を残すことになります。 これは運用を続ける場合には危険要素となりそうです。

パターン#2で発生しうる問題

  1. ‘Upload path’、 ‘Upload Url path’が将来廃止される可能性が無いとは言い切れません。非マルチサイトでは既に廃止されているためです。

パターン#3によって生じる問題

  1. (site url)が “/foo/”、(blog_id) が “2”、UPLOADS が “bar” と設定されている場合に、URLは “/foo/bar/sites/2/YYYY/MM/*” となるはずです。 しかし既存の記事内のURLは “/foo/files/YYYY/MM/*” となっているはずです。

結論

  1. 将来的なトラブルを回避する方が良いので、パターン#3を選択しました。

  2. 既存の画像ファイルは全て “/foo/files/*” から “/foo/bar/sites/2/*” にコピーしなければなりません。

  3. 既存の記事内のURLについては、RewriteRuleで解決することにしました。

  4. 例) RewriteRule ^/foo/files(.*?)$ /foo/bar/sites/2$1 [R=301,L]

  5. または wp-cli を使うことになるかと思います。

最新記事

すべて表示

SQLite(sqlite3)で “no such table”

小ネタです。 SQLiteを使っていて "no such table" とエラーが出た場合、 DBファイル名の指定が空になっている、という凡ミスを起こしていないかを確認してみましょう。 ・・・ そういう凡ミスをしてしばし悩んだので… ファイル名の指定が空になっている場合、一時的なインメモリDBとして保存されます(※1)。 つまりDB接続を切断すると中身は消えます。 なので接続

アプリケーションサーバにポートを指定せずに起動すると?

最近、 Goで書かれたアプリケーションサーバが起動しない! ->原因: .env ファイルが欠けていた というドタバタがありました。 結局Goと関係ないですが、この時、 「あまりGoに慣れてないのでGoの問題かと…」「DockerまだよくわかってなくてDockerの問題かと…」 というような声があったのて、あえてGoで検証してみようと思ったわけです。 さて、Goでサーバサイドのシステムを作

GitLab 9.1.2 (MySQL) を 11.4.0 (PostgreSQL) にアップグレード

弊社ではかなり前からGitLab(CE)を自社環境で運用しているのですが、ふと気付くと、バージョンがだいぶ先に行ってしまっていました。 とくに最近のバージョンでは Auto DevOps なども使えるようになっていたりするので、さすがにそろそろキャッチアップしたいと考えたわけです。 現行の環境は次の通りです: GitLab 9.1.2 sameersbn/gitlab 使用 MySQL 5.6

bottom of page