CMS関連

WordPressのマルチサイトで参加サイトが表示されない

マルチサイト化されているWordpressのサーバーを移転したところ、参加サイトが表示されなくなってしまいました。

↓この部分

もちろんログインしたアカウントはすべてのサイトに所属しています。

プラグインのせいかと思って全部切ってみたのですが、治らず。

移転時にバージョンアップしたからかとも思いましたが、他のサイトで使っている同じバージョンのWordpressでは、こんな問題は起きたことがありません。

移転中だったのでベーシック認証をかけていたのですが、まさかこれじゃないだろうと思いながらも試しに解除してみたら、表示されるようになりました!

原因はベーシック認証!

こんなことあるのか・・・

ちなみに、一度表示されるようになったら、以降は再びベーシック認証をかけてもちゃんと表示されます。

総合管理者 | 2017年03月08日 | コメント(0) | トラックバック(0) | CMS関連

WordPressのバージョン4.7と4.7.1はヤバイ

ちょっと古い情報ですが、Wordpressのバージョン4.7と4.7.1はかなりヤバイ脆弱性があるそうです。

WordPress の脆弱性対策について:IPA 独立行政法人 情報処理推進機構

WordPress 4.7, 4.7.1 はAPIに致命的なバグがあって認証無しで誰でも記事を改ざんできちゃうっぽい! - かもメモ

上記のサイトに方法が記載されておりますが、簡単に改ざんできてしまうとのこと。

簡単過ぎる!怖い!

4.7から4.7.1へのアップデートは、PHPMailerの件ですぐにアップデートされることは予想しておりましたが、またすぐに4.7.2へのアップデートでしたので、何事?と思っておりましたが、これはかなりやばい脆弱性ですね。

すぐにアップデートするのは考えものですね・・・

ちなみに、Search Consoleでもこのような警告が出てしまう始末

貴サイトが WordPress の古いバージョンである WordPress 4.7.0 or 4.7.1 を実行していることが判明しました。古いバージョンやパッチを適用していないソフトウェアは、ハッキングやマルウェアの攻撃を受けやすくなり、貴サイトの訪問者に被害が及ぶことがあります。そのため、サイト上のソフトウェアをできるだけ早く更新することをおすすめします。

おすすめどころではない、必須事項でしょ。

自分のブログも一瞬だけ4.7.1にしておりましたが、すぐさま4.7.2にアップデートしました。

総合管理者 | 2017年02月14日 | コメント(0) | トラックバック(0) | CMS関連

【WordPress】スラッグ名が重複すると、公開中の投稿ページが404になる

※これは、現在最新バージョンである4.7.1で確認しています。

 

WordPressの管理画面にログインし、以下の手順で記事を作成してみてください。

①新規投稿で、スラッグ名をhogeと設定し、公開保存する。
②再び新規投稿で、スラッグ名をhogeと設定し、下書き保存する。(実際はhoge-2に変わりますが気にせずに)

※①と②の記事は別の記事です。
※スラッグ名は手動で設定してください。

①の投稿ページを、別のブラウザか、Wordpressからログアウトして開いてみてください。
公開しているにも関わらず、エラー404ページになってしまいます。
(pre_get_postsなどで、投稿詳細ページの取得ルールを変えている場合は起こらない可能性があります)

 

原因

②の投稿を作成する際、スラッグ名を「hoge」と入力すると、重複を回避するため「hoge-2」と表示されるのですが、実際は下書き保存では「-2」はつかず、そのまま「hoge」と保存されてしまいます。(データベースを確認すると、postnameがhogeとなっているレコードが2つ確認できます)

そのため、①のページを開こうとした際、②の投稿データを取得してしまい、しかし下書きのため404ページとなってしまうわけです。

ちなみに投稿詳細ページでのデータ取得の順番は公開日時順になっているらしく、②の下書き投稿が①の公開投稿よりも過去の公開日時に設定していると、①の投稿ページは正常に表示されます。

