Toshimichi Mimoto

拝見したところ WPtouch Mobile Plugin を使用されていると見受けられます。

管理画面（当方、WPtouch 3.8.2 で確認）で

1. WPtouch
2. コア設定
3. ランディングページ WPtouch待ち受けページ:

を確認するとどうなっていますか？

「Default (same as desktop visitors)」が選択されていればデスクトップと同じトップページが表示されると思いますがいかがでしょうか。

スクリプトが実行されるときに対象となる要素、今回の場合はsliderのクラスを付与させた要素が読み込み済みでないとスクリプトは正常に動きません。

<script type="text/javascript">
 jQuery('.slider').glide();
</script>

は、head内ではなく、</body>の前に記述する必要があります。

解決したのであればよかったです。

これで行けました！wp-redirectで同じことを試したのですが、その時はpostが弾かれてダメだったのかもしれませんが、 wp_safe_redirectは大丈夫でした。初めて知った関数でした。

postが弾かれる、というのは formのaction属性でwp-login.phpが指定されているので、フォームに入力された情報を送るときにリダイレクトされてしまいログインが出来ないのでは… というつもりでした。
wp_redirectとwp_safe_redirectで今回の件について挙動の差異が発生する原因はわからないので何か悶々とします ^^;

Twenty Fifteen テーマの子テーマ使用で、子テーマのfunctions.phpに下記コードを加えて検証してみました。

add_action( 'login_init', function() {
	/**
	 * $_POST の内容で条件分岐をしない
	 * wp_redirect
	 */
	wp_redirect( home_url() );
} );

add_action( 'get_sidebar', function() {
	if ( ! is_user_logged_in() ) {
		// 以下、ご質問内容にあるコード
	?>
<form method="post" action="<?php echo wp_login_url() ?>?redirect_to=<?php echo esc_attr($_SERVER['REQUEST_URI']) ?>">
	<label for="login_username">ユーザー名：</label>
		<input type="text" name="log" id="login_username" value="" />
	<label for="login_password">パスワード：</label>
	<input type="password" name="pwd" id="login_password" value="" />
	<input id="user_submit" type="submit" value="ログイン" />
</form>
	<?php
	}
} );

上記でおそらく思惑通りの動きをしたんですよね…
どこか別のところに問題があったのかもしれませんね。

やっと検証しましたが問題はないようです。
ただし体裁はひどいものです。

一応下記でそれなりにはなります。

function eg_setting_callback_function() {
	$vals = get_option( 'eg_setting_name', array() );
	$checked = isset( $vals['cb'] ) && $vals['cb'] ? 'checked="checked"' : '';
	$textVal = isset( $vals['text'] ) ? $vals['text'] : '';
	echo '<input name="eg_setting_name[cb]" id="gv_thumbnails_insert_into_excerpt" type="checkbox" value="1" class="code" ' . $checked . ' /> Explanation text';
	echo '</td></tr><tr><th>Text</th><td>'; // add
	echo '<input name="eg_setting_name[text]" id="gv_thumbnails_insert_into_something" type="text" value="' . esc_attr( $textVal ) . '" />';
}

…かなりブサイクなコードですが – -;

ちなみに、Settings APIでは add_settings_sectionとdo_settings_sectionsはすっ飛ばしてpage直下にfieldを展開することもできます。
Codexのように既存のsectionに追加する場合は（多分）上記のような手法をとることになると思いますが、add_menu_pageやadd_submenu_page（などそれに類する関数）から設定ページを構築する場合はそちらのほうが良いかもしれませんね。

以上あしからず

あっ、すみません。Code 間違えてますね。

function eg_setting_callback_function() {
	$vals = get_option( 'eg_setting_name', array() );
	$checked = isset( $vals['cb'] ) && $vals['cb'] ? 'checked="checked"' : ''; // fix
	$textVal = isset( $vals['text'] ) ? $vals['text'] : ''; // fix
	echo '<input name="eg_setting_name[cb]" id="gv_thumbnails_insert_into_excerpt" type="checkbox" value="1" class="code" ' . $checked . ' /> Explanation text';
	echo '<input name="eg_setting_name[text]" id="gv_thumbnails_insert_into_something" type="text" value="' . esc_attr( $textVal ) . '" />';
 }

(コメント箇所以外もどさくさに紛れていくつか直してます ^_^;)

ちなみにmaybe_unserialize、およびmaybe_serializeは、この場合、それぞれget_option、update_option内で適用されているので考慮しなくても大丈夫だと思います。

htaccessで制限するのではなくlogin_init アクションでなんとかしてみるのはどうでしょう。

add_action( 'login_init', function() {
    wp_safe_redirect( home_url() );
} );

で試してみたらちゃんと弾いてくれました。

—

追記)

あ、この場合でもそのままだとformからのpostを弾いてしまいますよね。。でも、htaccessよりはいろいろ条件を分岐させて柔軟に対処できそうな気がします。

例えば、

add_action( 'login_init', function() {
    $log = filter_input( INPUT_POST, 'log' );
    $pwd = filter_input( INPUT_POST, 'pwd' );
    if ( ! $log || ! $pwd )
        wp_safe_redirect( home_url() );
} );

というような感じですかね。