kjmtsh

1 と 2 は、ちょっと違う機構です。

1 は、WordPress の仕様であって、何も手を加えていなければ、全てのインストールで同じ状態になるはずです。

WordPress は、siteurl、home というオプションデータを持っていて、prefix_options というデータベース・テーブルにその値を保存しています。テンプレート・タグの site_url() や home_url() を使うと、内部で get_option(‘siteurl’) や get_option(‘home’) を呼び出して、テーブルからデータを読み込みます。この URL は、保存するときに必ず最後のスラッシュを削除した形に整形されます。ですから、設定->一般で、スラッシュを追加しても変更することはできません。

Apache などの DocumentRoot の指定方法にならっているような感じですね。ルートはスラッシュなし、それより後は、GET 要求でつけるパスと同じように扱えということではないかな。ルートへの要求は GET / HTTP/1.0 だから。

保存されたデータは、しかるべき関数を使えば、変更することもできますが、お勧めはしません。WordPress 内部でも、プラグインやテーマでもさまざまに使われているからです。まあ、二重スラッシュが飛び交うだけといえば、そうなのですが… 気持ち悪いですよね。

テンプレート・タグは、オプションの引数を受け取ることができて、指定の仕方によって、下のような違いがあります。

site_url()                 => http://example.com/wp
site_url('/')              => http://example.com/wp/
site_url('/somepage/')     => http://example.com/wp/somepage/
site_url('anotherpage/')   => http://example.com/wp/anotherpage/
site_url('yetanotherpage') => http://example.com/wp/yetanotherpage

こういう仕様なわけです。これが WordPress のあちこちで使われています。

2 の方は、サーバ設定によって、振る舞いが変わることがありますが、通常は以下のようになります。

ブラウザから http://example.com/wp へ GET 要求を出すと、wp というディレクトリがある場合、サーバは、http://example.com/wp/ へのリダイレクトを送信します。Apache、Nginx ともにこれがデフォルトの振る舞いのはずです。そして、http://example.com/wp/index.php があれば、PHP (または、php モジュール) が実行されて、WordPress が動き出します。ということは、この場合、最後のスラッシュをつけているのは、Apache や Nginx であって、WordPress がつけてるわけじゃありません。

どうしてもこの動作を変更したいとうことなら、止めはしませんが、お勧めもしません。Apache なら、mod_dir を、Nginx なら、設定ファイルの server セクションの記述を調べてみてください。うまくいかない場合は、Apache または Nginx のフォーラムかメーリングリストでお願いします。

さて、お使いのプラグインですが、http://example.com/wp/ を送信するのが本当は正しいやり方だと思います。サーバのリダイレクトとブラウザとのやり取りは一瞬で終わるので、どうということはないですが (ディレクトリには必ずスラッシュをつけろ、と昔は言われましたけど)、サーバに余計な仕事をさせないことは確かだからです。WordPress は仕様どおり動いているので、まったく問題ありません。

はい、その通りです。テーマディレクトリにある、functions.php に記述してください。

全てfunctions.phpからページ毎に枝分かれさせて行う方法がWPでは一般的なのでしょうか。

あまり一般的ではないと思います。最後の手段として、仕方なしにやっているという感じでしょうか。プラグイン作者たちは、Ajax を使うことが多いような気がします。

入力チェックは、Ajax を使うか、JavaScript だけを使って、画面遷移せずにユーザに注意を促すのがわかりやすいと思います。仕様として、JavaScript が使えないということなら、どうしようもありませんが… リダイレクトすると、1項目だけの不備でも、全て再入力となって、ちょっとイラっとされちゃうかもです。

リダイレクトについては、template_redirect というのがあります。WordPress の全てのオブジェクトがインスタンス化されていて、かつ、サーバにはまだ何も送られていない段階のフックなので、いわば、リダイレクトの last resort です。wp_safe_redirect を使っても動作します。

add_action('template_redirect', 'my_redirect_callback');
function my_redirect_callback() {
    if (!is_user_logged_in() &&
        is_page(195) &&
        !isset($_POST['textfield1']) &&
        etc...) {
        wp_redirect(home_url('/login/'));
        exit();
    }
}

ついでですが、wp_nonce_field くらいは使った方がいいと思います。

FFFTP は現状、エラーが多すぎてまともに使えません。開発者たちには申し訳ありませんが、FFFTP を捨てて、FileZilla を使うのが Windows ではベストな選択です。