この現象が発生する条件は正確には以下となります。

  • スラッグ名を設定することができるパーマリンク設定になっていること
    (%postname%が含まれる設定の場合)
  • 投稿タイプが「投稿」であること
    (固定ページではこの現象は起きない)
  • 投稿の作成・編集時にスラッグ名を任意に設定すること
    (WPがタイトルから自動的に生成する場合は、重複してもこの現象は起きない)
  • 設定したスラッグ名に自動的に連番がつくこと
    (すでに公開されている投稿記事が存在している場合)
  • 保存時に下書き保存すること
    (公開保存なら大丈夫)
  • 下書き保存した投稿記事と同じURLの公開中の記事が存在すること
    (連番なしのURLと完全一致する公開中の投稿記事があること。日付やカテゴリーがパーマリンクに含まれる場合で、これらが異なる場合はこの現象は起きない)
  • 公開保存されている投稿より、下書き保存した投稿の方が、公開日時が未来に設定されていること

という条件なので、投稿でも命名規則を決めてスラッグ名をきっちり設定するという運用を行っている(例えばニュースなら「news20160120」と設定する)サイトの場合以外は起きないので、なかなか見つかりづらい不具合ではあると思われます。

 

対策

ひとまず404エラーを回避する方法ですが、functions.phpに以下を追記すると、回避できます。

add_action('pre_get_posts', 'custom_pre_get_posts' );
function custom_pre_get_posts($query){
if ( is_admin() || ! $query->is_main_query() ){
return;
}
if($query->is_single && !$query->is_preview){
$query->set( 'post_status' , 'publish');
}
}

要するに、公開されているものを開けばよいのですが、なぜ下書きのものを取得しようとしてしまうのか、不思議です・・・

なお、この方法で404エラーは回避できますが、もう1つ問題があります。

該当の公開中の記事を編集すると、こっちは重複を回避しようとしてスラッグ名の後ろに「-2」がついて保存されてしまうことです。(なんでやねん)

スラッグ名が変わっても、一応リダイレクトしてくれるみたいですが、下書きの方の記事が「hoge」で公開保存されたら、完全に入れ替わっちゃいます。

結局気を付けるしかないのが現状ですね・・・

 

冒頭でも書いていますが、これはバージョン4.7.1で起こっています。

もしかしたらこれより古いバージョンでは起きないかもしれません。

また、さらにバージョンアップされたら起きなくなるかもしれません(というか起きなくなってくれ)

総合管理者 | 2017年01月20日 | コメント(0) | トラックバック(0) | CMS関連

投稿一覧の各投稿のメニューをカスタマイズする方法

フック!フック!フック!

フックは便利ですね!

ということで、テーマで投稿一覧の各投稿のメニューをカスタマイズする方法のメモです。

下図のように、メニューに「サンプル」を追加する場合

WS002447

テーマのfunctions.phpに以下を追記します。


function custom_post_row_actions($actions, $post) {
//$actions['(キー)'] = '<a href="(リンク先)" title="">(ラベル)</a>';
$actions['sample'] = '<a href="/sample.php" title="">サンプル</a>';
return $actions;
}

add_filter('post_row_actions', 'custom_post_row_actions',10,2);

 

いらないものを消す場合は、unsetします。(以下クイック編集を削除する)


function custom_post_row_actions($actions, $post) {
unset($actions['inline hide-if-no-js']);    //クイック編集
return $actions;
}

add_filter('post_row_actions', 'custom_post_row_actions',10,2);

以下デフォルトのメニューです。

$actions['edit'] 編集
$actions['inline hide-if-no-js'] クイック編集
$actions['trash'] ゴミ箱
$actions['view'] 表示

 

参考サイト

投稿一覧に独自リンクを追加する:WordPress私的マニュアル

総合管理者 | 2016年03月25日 | コメント(0) | トラックバック(0) | CMS関連

