wp_upload_bits

説明

array wp_upload_bits( string $name, null $deprecated, mixed $bits [ , string $time = null ] )
データをアップロードファイルとして保存する。

パラメータ

  • $name
    ファイル名を指定。
  • $deprecated
    必ずnullを指定。
  • $bits
    保存するデータを指定。
  • $time
    保存先のサブディレクトリ(yyyy/mm)を指定(省略時はnull)。

返り値

アップロード結果を格納した連想配列を返す。正しく保存できた場合はキー'error'の値にfalseが、保存に失敗した場合はその理由のテキストが格納され、キー'file'や'url'の値は存在しない。
キー内容
'file'アップロードファイルのフルパス名
'url'アップロードファイルのURL
'error'エラー内容(保存できた場合はfalse)

注意

この関数はあくまでもデータをアップロード先ディレクトリに保存するだけで、メディア(attachment)として登録されるわけではない。

アップロード先に同名のファイルが存在する場合は、ファイル名の拡張子前に数字を追加して重複しないようになるため、保存されるファイル名はパラメータ$nameと異なる場合がある。例えば、パラメータ$nameに'a.txt'が指定され、保存先のディレクトリに同名のファイルが存在する場合は、'a1.txt'、a2.txt'、a3.txt'の順にファイルが存在するか調べ、存在しなかった名前が最終的なファイル名となる。

アップロードしたファイルのステータスは、アップロード先ディレクトリのステータスに依存する。


使用例

  • データ$dataをファイル名'log20141127_123456.txt'で保存する。
    <?php
    $upload = wp_upload_bits( 'log20141127_123456.txt', null, $data );
    if ( empty( $upload['error'] ) ) {
    	// アップロード成功時の処理
    }
    ?>
  • データ$dataを2014年9月のディレクトリにファイル名'log20141127_123456.txt'で保存する。
    <?php $upload = wp_upload_bits( 'log20141127_123456.txt', null, $data, '2014/09' ); ?>

フィルター

[3.0.0]アップロード先ディレクトリを確認した後に'wp_upload_bits'フィルターを呼び出す。パラメータ$argsは本関数が受け取った$name$bits$timeが格納された連想配列となる。
$upload_bits_error = apply_filters( 'wp_upload_bits', $args );

アクション

実行するアクションはありません。

ソースファイル

/wp-includes/functions.php

最終更新 : 2018年05月27日 10:46



お勧め

投稿ページでユニークなテンプレートを選択しよう(2018年5月27日 更新)

4.7の変更点に「投稿タイプテンプレート」がある。これは従来固定ページ('page')向けに任意のテンプレートを適用できる機能が拡張されたもので、投稿ページ('post')はもちろんカスタム投稿タイプのページにも適用可能になっている。

ブロックエディターの色設定を変えてみる(2019年12月11日 更新)

バージョン5.3で機能強化されたブロックエディター。対応を考えて新テーマ「Twenty Twenty」のソースコードを眺めていく。

5.3の新機能:日付とタイムゾーン(2019年10月2日 更新)

WordPress 5.3 Beta 1」に記載されていた「Time/Date component fixes」という見出し。開発者向として新しい関数の追加や多くのバグが修正されたとなっており、チェックせざるを得ない。

ショートコードを含んだページを表示する前に何か処理する(2014年5月28日 更新)

固定ページまたは投稿ページに独自のフォームを埋め込む。入力→登録の2段階のフォームなら著名なプラグイン「Contact Form 7」を利用すればいいのだが、クライアントの依頼は入力→確認→登録の3段階で組み込む要素が特化していたので、独自の実装方法を考えることになった。

Emojin:プラグイン作ってみました(2015年3月21日 更新)

ちょっと前のTLでiOSの絵文字を含んだ投稿を保存すると、絵文字以降の文章がすべて消えた状態で保存されるといったツイートを見かけた。少し検索してみると、MySQLのデータベースの文字セットが「utf8」の場合、iOSの絵文字のような4バイトの文字を正常に保存できず、それ以降の文章も保存されないというものらしい。対処方法としてデータベースの文字セットを「utf8mb4」に変更するのが有効らしいのだが、他に回避策がないか考えてみた。