おっと、そうでしたね。お示しの関数を利用して書き換えるようにしましょうか。ちょっと効率悪いかもしれませんが、試してみてください。久しぶりに PHP を触ったので、ミスがあるかも。

テンプレートの function.php。

/**
 * 最後から N 番目の投稿ならば true を返す。第2引数に false を渡すと、
 * 最初から N 番目の投稿が true になる。
 *
 * 引数は N を整数で指定する。指定がない場合は何もしないが、判定は実行される。
 * 文字列引数を渡した場合は、強制的に符号なし整数に変換する。
 * ループの中で使われていない場合は、false を返して抜ける。
 *
 * @parameter unsigned integer: if string given, force it to uint
 * @access global
 * @return value boolean
 */
function is_last_nth($nth = 0, $from_the_last = true) {
    global $wp_query;
    $last_nth = sprintf("%u", $nth);
    if ($wp_query->in_the_loop) {
        if ($from_the_last) {
            return ($wp_query->current_post + 1 > $wp_query->post_count - $last_nth);
        } else {
            return ($wp_query->current_post < $last_nth);
        }
    }
    return false;
}

テンプレート。

if ( have_posts() ) :
    while ( have_posts() ) : the_post();
        if ( is_last_nth(3, false) ) :
            ここで最初から3つの投稿を処理する
        elseif ( is_last_nth(3) ) :
            ここで最後から3つの投稿を処理する
        else;
            ここでその他の投稿を処理する
        endif;
    endwhile;
endif;

Custom fields search をちょっと覗いてみましたが、WordPress の API を使わず、直接 $wp_query に変更を加えています。実際の出力を見ないとわからないところがあるので、search.php の冒頭に下記のコードを加えて、その出力を投稿していただけますか? 何かわかるかもしれません。

global $wp_query;
echo $wp_query->request;

なお、pre_get_posts にフックした関数で使われる return は、そこで関数の実行を止めて、制御を呼び出し元に戻す、という意味しかありません。ですから、この場合、最初の return には意味がありますが、二つ目の return は、関数の最後なので、あってもなくても動作に変化がないのが正常動作です。

どこに何を表示しているか、あるいは、前後とループの中はどうなっているか、具体的なコードがないとフォローが難しいです。たぶん、get_posts では代替できないのではないか、くらいはわかりますが…

失礼を承知で書きますが、お示しの方法はちょっと危ないので、設計を見直された方がいいと思います。「訪問者」ということですので、ユーザ登録をした人だけに表示される内容ではないようですし。危険な部分は、たとえば、次のようなところです。

1. form に何の制限もないため、何度でも、何でも送信できる。
2. その気になれば、別のサーバからも投稿できる。
3. $_POST で送られてきた内容を生のまま SQL 文に使っているので、自由に書き換えることができる。

このままだと、SQL インジェクションし放題、スパム送り放題になってしまうのではないかと心配になります。余計なお世話だったら、申し訳ありませんが…

さて、それとは別に、なぜ locate_template() が動かないかですが、form から呼び出された db_input1.php は WordPress の情報を一切引き継がないので、WordPress の定数、変数、関数すべて使うことができません。これら、WordPress のオブジェクトの多くはグローバルな空間に存在しますが、db_input1.php は、それとは別のプロセス、空間で動作します。デバッグモードで試すと、undefined function と言われるはずです。

WordPress の機能を使いたいという場合は、db_input1.php の冒頭で、

require_once('absolute-path-to/wp-config.php');

みたいなことをすれば、可能です。admin-ajax.php を紹介するブログ記事では、この手を使うことが多いようです。お勧めはしません。

単に、db_input1.php の中で、auto-upload.php を呼びたい場合は、同じディレクトリにあるなら、

require_once(dirname(__FILE__) . '/auto-upload.php');

のような、PHP が持っている関数や定数を使う、または、絶対パスを使えばお望みのことができます。なお、ここでも、本当は、グローバルな関数に処理をさせるよりは、外部から直接実行できないようにカプセル化し、WordPress に備え付けの Ajax を使った方が安全ですし、何より、WordPress のオブジェクトを使うことができます。

ただ、ちょっと残念なのは、WordPress の Ajax は基本的に、ダッシュボードで使うように設計されているのを、フロントエンドでも使えるようにしましたという感じなのと、Codex の記述がいまいちで、外部リンクに丸投げしてるところです。一応、参考まで: AJAX in Plugins

あ、それから、mysql_* は、非推奨なので、mysqli ライブラリを使うほうが長く使えると思います。