Search Console(ウェブマスターツール)でインデックス数が激減

このサイトのURLを

http://www.nandani.sakura.ne.jp/

から

http://nandani.sakura.ne.jp/

に変更しました。(wwwなし)

理由はwwwあり・なし両方でアクセスできるとSEO的に良くないのが1点(いまさら)

もう1つは、さくらインターネットのサブドメイン(○○○.sakura.ne.jp)でSSLが使えるのが、www無しのみだったので、http://nandani.sakura.ne.jp/をメインURLとしました。(httpsの方がSEO的に良いらしいので。さくらインターネット特有のくせで、記事ページにhttpsでアクセスするとおかしくなるため、まだ変えてませんが。)

そうしてみたところ、Search Consoleのインデックス数が激減。

まあ当たり前です。

これまでは「http://www.nandani.sakura.ne.jp/」で登録されていたのに、wwwなしになったわけですから。

しばらくしたら治るだろうと思っていたのですが、一向に増える気配はなく、何ならどんどん減っていきます。

ただでさえ減ってたのに!

なんで?と思い、よくよくSearch Consoleに送っているsitemap.xmlを見てみたら、そこに記述されているURLが「http://www.nandani.sakura.ne.jp/」になっているではありませんか。

サイトマップ書き出しには「Google XML Sitemaps」を使っているのですが、どうやらキャッシュっぽい感じで残っており、それが送信されてたらしい。

通りで全然インデックスされないわけだ。

ということで、設定>XML-Sitemapから設定を更新したら、無事「http://www.nandani.sakura.ne.jp/」で出力されるようになりました。

 

インデックスが減っていたとはいえ、あんまりアクセス数は変わってないんですよね。

メインの流入はGoogleからのはずなんだけどなぁ。

総合管理者 | 2016年01月20日 | コメント(0) | トラックバック(0) | CMS関連 | PHP関連 | SEO関連

EC-CUBEでクレジットカード決済が表示されない

EC-CUBEで「イプシロン決済モジュール」を導入し、設定も一通り完了したのですが、なぜか商品購入フローの「お支払方法・お届け時間等の指定」で「クレジットカード決済」の選択が表示されないという現象になってしまいました。

イプシロン側の設定も、EC-CUBE側のイプシロンモジュールの設定も問題なく見えます。

基本情報管理>支払方法設定にも、ちゃんと「クレジットカード決済」は追加されています。

なぜ登録されない・・・と「LC_Page_Shopping_Payment.php」の中身を調べてみたところ

if (in_array($payment['payment_id'], $payments_deliv)) {

というところではじかれている様子。

deliv・・・ということはと、基本情報管理>配送方法設定を調べたところ、「取扱支払方法」の設定で「クレジットカード決済」にチェックが入っていませんでした。

WS002223

凡ミス・・・

総合管理者 | 2016年01月19日 | コメント(0) | トラックバック(0) | CMS関連

EC-CUBEテンプレート用タグ

メモ。

随時更新中・・・

パス用タグ

  • <!--{$smarty.const.ROOT_URLPATH}-->
    EC-CUBEで設定したウェブルートのURLパス。
    ドメイン:無し
    出力例:/
  • <!--{$smarty.const.TOP_URL}-->
    EC-CUBEで設定したトップページのURLパス。
    ドメイン:あり
    出力例:http://nandani.sakura.ne.jp/
  • <!--{$smarty.const.CART_URL}-->
    カートへのURLパス。
    ドメイン:あり
    出力例:http://nandani.sakura.ne.jp/cart/
  • <!--{$smarty.const.P_DETAIL_URLPATH}-->
    商品詳細ページへのベースURLパス。
    ドメイン:無し
    実際に商品ページへ行くには後ろに商品IDを付ける必要あり。
    例:<!--{$smarty.const.P_DETAIL_URLPATH}--><!--{$arrProduct.product_id|u}-->
    出力例:/products/detail.php?product_id=1
  • <!--{$smarty.const.IMAGE_SAVE_URLPATH}-->
    アップロードした画像のフォルダへのURLパス。
    ドメイン:なし
    出力例:/upload/save_image/
  • <!--{$TPL_URLPATH}-->
    テンプレートへのURLパス。
    ドメイン:無し
    出力例:/user_data/packages/default/

 

総合管理者 | 2015年12月17日 | コメント(0) | トラックバック(0) | CMS関連

商品ページの変数【EC-CUBE】

かなり雑にメモ。

EC-CUBEの商品ページ用のテンプレートで、商品情報が入っている「$arrProduct」の中身は、以下のキーで取得できます。

■product_id
■name
■maker_id
■status
■comment1
■comment2
■comment3
■comment4
■comment5
■comment6
■note
■main_list_comment
■main_list_image
■main_comment
■main_image
■main_large_image
■sub_title1
■sub_comment1
■sub_image1
■sub_large_image1
■sub_title2
■sub_comment2
■sub_image2
■sub_large_image2
■sub_title3
■sub_comment3
■sub_image3
■sub_large_image3
■sub_title4
■sub_comment4
■sub_image4
■sub_large_image4
■sub_title5
■sub_comment5
■sub_image5
■sub_large_image5
■sub_title6
■sub_comment6
■sub_image6
■sub_large_image6
■del_flg
■creator_id
■create_date
■update_date
■deliv_date_id
■plg_giftpaper_noshi
■product_code_min
■product_code_max
■price01_min
■price01_max
■price02_min
■price02_max
■stock_min
■stock_max
■stock_unlimited_min
■stock_unlimited_max
■point_rate
■deliv_fee
■maker_name
■price01_min_inctax
■price01_max_inctax
■price02_min_inctax
■price02_max_inctax

取得例:商品IDを取得する場合

<!--{$arrProduct.product_id}-->

総合管理者 | 2015年12月11日 | コメント(0) | トラックバック(0) | CMS関連 | PHP関連

WordPressの見落としがちな設定(ゴミ箱)

お客様から、記事が勝手に消えてしまったという連絡を受けました。

話をよく聞いてみると、とりあえず非公開にしたいからゴミ箱に移動させていたとのこと。

いや、そういう時はステータスを「下書き」にするか、公開状態を「非公開」にしてほしいのですが・・・

うっかり「完全に削除する」をクリックしてしまったのではないかと思ったのですが、よくよく調べてみると、Wordpressではゴミ箱に移動した記事は、30日経つと自動的に消えてしまうそうな。

これは知らなかった。

ちなみに、wp-config.phpに

define('EMPTY_TRASH_DAYS', 日数);

と追記することで、保存期間は設定できるらしい。

WordPressでゴミ箱から復元する方法と保存期間を変更する方法 | WordPress奮闘記

とりあえずゴミ箱には、消えても良い記事だけを入れましょう。

総合管理者 | 2015年10月17日 | コメント(0) | トラックバック(0) | CMS関連

bloginfoが非推奨?【WordPress】

今更ながら、bloginfoで一部パラメータの使用が非推奨になっているのに教えてもらって気付きました。

ただ、全部がアウトというわけではなく、Codexを見る限り非推奨になっているパラメータは

  • 'siteurl'
  • 'home'

の2つ。

代わりは

  • echo site_url()
  • echo home_url()

です。(どちらも返り値があるタイプなので出力する場合は要echo)

ちなみに、非推奨になったのは2.2のときみたい(結構前だな)

非推奨とはいえ、一応現在(version4.2.4)でも使用できています。

こういう場合の対策として、基本的に関数はさらにラッピングしといて、functions.phpだけ修正すればOKみたいにしておくべきだろうか・・・

それも面倒だなぁ。

 

参照サイト

総合管理者 | 2015年08月18日 | コメント(0) | トラックバック(0) | CMS関連

Copyright(c) 2010 - 2017 ダリの雑記