カテゴリー: Web制作・プログラミング

実際の制作現場で役に立つ、技術的な話がメイン。

  • WordPress 表示設定で「投稿ページ」に指定した固定ページのID取得

    WordPress 表示設定で「投稿ページ」に指定した固定ページのID取得

    WordPressの表示設定で、「投稿ページ」に固定ページを指定した場合の、指定された固定ページのIDを取得する方法。

    調べてもなかなか出てこなかったのでメモ




    実装

    取得するタグは以下

    get_option('page_for_posts')

    これで、投稿ページのIDを取得できます。
    IDさえ取得すればあとはなんとでもなる。

    例えば、投稿ページのURLを出力したい場合は

    the_permalink( get_option('page_for_posts') );

    と書けばOK。

     

    以上、現場からでした。

  • Advanced Custom Fieldsで「真/偽」を使ったときのmeta_queryの指定

    Advanced Custom Fieldsで「真/偽」を使ったときのmeta_queryの指定

    WordPressのカスタムフィールドを作れるプラグインAdvanced Custom Fieldsの「真/偽」を使って、「チェックした記事は一覧に表示させない(meta_queryで除外する)」方法を調べるのにけっこう時間がかかったので、備忘録として。




    その答えは、こうだ!!!

    $param = array(
    	'posts_per_page' => '3',
    	'post_type' => 'news',
    	'meta_query' => [
    		[
    			'key' => 'check_flag',
    			'value' => '0',
    			'compare' => '='
    		],
    	],
    );

    これで、「”check_flag”にチェックが入っていない記事」だけが表示されます。

    しかし、ここで要注意なんですが、既にある程度記事がある段階で真/偽フィールドを追加した場合、このままだとうまく除外できません

    なぜかというと、上記は具体的には「値がfalse(0)である記事のみ表示させる」という意味なんですが、なんと真/偽フィールドを追加する前から存在している記事は、チェックをしていない場合に入ってる値はfalseではなくNULLだからなんですね。
    そもそも値が入っていないのです。

    だから、そういった場合は上記に加え「NULLのやつも表示」って書く必要があります。

    $param = array(
    	'posts_per_page' => '3',
    	'post_type' => 'news',
    	'meta_query' => [
    		'relation' => 'OR',
    		[
    			'key' => 'check_flag',
    			'value' => '0',
    			'compare' => '='
    		],
    		[
    			'key' => 'check_flag',
    			'compare' => 'NOT EXISTS'
    		]
    	],
    );

    これでよし。

     

    おまけで、「”check_flag”にチェックが入っている記事」だけ表示したい場合はこう。

    $param = array(
    	'posts_per_page' => '3',
    	'post_type' => 'news',
    	'meta_query' => [
    		[
    			'key' => 'check_flag',
    			'value' => '1',
    			'compare' => '='
    		]
    	],
    );

    まぁ、こっちは公式に書いてるんですけどね。

     

    ついでにもう一つ、ちょっと応用編。

    例えばindex.phpとかarchive-news.phpで、WP_QUERYを使っていない場合。(条件なしで普通にループさせている場合。)
    こうなると、もし上記を実装するとなるとWP_QUERYを書かなきゃいけなくなって、カテゴリーページとか年別アーカイブも作って同じように実装して…ってやらなきゃいけないので、めちゃくちゃめんどくさいですよね。

    そんなときは、functions.phpで以下のようにやっちゃいましょう。

    add_filter( 'parse_query', 'custom_parse_query' );
    function custom_parse_query( $query ) {
      if ( is_admin() || is_singular() ) { // 管理画面とsingleは除く
        return false;
      }
    
      $check_flag_array = array(
        'relation' => 'OR',
        array(
          'key' => 'check_flag',
          'value' => '0',
          'compare' => '='
        ),
        array(
          'key' => 'check_flag',
          'compare' => 'NOT EXISTS'
        )
      );
      if ( get_query_var( 'post_type' ) == 'news' ) { //post_typeを指定
          $query->set( 'meta_query', $check_flag_array );
      }
    }

    これで、「post_typeがnewsの一覧(query)」で、同様の条件を指定することができます。

    もしnews以外も同じ条件を指定したい場合は、post_typeを増やすだけです。
    ※$query->is_main_query()も入れないと、index.phpで適応されないみたいです。

    add_filter( 'parse_query', 'custom_parse_query' );
    function custom_parse_query( $query ) {
      if ( is_admin() || is_singular() ) { // 管理画面とsingleは除く
        return false;
      }
    
      $check_flag_array = array(
        'relation' => 'OR',
        array(
          'key' => 'check_flag',
          'value' => '0',
          'compare' => '='
        ),
        array(
          'key' => 'check_flag',
          'compare' => 'NOT EXISTS'
        )
      );
      if ( get_query_var( 'post_type' ) == 'news' || get_query_var( 'post_type' ) == 'post' || get_query_var( 'post_type' ) == 'seminar' || get_query_var( 'post_type' ) == 'business' || $query->is_main_query() )
    }

    これでぐっと楽になりました。
    しかもなんと、RSSフィードにも表示されないみたいです!

     

    以上、現場からでした。

     

    よかったらこっちもどうぞ

    WordPress functions.phpを関数ごとに分割して管理しやすくする話

  • 今のSEOに不可欠なE-A-T。その理由とプラグインでできるちょっとした対策

    今のSEOに不可欠なE-A-T。その理由とプラグインでできるちょっとした対策

    今のSEOには、E-A-Tが重要と言われています。

    今まで上位にきていたアフィリエイトブログがどんどんぶっ飛んでいる理由がここにありそうで、いったいE-A-Tとはなんなのか、どうしたら対策できるのかということを考えてみたいと思います。

    今までのSEOの知識だけでは上位表示させるのは難しいかもしれません。




    E-A-Tってなに?

    E-A-Tとは、Googleの造語で、「専門性(Expertise)」「権威性(Authoritativeness)」「信頼性(Trastworthiness)」の略です。

    専門性、権威性、信頼性のあるコンテンツ作りが重要ということです。

     

    なぜE-A-Tが重要なのか

    まぁ当たり前のことなんですが、「その分野において、検索したユーザーがしっかり信用できる内容」を書いている記事が上位に出るよってことですよね。

    そりゃそうよ。

    どこの馬の骨が書いたかわからないような適当な知識、トンデモ医療だったりを全世界の人間が信じると、Googleとしてもまずいわけですよ。

     

    だから、適当な知識で、誰が書いたかわからないような記事は軒並み順位が下がっていますよね。

    特に、医療関係なんかは顕著で、ちゃんとした医者や病院が書いている記事が上位に来るようになりました。

    これは他の分野でももちろん当てはまることで、どっかのブログから適当に得た知識で量産していたアフィリエイトブログなんかは、吹っ飛んで当然なんですよね。
    適当ばっか書くなよってことです。

     

    というわけで、逆に、信用に値する記事は上位に上がるんですね。

     

    Googleの検索担当副社長のベン・ゴメス氏も、「ランキングシステムは、高いE-A-Tの兆候を持ったサイトを特定するように設計されている」と実際に言っていることから、E-A-Tはランキングに深く関わっていることは明白。

     

    どうすればE-A-Tを改善できるか

    これについては、いろんな人のいろんな意見があると思いますが、僕はこちらのTipsの内容は信頼できると思いますので、支持します。

    僕はSEOについては、Googleの人が言ってるなら信じます(笑)

    E-A-Tに関して書いてある記事、いろいろ読んできましたが、「いやそうはならんやろ」って記事がいっぱいありました、ぶっちゃけ。それこそE-A-Tを重視しろよ。

     

    というわけで、信頼できるこの記事によると、すぐできる改善策は大まかに2つ。

    ・著者情報を表示する。
    ・その分野に権威がある人からのリンクを得る

    著者情報を表示する

    なんか最近、どうもみんな記事に著者情報を入れたがると思ってたんですが、E-A-Tに関係することだったのかもしれないですね。

    その記事を書いた人がどんな人なのか、どんな専門家なのかがわかるようにすると効果があるかもしれないとのことです。

    僕はずっと、サイドメニューに自己紹介を書いて、プロフィールページにも誘導してたんですが、ちょっと実験的に表示方法を変えてみることにしました。

    これで順位上がったらすごいですよね。
    まぁ、サイドメニューにも元々あったので、効果が上がるかはわからないんですが、今回追加してみようと思うのは構造化マークアップです。

    構造化マークアップについて

    構造化マークアップとは、Google botがよりコンテンツの内容を理解できるよう記述する記法のことで、構造化マークアップを行うことで、検索時のリッチスニペットに表示されたりするんですが、僕が思うに、これからはこの構造化マークアップが超重要になってくると思うんですよ。

    検索/ランキングシステムには人工知能が深く関わってますが、人工知能を発達させるには、とにかくデータが必要。
    で、そのデータをどうやってとるかというと、構造化マークアップデータから引っ張ってくるんじゃないかと思うんです。

    どうやって構造化マークアップするのか

    まぁちょっと、自力でやろうと思うと初心者には厳しいですよね。

    でもWordPressなら、テーマやプラグインのパワーで大概なんとかなります!

    というわけで、今回は著者情報を表示・マークアップできるプラグイン「Simple Author Box」を使ってみようと思います。

    Simple Author Box

    このプラグインを有効にすると、プロフィール編集が拡張され、SNSのアイコンを登録したりできるようになります。

    あと、早速この記事の一番下にもあると思うんですが、全ての記事下に著者情報が記載されるようになります。
    ついでにプロフィールページへのリンクもつけてます。

    もちろん、構造化マークアップ対策もばっちり。

    自分のブログが構造化マークアップに対応しているかどうかは、「構造化データ テストツール」でチェックすることができます!

    僕の場合はこんな感じです。

    これで、ひとまず「著者情報を表示」は簡単にできますね!

    その分野に権威がある人からのリンクを得る

    これについては、「その分野の権威者と仲良くなる」「頼み込んでリンクしてもらう」という手が使える人はいいかもしれませんが、そんなコミュ力ねぇよって人は、長い目で見るしかないんじゃないかと…

    ただ、ひたすらに役に立つ記事を書いていれば、自然とリンクは集まります

    例えば僕のブログも、他の人のブログ記事やどっかの社内GithubのWikiから参考リンクとして貼られていたりしますからね。そういった記事は、確かにアクセスが増えたように思えます。

     

    参考記事にもありますが、役に立つ情報やツールを提供しようねってことですね。

     

    おわり

    Googleの技術もどんどん発達していて、そのたびに「サイト吹っ飛んだ~」って言ってる人を見かけますが、そりゃ適当なこと書いてたらいつか飛ぶだろと。

    Googleもそれくらいは見分けがつくようになってるってことなので、これからはしっかりと信用できる記事を書く必要があるってことですね。

     

    僕のブログは適当なこと書いてる記事はないはずですよ!
    みんな信じてね!

    それじゃ、バイバイ~

  • CSS 「n番目の要素」を指定できるnth系疑似要素のまとめと注意

    CSS 「n番目の要素」を指定できるnth系疑似要素のまとめと注意

    「n番目の要素」という指定ができる”:nth-child(n)”系の疑似要素ですが、注意しなければいけない点と、案外知られていない便利なバリエーションがあるので、まとめます。




    基本の使い方

    以下のような構造とします。

    <div class="parent">
        <div class="child">1番目の要素</div>
        <div class="child">2番目の要素</div>
        <div class="child">3番目の要素</div>
        <div class="child">4番目の要素</div>
        <div class="child">5番目の要素</div>
    </div>
    .parent {
      border: 1px solid #000;
      padding: 20px;
    }
    .child {
      border: 1px solid #000;
      font-size: 16px;
      padding: 10px;
      margin-bottom: 10px;
    }

    上からn番目の要素を選択

    :nth-child(n)

    .child:nth-child(3) {
      background-color: #ddd;
    }

    兄弟要素と比較し、上から数えて3番目の.childの背景色を変更。

    この「兄弟要素と比較」というのが大事です。
    これについては後で補足します。

    下からn番目の要素を選択

    :nth-last-child(n)

    .child:nth-last-child(2) {
      background-color: #ddd;
    }

    最初の要素を選択

    :first-child

    .child:first-child {
      background-color: #ddd;
    }

    最後の要素を選択

    :last-child

    .child:last-child {
      background-color: #ddd;
    }

    偶数要素を選択

    :nth-child(even)を使えば、偶数要素を選択できます。
    ちなみに、:nth-child(2n)でも同じことができますので、僕はこっちを使ってます。

    .child:nth-child(even) {
      background-color: #ddd;
    }

    奇数要素を選択

    :nth-child(odd)を使います。
    :nth-child(2n-1)でも同じことができます。

    .child:nth-child(odd) {
      background-color: #ddd;
    }

    n個置きに要素を選択

    これが意外と便利。

    例えば3個置きに要素を選択したい場合は、”:nth-child(3n)”、4個置きの場合は”:nth-child(4n)”のように書きます。

    また、”:nth-child(3n-1)”のように書くと、”2,5,8,11,…”という指定もできます。

    要するに、nは自動で”0,1,2,3,…”と値が代入され、nの掛け算、引き算、足し算で、要素を選択できるというわけです。

    :nth-child(3n-1)の場合、

    n = 0 のとき、 :nth-child(-1) ※これは正数ではないため、表示されません
    n = 1 のとき、 :nth-child(1)
    n = 2 のとき、 :nth-child(5)
    n = 3 のとき、 :nth-child(8)

    といった感じで、自動で計算されるというわけです。
    便利!

    .child:nth-child(3n-1) {
      background-color: #ddd;
    }

    nth-childが参照する要素の範囲に注意

    途中にちらっと言いましたが、nth-childは、指定した要素の兄弟要素と比較されます。
    つまり、以下のような構造のとき、思わぬ事態が発生します。

    <div class="parent">
        <h2>グッとくる見出し</h2>
        <div class="child">1番目の要素</div>
        <div class="child">2番目の要素</div>
        <div class="child">3番目の要素</div>
        <div class="child">4番目の要素</div>
        <div class="child">5番目の要素</div>
    </div>
    .child:nth-child(3) {
      background-color: #ddd;
    }

    :nth-child(3)にしてるのに、2番目の要素が選択されている!

    これはなぜかというと、一番上の<h2>もカウントされているからです。
    nth-childは、指定したclassだけでなく、兄弟要素全てと比較されます。
    つまり、上から3番目なんだけど、一番上は<h2>なので、実質上から3番目の要素である2番目の.childが選択されている状態。

    この仕様を知っておかないと、以下のような構造の場合、手間取ってしまうかもしれません。

    解決策は2つ。

    解決策1:更にブロックで囲む

    正直、これがシンプルで構造的にも一番綺麗な解決法だと思います。

    <div class="parent">
        <h2>グッとくる見出し</h2>
        <div class="block">
            <div class="child">1番目の要素</div>
            <div class="child">2番目の要素</div>
            <div class="child">3番目の要素</div>
            <div class="child">4番目の要素</div>
            <div class="child">5番目の要素</div>
        </div>
    </div>

    childを、blockで囲みました。
    まぁ普通こうするよね。

    解決策2:nth-of-typeを使う

    ちょっとトリッキーな方法となりますが、nth-childの親戚に、nth-of-typeという疑似要素があります。

    これはどういうものかというと、例えば以下のような使い方になります。

    <div class="parent">
        <h2>グッとくる見出し</h2>
        <div class="child">1番目の要素</div>
        <div class="child">2番目の要素</div>
        <div class="child">3番目の要素</div>
        <div class="child">4番目の要素</div>
        <div class="child">5番目の要素</div>
    </div>
    .parent div:nth-of-type(3) {
      background-color: #ddd;
    }

    .parent div:nth-of-type(3)と書くと、「.parentの中のdiv」の、上から3番目ということになります。

    つまり、比較されるのはdivだけなので、他の要素はカウントされません

     

    一点、この疑似要素を使う際に注意しなければいけないのは、classをつけたときの挙動。

    例えば、

    .parent div.child:nth-of-type(3)

    と書いた場合、
    「parentの中のdiv.childの上から3番目」ではなく、
    「parentの中のdivの上から3番目で、かつclassがchildのもの」
    という指示になります。

    疑似要素自体はclassには使えないので、注意してください。

    番外編

    あんまりこういうことはないと思うんですが、nth-of-childの応用として、こんなこともできます。

    <div class="parent">
        <h2>グッとくる見出し</h2>
        <p class="text">見出しの次に来るナイスなリード文</p>
        <p class="text">リード文の次に来る小粋なジョーク</p>
        <h3>匠の粋な計らい</h3>
        <p class="text">なんということでしょう、ネタ切れです</p>
    </div>
    .parent p:nth-of-type(3) {
      background-color: #ddd;
    }

    うーん…使わないなこれ。
    まいっか!

    以上、現場からでした。

  • Webデザイナーはコーディングもできるべきか?についてデザインできないコーダーが考える

    Webデザイナーはコーディングもできるべきか?についてデザインできないコーダーが考える

    最近Twitterで、「Webデザイナーはコーディングもできてようやくスタートライン」という意見が話題になっています。

    これについては賛否両論で、今に始まったことではなく昔からずっと議論されていたことなのですが、デザインできないコーダーである僕の個人的な意見を語ろうと思います。

    先に結論から言ってしまうと、

    Webデザイナーはコーディングをできなくてもいいけど、ある程度知っておく必要はある

    というのが僕の見解です。




    Web向けのデザインになってない

    今はCSS技術も発達していて、大抵の装飾であれば実現可能となってます。
    それ故に、「画像は極力使わず、CSSで表現してね」という要望が増えています。

    LPなんかも、昔は画像をベタベタ貼り付けるだけでよかったんです。
    SEOとか関係ないですからね。

    でも今は、LPもテキストがメインとなってます。

    そんな時代、これはWebではなく紙媒体向けのデザインだよねみたいなのが来ると、正直困ります。

    例えば、

    ・フォントサイズの種類が豊富すぎる
    ・文字詰めに異様にこだわる
    ・禁則処理について考えてない
    ・要素の配置が自由すぎる
    ・画面幅が変わったときのデザインが考えられていない
    ・コンテンツ幅がばらばら
    ・インデントがばらばら

    などなど…

    こういった項目って、コーディングができるどうのこうのよりまずWebデザインの基礎とも呼べる部分だと思うんですが、コーディングを全く知らないデザイナーはこの辺が出来ていないことが多いです。

    このあたりのことがしっかりできていないと、見た目はもちろんWebでは見るに堪えない見た目になっちゃいますし、コーディングがめちゃくちゃ時間かかるし、コーディングに時間がかかるってことは単純にコーダーがしんどいだけでなく、工数的にも赤字になりますので、いいことはありません。
    ちょっとの工夫でコーディングしやすいデザインにしていただくだけで、コーディングにかかる時間はかなり減ります。

    「コーディングでできること、できないこと(時間がかかること)」を知っておくと、必然的にこのあたりの欠点は改善されます。

    見づらい、使いづらい

    「そうはいってもクライアントがそうしたいって言ってるし、コーダーががんばればいいじゃない?」

    オーケー、コーダーがんばります。
    例え残業続きでドロドロになり、あなたを呪いながら今後生きていくのを良しとするのであれば、いいでしょう。
    仕事だから、いやいややります。

    だけど、まぁちょっと待ってほしいんです。

    最終的に、そのサイトを見るのは誰かと。

    上司?クライアント?
    デザイナー私?

    いいえ、違います。
    一般ユーザーです。

    そして、いくらクライアントや上司、デザイナーわたしが良しとした破壊的デザインと言い張っても、一般ユーザーが見づらい、使いづらいと感じたならば、そのサイトは、「壊れ切ったゴミ」です。

     

    コーディングがちょっとわかる状態であれば、htmlの構造をなんとなく理解し、ユーザーが見やすい、使いやすいというのがどういうことなのかが自然とわかってきます。

    というか、コーディングしてると、「うわ、これ使いづらいやろなー…まぁ命令だからやるけど」という多々あるので、むしろどうなってれば使いづらいかがわかるんですよね。

     

    僕は制作会社に勤めてたときは、コーダー兼ディレクターというような立ち位置でいましたが、デザイナーから上がってきたデザインを確認するときはまず「使いづらくないか、わかりにくくないか」を最優先に考えてます。

    コーディング大変そうだなー、は、まぁあまりにもしんどそうだと相談することもありますが、基本的にはデザイナーの夢を叶えるべく努力するべきだとは思ってますので、そこはいいんです。

    ユーザーのことを第一に考えて制作しましょう。

    そこまではできなくていい

    コーディングのプロフェッショナルと言われるほど、コーディングができるようになる必要はないかなと。

    むしろ、デザイナーはデザインに集中し、コーダーはコーディングに集中したほうが、役割分担もできて効率よく高品質なWeb制作ができます。

    もちろん、デザインもコーディングも一人でできたら素晴らしいんですけどね…まぁ、そこに到達するには相当な努力と経験が必要だと思います。
    大抵は、どちらも微妙な中途半端なクオリティになることが多いんじゃないでしょうか。

    フリーランスとかだと、たまに一人でなんでもできる方がいらっしゃいますが、僕はデザインは一切しません
    得意じゃないことを仕事にしている余裕はないですからね。

     

    ただ、デザインは仕事としてはしませんが、
    デザインの本を読んだり、実際にPhotoshopでデザインをして、サイト制作までやったことはあります。

    これはもちろん、デザイナーがコーディングを知っていればいいと思うのと同時に、コーダーもデザインのことを知っていればいいと思うからです。

    例えば、「デザインは作ってないので、既にあるページにトンマナを合わせ作ってください」とか、「レスポンシブはお任せします」とか言われたときに、デザインの知識があるかないかでは大違いですよね。

    テンプレートを使うにしても、イケてるファーストビューやUIを設計するためにはデザインの知識は不可欠です。

    いろんな人のデザインを見て、実際に自分でもデザインしてみて、「デザインのパターン」のようなものを知っていたほうが良いサイトになるのは間違いないです。

    いやフレームワーク使えばええやんと思うかもしれませんが、そりゃそうなんですけど、それにしてもフレームワークだけに頼っていると、どこにでもあるテンプレート的なサイトになっちゃいますよね。
    もちろん、そういうサイトを時間をかけず量産してビジネスにするのも全然ありなんですけど、自分で運営するサイトはなんとなくいい感じにしたいじゃないですか。

    使いやすさだけにこだわりすぎて、視覚的につまらないサイトになるのもちょっと考え者かなと思いますので。

    おわり

    なんかデザイナーにがんばってくださいって言ってるような記事になっちゃいましたが、僕はむしろコーダーにこそがんばってほしい

    デザイナーから来たむちゃくちゃなデザインを再現するのをがんばるのではなく、デザイナーとのコミュニケーションをがんばる。育成をがんばる。

    しんどいなこのデザインと思ったらデザイナーに伝えて直してもらえばいいし、もし既にクライアントに提出しちゃって直せないのなら、「こういう理由でしんどいので、次からはできればやめてほしい」というような相談をすればいいんです。

    実際、僕もフリーランスという立場ですが、厳しいデザインが来たら直してほしいと普通に言いますし、逆に「どういうデザインだったらコーディングしやすいか」って相談受けることもありますよ。

    自分がしんどいことをただSNSで愚痴をこぼすだけじゃ何も変わりません
    それに、デザイナーだってしんどいに決まってますので。
    仲良く協力して、良いWeb制作しましょうねってことで。

     

    バイバイ!

  • 「WordPress Popular Posts」でランキングを好きなように表示させるシンプルなやり方

    「WordPress Popular Posts」でランキングを好きなように表示させるシンプルなやり方

    WordPressで、記事の閲覧数ランキングを表示させるときに便利なプラグイン「WordPress Popular Posts(以下WPP)」。

    そのままウィジェットに突っ込めばランキング表示できるし、設定もいろいろできるしすごく良いですよね。

    ところが、表示の仕方をカスタマイズしたり、もっと好きな場所に好きなように表示させたいとなった場合、何やら関数を作ったりフックを使ったりしなきゃいけないようで初心者にはちょっとつらい。

    というわけで、初心者向けに超シンプルにフルカスタマイズできる方法をご紹介します。




    実装

    考え方は至ってシンプル。

    ①ランク順に「記事ID」を取得
    ②記事IDをもとに、WP_Queryで普通にまわす

    めっちゃ簡単にできそうでしょ!?

    できます。
    やっていきましょう。

    記事IDを取得

    <?php
    if ( function_exists( 'wpp_get_mostpopular' ) ){
      $wpp_option = array( // 表示オプションの設定
        'range' => 'weekly',
        'post_type' => 'post',
        'order_by' => 'views',
        'limit' => 5
      );
      $wpp_query = new WPP_Query( $wpp_option );
      $wpp_query_ids = array_map(
        function( $wppost ){
          return (int)$wppost->id;
        }, $wpp_query->get_posts()
      );
    }

    こんな感じです。

    $wpp_optionでは、表示オプションを配列にしてやります。

    WPPで使えるオプションは、「設定→WordPress Popular Posts→パラメーター」から確認できます。

    これで、”$wpp_query_ids”に、1~5位までの記事のIDが配列で格納されました。

    あとは、この配列を使って、WP_Queryで記事を表示させます。

     

    普通にループ

    おなじみのやつですが、“orderby => post__in”の部分がポイント。

    <?php
    $wp_query = new WP_Query();
    $param = array(
      'posts_per_page' => '5',
      'post_type' => 'post',
      'post__in' => $wpp_query_ids, // ここで記事IDの配列を使う
      'orderby' => 'post__in' // 配列に入ってる順番に表示
    );
    $wp_query->query($param);
    if($wp_query->have_posts()):
      while($wp_query->have_posts()) : $wp_query->the_post();
    ?>
    <p><a href="<?php the_permalink();"><?php the_title(); ?></a></p>
    <?php
      endwhile;
    endif; wp_reset_query();
    ?>

     

    ランクとか、閲覧数も表示させたい!

    WPPを仕様通り表示させると、簡単に閲覧数やランクを表示させることができますが、今回はIDだけ拾ってあとは普通のループに任せちゃってるので、表示させられないじゃん…

    しかしご安心ください。いけます。

    閲覧数の表示

    wpp_get_views()という関数を使います。

    ループ内で以下のように書けば、閲覧数を表示させることができます。

    <?php echo wpp_get_views($post->ID, 'weekly'); ?>

    上の例と合わせるなら、こんな感じ

    <?php
    $wp_query = new WP_Query();
    $param = array(
      'posts_per_page' => '5',
      'post_type' => 'post',
      'post__in' => $wpp_query_ids, // ここで記事IDの配列を使う
      'orderby' => 'post__in' // 配列に入ってる順番に表示
    );
    $wp_query->query($param);
    if($wp_query->have_posts()):
      while($wp_query->have_posts()) : $wp_query->the_post();
    ?>
    <p><a href="<?php the_permalink();"><?php the_title(); ?></a>(閲覧数:<?php echo wpp_get_views($post->ID, 'weekly'); ?>)</p>
    <?php
      endwhile;
    endif; wp_reset_query();
    ?>

    ランクの表示

    こっちはプログラミングでやっちゃいましょう。

    基礎中の基礎、「変数$iをループごとに1ずつ増やして表示させる」だけですね。

    <?php
    $wp_query = new WP_Query();
    $param = array(
      'posts_per_page' => '5',
      'post_type' => 'post',
      'post__in' => $wpp_query_ids, // ここで記事IDの配列を使う
      'orderby' => 'post__in' // 配列に入ってる順番に表示
    );
    $wp_query->query($param);
    if($wp_query->have_posts()):
      $i = 1; // 変数"$i"を定義
      while($wp_query->have_posts()) : $wp_query->the_post();
    ?>
    <p><?php echo $i; ?>位</p>
    <p><a href="<?php the_permalink();"><?php the_title(); ?></a>(閲覧数:<?php echo wpp_get_views($post->ID, 'weekly'); ?>)</p>
    <?php
      endwhile;
      $i++; // $iを1増やす
    endif; wp_reset_query();
    ?>

     

    おわり

    こんな感じで、難しく考えなくても、シンプルにランキングが実装できます。
    クライアントワークでも使えますね!

    僕は頭がよろしくないので、いつも難しいコードとか読むと発狂しそうになるんですが、だいたいは「IDさえゲットできればなんとかなる」と思っていて、とにかくまずはIDを取得することを考えるようにしています。

     

    ではでは、エクセレントなランキング表示を!

  • 「My WP Customize」で、特定の権限だけに設定を反映させる方法

    「My WP Customize」で、特定の権限だけに設定を反映させる方法

    WordPressで、クライアントに納品するとき、管理画面上で無駄な部分を非表示にするために今まで使っていた「WP Admin UI Customize」。

    すごく便利だったんですが、新しいプラグインに移行するため開発が終了するとのことで、今後使えなくなりそうです。

    その新しいプラグインが、「My WP Customize」。

    こちらは「WP Admin UI Customize」の上位種のようなものですが、どこをどう見ても、我々が一番ほしいであろう「特定の権限だけに設定を反映させる」設定画面が見当たらない

    これじゃ管理者にまで反映されちゃうじゃん、できないの?と思っていたのですが、できました。アドオンを使うみたいです。




    アドオンのダウンロード・インストール

    下記公式サイトにアクセスし、

    https://mywpcustomize.com/add-ons/

    「Select User Roles」を選択。

    飛んだページの下の方に、「Download」という項目があり、リンクがあるので、飛ぶ。

    するとgithubにたどり着きます。右上の「Clone or Download」→「Download ZIP」を選択すると、zipファイルがダウンロードできます。

    ファイルをダウンロードしたら解凍します。このzipのまま管理画面からアップロードはできませんので、注意してください。

    解凍したら、フォルダの中にある「mywp-select-user-roles」というフォルダを、FTPで「wp-content/plugins」の中にアップします。

    アップしたら管理画面を開き、「プラグイン」から「My WP Add-on Select User Roles」を有効にしましょう。

    これでようやくアドオンをインストールできました。

    設定

    アドオンを有効化したら、管理画面のメニュー「My WP」の子メニューに「ユーザー権限グループ」が追加されていると思いますので、見てみましょう

    こんな感じで、設定を反映させる権限を選択できるようになりました。

    やったね。

     

  • 【JavaScript】iPadだけviewportを固定してPC表示にするやつ

    【JavaScript】iPadだけviewportを固定してPC表示にするやつ

    レスポンシブだけど、iPad(タブレット)ではPCの縮小表示にしたい。
    あると思います。

    僕は基本WordPress使いなので、phpでviewportを場合分けしていたんですが、phpを使わない場合はJavaScriptでもできます。




    実装

    htmlのhead内は、スマホ向けにこうしておきましょう

    <meta name="viewport" content="width=device-width">

     

    JavaScriptでユーザーエージェントを判別し、iPadの場合だけmeta viewportを書き換えます。

    const baseW = 1120; // viewportのwidth
    const ua = navigator.userAgent
    
    const sp = ua.indexOf('iPhone') > -1 ||
      (ua.indexOf('Android') > -1 && ua.indexOf('Mobile') > -1)
    
    const tab = !sp && (
      ua.indexOf('iPad') > -1 ||
      (ua.indexOf('Macintosh') > -1 && 'ontouchend' in document) ||
      ua.indexOf('Android') > -1
    )
    
    if (tab) {
      viewportContent = "width=" + baseW + "px,user-scalable=no";
      document.querySelector("meta[name='viewport']").setAttribute("content", viewportContent);
    }

    jQueryと違って早いので、ページ読み込み時に一瞬だけなんかおかしい!ということも軽減されます。iPad以外では動かないしね。

    現場からは以上です。

  • 【Sass】BEMとSMACSSをなんとなく使っていい感じのCSS設計

    【Sass】BEMとSMACSSをなんとなく使っていい感じのCSS設計

    CSS設計、やってますか?
    何も考えずに命名したりCSSを書いていると、拡張性や管理性を損なうとんでもないものが出来上がります。
    作ったときはいいけど、後で修正したり追加したりするときに、どこか知らんとこがついでに崩れたり、反映されないからどんどん!importantで上書きしてガチガチに絡まったCSSになったりします。

    そういった問題を防ぐためにも、CSS設計をちょっとでもいいので心がけるようにしていきましょう。
    最初はちょっとしんどいかもしれませんが、慣れてくると「どんな名前をつければいいか」に悩む時間も減りますので、効率爆上がりです。

    僕は、BEMとSMACSSという2つの設計方法をなんとなく取り入れ、CSS設計を行っています。
    両方とも完璧に取り入れようとすると逆にしんどいので、なんとなくでいいんです。
    とりあえず意識してみることから始めて、もっとこうしたほうがいいかなーと思ったら改善していくといった流れでいくのがオススメ。

    CSS設計ができるようになると、

    • コーディングが早くなる。
    • わかりやすいコードを書ける。
    • メンテナンス性がいいので、修正や追加のときも楽ちん。
    • 一歩上に行ける気がする

    いいことづくしです。
    まずはBEMとSMACSSがどんなものなのかをだいたい説明して、組み合わせることのメリットを紹介したいと思います。

    ちなみに、僕のフレームワークをGithubで公開していますので、SMACSSについては合わせて読むとわかりやすいと思います。
    それでは、参りましょう。





    BEMとは?

    下の記事でもさらっと紹介していますが、

    初心者がコーディングを3倍速くするために知っておきたい6つの技術

    BlockElementModifireという3つの概念の頭文字をとったものです。
    難しいことは考えず、基本的にこの3つを使ってclass名をつけるということだけ頭に入れておきましょう。

    Block

    ヘッダー、フッターや記事一覧の繰り返し要素など、大まかなパーツ。
    Blockの中にBlockを含んでもいいが、cssではBlockを入れ子にしない

    Element

    Blockに所属する、細かいパーツ。
    その所属するBlock内でのみcssが機能する

    Modifire

    Block、およびElementにて、既存のものとほとんど一緒だけど、ちょっとだけ違う部分があるというときに使う
    バリエーションを与える役割がある。

    命名方法

    命名方法は人によってけっこう違うみたいだけど、Block、Element、Modifireの関係性がわかればOK。

    例えば僕は以下のように命名します

    {Block}__{Element}
    {Block}-{Modifire}
    {Block}__{Element}-{Modifire}

    BEMを使って命名する場合、最初は必ずBlockからはじまり、ElementとModifireの前にそれぞれ別のつなぎをくっつけます。
    アンダースコアとか、アイフンとか、なんでもいいです。
    ただ、Elementの前はアンダースコア2つというのはけっこう共通認識みたいなので、これはこれでいったほうが他の人が見たときに、「あ、BEMだな」とわかりやすいかと思います。

    図で説明するとこんな感じ

    <div class="archiveItem">
      <a class="archiveItem__inner">
        <div class="archiveItem__thumb"><img src="" alt=""></div>
        <div class="archiveItem__right">
          <h2 class="ardhiveItem__title">タイトルタイトル</h2>
          <p class="archiveItem__text">テキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキスト</p>
        </div>
      </a>
    </div>
    <div class="archiveItem">
      <a class="archiveItem__inner">
        <div class="archiveItem__thumb"><img src="" alt=""></div>
        <div class="archiveItem__right">
          <h2 class="ardhiveItem__title">タイトルタイトル</h2>
          <p class="archiveItem__text">テキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキスト</p>
        </div>
      </a>
    </div>
    <div class="archiveItem">
      <a class="archiveItem__inner">
        <div class="archiveItem__thumb"><img src="" alt=""></div>
        <div class="archiveItem__right">
          <h2 class="ardhiveItem__title">タイトルタイトル</h2>
          <p class="archiveItem__text">テキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキスト</p>
        </div>
      </a>
    </div>

    ちなみBlockは、キャメルになってもいいです。

    こんな感じで各パーツ全てにclass名をつけます。
    そして驚くべきことに、これら全てのパーツはcssで入れ子にならないということに気づくかと思います。
    入れ子にならないというのはかなり安全で、読みやすく、そして指定しやすいです。

    さらに、命名にかかる時間も大幅に短縮されます。Block名さえ考えれば、Elementはtextとかthumbとか適当でいいですからね。
    これが、入れ子だとどうでしょうか。
    下のように、全然スタイルが違う.archiveListと.rankingListがあるとして、

    <div class="archiveList">
      <h2 class="title"></h2>
      <p class="text"></p>
    </div>
    
    <div class="rankingList">
      <h2 class="title"></h2>
      <p class="text"></p>
    </div>

    中に.titleと.textがある。cssは、こんな感じですよね

    .archive .text {
    
    }
    .ranking .text {
      
    }

    じゃあ、もし次のような構造だったら?

    <div class="archiveList">
      <h2 class="title"></h2>
      <p class="text"></p>
    
      <div class="rankingList">
        <h2 class="title"></h2>
        <p class="text"></p>
      </div>
      
    </div>

    一気にややこしくなりましたね。
    こうなってくると、うーんどう名前つけようか…となってくるわけですが、BEMだと一瞬です。

     

    「いやこんなんcss書くのめんどいやん!」と思うかもしれません。
    しかし安心してください。
    ここでSassの出番です。

    cssでは以下のように書くところを、

    .archiveItem {
      margin-bottom: 20px;
    }
    .archiveItem__inner {
      display: flex;
      padding: 10px;
    }
    .archiveItem__thumb {
      margin-right: 20px;
    }

    Sass(scss)では以下のように書けます。

    .archiveItem {
      margin-bottom: 20px;
      &__inner {
        display: flex;
        padding: 10px;
      }
      &__thumb {
        margin-right: 20px;
      }
    }

    猛烈にわかりやすいですよね。

     

    実際は入れ子構造になってないのに、Sassなら入れ子で書けるし、親子関係が一発でわかる。これがBEMのメリットです。

    いやModifireは?

    忘れかけてましたが、Modifireの使い方もやっておきましょう。

    Modifireは、ほとんど同じだけど、ちょっとだけ違う、言うなれば「別パターン」を作りたいときに使用します。

    例えば以下のように。

    左右の順番が違うだけで、あとは全部一緒。ってときにほんの少しスタイル書き足すだけなのに(ちなみに順番を逆にするのは ”flex-direction: row-reverce;” でいけます)、それぞれ別々のBlockとして命名するのはめちゃくちゃめんどくさいですよね。

    そこで登場するのが、Modifireです。こんな感じで命名します

    <div class="archiveItem">
      <a class="archiveItem__inner">
        <div class="archiveItem__thumb"><img src="" alt=""></div>
        <div class="archiveItem__right">
          <h2 class="ardhiveItem__title">タイトルタイトル</h2>
          <p class="archiveItem__text">テキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキスト</p>
        </div>
      </a>
    </div>
    <div class="archiveItem archiveItem-reverce">
      <a class="archiveItem__inner">
        <div class="archiveItem__thumb"><img src="" alt=""></div>
        <div class="archiveItem__right">
          <h2 class="ardhiveItem__title">タイトルタイトル</h2>
          <p class="archiveItem__text">テキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキストテキスト</p>
        </div>
      </a>
    </div>

    もともとのBlockのClass名はそのまま残したうえで、”-{Modifire}”をくっつけたClassを更に追加します。これにより、ほとんどhtmlを書き換えることなく、さらにぱっと見ただけでも「あ、基本同じだけど別パターンあるな」ということがわかりやすいです。

    これでModifireも大丈夫ですね。

    じゃあ次は、SMACSSの話をしましょう。

     

    SMACSSとは?

    SMACSS(スマックスと読むらしいです)とは、BEMとはまた違ったCSS設計の一つです。

    本当はけっこう奥が深いんですが、今回のテーマは「BEMとSMACSSをなんとなく組み合わせたいい感じのCSS設計」なので、ひとまず全体をふわっと説明したあと、必要な部分だけ掘り下げていきましょう。

    CSSのカテゴライズ

    SMACSSの基本の考え方は、CSSを5つのカテゴリーに分類することです。

    • ベース
    • レイアウト
    • モジュール
    • 状態(ステート)
    • テーマ

    ちなみに、僕はテーマは使ってません

    ベース

    要素そのものにつけるスタイル。

    p, div, input等、classに関係なく基本的なスタイリングを行う。リセットCSSもここに属すると考えていい。

    ここでは、IDやclassによる指定は行わないが、属性([type=”text”])や疑似クラス(:hover)は使ってもいい。

    レイアウト

    迷ったら全部ここ。

    モジュール

    再利用可能なもの。
    ボタンとか、汎用クラス(.mb20みたいなやつ)もここに属する。
    「いろんな場所、ページで共通して使われるパーツ」を書くといい。

    “modBtn”,”modTitle”のように、”mod”をつけることが多い。

    モジュールでは、BEMによる命名規則を行わない

    状態(ステート)

    あるclassに対し、状態が変わる際に付与されるclass。
    たとえば、「メニューが開いたとき」なんかに使う。”is-open”,”is-active”のような命名のしかたをする。

    この命名をすることで、JavaScriptの指定がすごくやりやすい

    例えば.menuに対し、開いたときの状態をスタイリングしたい場合、

    <div class="menu is-open">メニュー</div>

    のように書く。

    テーマ

    色や背景等、サイトの全体で統一されるスタイルを書く。

    BEMのModifierがあるし、Sassだと変数が使えるので正直いらないと思う

     

    厳密にはけっこう違う(特にレイアウトとか)けど、僕がやってるやり方の場合、これでいいんです。なんとなくで。次いきましょう。

     

    SMACSSの真骨頂はSassで発揮される

    今まで紹介した、cssのカテゴリ分けですが、これだけだと「で?分けてどうすんの?」って感じですが、これはSassを使うことで便利になります。

    Sassには、cssにコンパイルするときに複数のsass(scss)ファイルをまとめるという機能があります。
    これを応用し、以下のようにファイルを分けます。

    “_base”,”_layout”,”_modlue”,”_state”には、それぞれカテゴリ分けされたcssを書きます。
    style.scssは、これらをまとめる記述だけです。

    @charset "UTF-8";
    
    // Include Base Style
    @import "base";
    
    // Styling Start
    @import "layout";
    @import "module";
    @import "state";

     

    ファイルの前にアンダースコアがあるものは、コンパイルの際にcssファイルとして生成されないという特徴を利用しています。
    逆にこれをつけないと、最終的にほしいのはstyle.cssだけなのに、他のいらないファイルも全部生成されて邪魔になっちゃいます。

     

    僕の場合は、更にアレンジを加えて、baseからリセット(もしくはノーマライズ)CSSだけを切り離した”normalize”ディレクトリ、ページごとにスタイリングするための”page”ディレクトリ、mixinや基本設定を記述する”lib”、外部ライブラリのスタイルを上書きするための”vend”といったファイルを作っています。
    今回は触れませんが、興味があれば記事の冒頭で紹介したGithubを眺めてみてくださいね。

    いちおうthemeも入れてるんですが、ほぼ使うことはありません。

     

    SMACSSは、カテゴリ分けすることにより可読性、メンテナンス性、拡張性の向上といったメリットがあります。逆にこれをSassを使わずcssだけでやろうとすると面倒なので、使うときはSassとセットだと認識していたほうがいいと思います。



    なんでBEMとSMACSSを組み合わせたの?

    組み合わせるといっても、ただ単に

    • BEMで命名して
    • SMACSSっぽくカテゴライズする

    だけなんですが、SMACSSはその概念の一部のみを利用しています。

    その理由は、SMACSSのデメリットを解消するためです。

    SMACSSは非常に便利なんですが、とにかく難しくて考えることが多く、下手をすれば逆に時間がかかります。
    いくら後々メンテナンス性がよくなるといっても、作るときに疲れるのはいやです。

    特に、レイアウトとモジュールの使い分けの部分ですね。
    この2つ、実際はもっとややこしいんです。
    たぶん、この記事に書いてあるレイアウトとモジュールの概念は、実際にSMACSSでググると出てくるものと全然違うだいぶゆるいものになっていると思います。

    なんでこんなにゆるくなったかというと、このめんどい部分をBEMの命名規則に肩代わりさせてるからなんですね。
    BEMを使うことで、どうしたらいいんだと迷う時間が減ります。

    SMACSSの”レイアウト”は、BEMでいうところの”Block”なんですが、何せBEMで命名していますので、全てlayout.scss内に書いても辻褄があいます。

    SMACSSのthemeを使わないのも、BEMの”Modifier”があるからです。
    そして、これも全部”layout”に書いてしまうことにしてしまえば(もしくは、ページごとに分ければ)、シンプルですっきりしますし、SMACSSのメリットを失いません。

     

    逆に、BEMの命名が成り立たないもの、単独で使う汎用クラスは”モジュール”にカテゴライズするとすれば、わかりやすいと思います。

    BEMが使えるものはレイアウト、BEMを使わないものはモジュール

    おわり

    SMACSSについては少し我流な部分がありますが、BEMもSMACSSも別にそうしなきゃいけないというルールがあるわけではなく、あくまでガイドラインなので、お互いのいい部分を組み合わせ、楽に、そしていい感じのCSS設計ができるようにしましょう。

    時間をかけずに、しかも苦しまずに、いいものを作れたら最高ですよね。

     

    それでは、ビクトリーなCSS設計を!

    バイバイ~

  • flexで3列以上横並びにするとき、左右をコンテンツ端に合わせるやり方

    flexで3列以上横並びにするとき、左右をコンテンツ端に合わせるやり方

    cssのflexを使って、3列以上の幅が均等な要素を横並びにして左右にぴったりくっつけたい場合、以下のように記述すればOK。




    <div class="box">
    	<div class="item"></div>
    	<div class="item"></div>
    	<div class="item"></div>
    </div>
    .box {
    	display: flex;
    	justify-content: space-between;
    }

     

    2行以上にする場合はflex-wrap:wrap;を追加。

    .box {
    	display: flex;
    	justify-content: space-between;
    	flex-wrap: wrap;
    }

    しかしこのままだと、要素の数が決まっていない場合で、例えば5個とかの場合に問題が発生する。こんな感じになっちゃう

    3列ならまだ「こういうもんなの…ちょっとおかしい気もするけど…まぁいいか」で済ませられることもあるけど、4列・5列となるにつれどんどん気持ち悪くなっていく。

    これをシンプルに解決する方法がこちら。

    解決方法

    結論からいうと、こういう場合はjustify-content: space-between;は使いません

    なんか疑似要素やjQueryを使って空の要素を補完するとかいう方法を見かけましたが、そんな無理してやらなくても、同じようなことはできます。

    パターンA:親要素を左にちょっとずらす

    以下のように、子要素は均等にmargin-leftをつけておき、親要素自体を左にちょっとずらす

    .box {
    	display: flex;
    	flex-wrap: wrap;
    	margin-left: -20px;
    }
    .item {
    	margin-left: 20px;
    }

    書き方はスッキリしていて、いいと思います。

    ただ、幅を%で指定したいときや、親要素を左にずらすスペースがない場合ややこしいので、僕は次のパターンBを推します。

    パターンB:一番左の子要素だけmargin-left:0;にする

    疑似要素 :nth-child() を利用して、一番左の子要素だけmargin-left:0;にしちゃいましょう。

    また、レスポンシブの場合は画面幅によって並べる数が違うと思うので、メディアクエリを使うとスッキリします。

    .box {
    	display: flex;
    	flex-wrap: wrap;
    }
    .item {
    	margin-left: 20px;
    }
    @media screen and (min-width: 751px){
    	.item:nth-child(3n+1) {
    		margin-left: 0;
    	}
    }

     

    さらにいうと、スマホでは2列!という場合、justify-content:spcae-between;のほうが幅を気にせずに済むので、効率がいいです。

     

    例:1000px以上は4列、751px~1000pxでは3列、750px以下(スマホ)では2列にするよ!

    .box {
    	display: flex;
    	flex-wrap: wrap;
    }
    .item {
    	margin-left: 20px;
    }
    @media screen and (min-width: 1001px){
    	.item:nth-child(4n+1) {
    		margin-left: 0;
    	}
    }
    @media screen and (min-width: 751px){
    	.item:nth-child(3n+1) {
    		margin-left: 0;
    	}
    }
    @media screen and (max-width: 750px){
    	.box {
    		justify-content: space-between;
    	}
    	.item {
    		margin-left: 0;
    	}
    }

     

    以上、現場からでした。

  • .htaccessで常時SSL化~wwwのありなし統一も添えて

    .htaccessで常時SSL化~wwwのありなし統一も添えて

    .htaccessで常時SSL化・正規化するとき、いつも調べまわるのでいい加減メモ。

    なお、常時SSL化だけやって正規化はやらないというパターンのメリットはないので、どうせなら両方やっちゃいましょう。




    常時SSL化+wwwなし

    一番あるやつ。

    RewriteEngine on
    RewriteBase /
    RewriteCond %{HTTP_HOST} ^(www\.hoge\.com)(:80)? [NC]
    RewriteRule ^(.*) https://hoge.com/$1 [R=301,L]
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

    常時SSL化+wwwあり

    最近あんまりwwwありに統一するパターンは少なくなってきましたね。

    RewriteEngine on
    RewriteBase /
    RewriteCond %{HTTP_HOST} ^(hoge\.com)(:80)? [NC]
    RewriteRule ^(.*) https://www.hoge.com/$1 [R=301,L]
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://www.hoge\.com/%{REQUEST_URI} [R,L]

     

    サーバーによっては記述が違うこともあるかもしれないけど、だいたいはいけるはず…

     

    ちなみにWordPressの場合は、「設定→一般」から「WordPressアドレス」と「サイトアドレス」を両方httpsにして、そのあとパーマリンク設定を更新するだけでOK。正規化は最初からされています。

     

    以上、現場からでした。

  • XAMPPでドキュメントルートを変更し、ルートパスを使えるようにする

    XAMPPでドキュメントルートを変更し、ルートパスを使えるようにする

    Windows使いのみなさん、XAMPP使ってますか?僕はバリバリ使ってます。

    XAMPPはダメだ!という声をよく聞きますが、Webサイト制作という点においては、気軽に使えてめっちゃ便利です。複雑なシステムを組むために、サーバーのチューニングを独自にやらなきゃいけない場合なんかはちょっと厳しいのでVagrantとか使ったほうがいいと思いますが、レンタルサーバー使う程度であればやはりXAMPP最強といっても過言ではないかもしれません。ちょっとPHPの入れ替えがめんどくさいかもですね。

    さてそんなXAMPPですが、ドキュメントルートが”http://localhost/”となっているため、ルートパスを使いたいときなんかに不便ですよね。

    “xampp/htdocs/hoge/”というディレクトリで作業しているとすれば、ドキュメントルートを”http://hoge/”にしたい。あると思います。やってみましょう。




    設定

    触るファイルは、以下2つだけです。

    • C: /xampp/apache/httpd.conf
    • C: /windows/System32/drivers/etc/hosts

    両方とも場所を覚えるのがめんどいので、ディレクトリをショートカットに登録しておくといいでしょう。

    httpd.conf

    これはxamppのApacheの編集ファイルです。このファイルを編集する前に、XAMPPのコンパネでApacheを起動している場合は、停止してください。別に停止してないとぶっ壊れるとかじゃないんですが、ファイルを編集したあとはApacheを再起動しなければいけないので、最初から止めといたほうが忘れずに済みます。

    例えば”xampp/htdocs/hoge”をルートにしたい場合、ファイルの一番下に、以下のように記述します。

    <VirtualHost *:80>
    DocumentRoot "C:/xampp/htdocs/hoge"
    ServerName hoge
    </VirtualHost>

    ちなみに、もっと深い階層でもいけます。

    <VirtualHost *:80>
    DocumentRoot "C:/xampp/htdocs/hoge/www/htdocs"
    ServerName hoge
    </VirtualHost>

    hosts

    こちらは、Windowsのシステムです。権限がないと編集できないことがありますので、管理者権限のあるアカウントで作業してください。

    一番下に、以下のように書きます。

    127.0.0.1 hoge

    hostsファイルにこのように書くと、ブラウザを開いてURLに”hoge”とうつだけで、”127.0.0.1″、つまりlocalhostのIPに接続できるようになります。

    これは、Webに公開されているIPにも適用されます。つまり、サーバーは公開されてるけどDNSがまだ向いていないという環境で作業するときに役に立ちます。WordPressのサーバー引越しとかに使います。

     

    Apache再起動

    hostsとhttpd.confの設定が終わったら、XAMPPのコンパネを開きApacheを再起動しましょう。そしてブラウザのURL入力欄で”hoge”とうつと、”http://hoge”というURLで、”xampp/htdocs/hoge”がちゃんとルートディレクトリになっていることが確認できるかと思います。

     

    作業が終わったら、httpd.confに書いた記述と、念のためhostsに書いた記述もコメントアウトしておきましょう。

    以上、現場からでした。

  • WordPress 固定ページ内でページネーションを使ったら404になる原因と対策

    WordPress 固定ページ内でページネーションを使ったら404になる原因と対策

    あんまりやりたくないパターンだけど、WordPressの固定ページテンプレート内で記事一覧を表示させ、あまつさえページネーションもつけたいというときがある。

    このページネーションの2ページ目以降が404になってはまったけど、動かない原因と対策がわかったのでメモ。




    なぜ404となるのか

    固定ページ内でページネーションを使うと404になる原因についてですが、たぶん以下のような感じだと思います。

    • ページネーションの仕様上、2ページ目とかのURLに、/page/2/とかがつく
    • 例えば/hoge/page/2/のようなパーマリンクになる
    • そんな固定ページはないので、404になる。

    まぁ、固定ページでそもそもページネーションできるようになっていないんでしょうね。そりゃそうよ。

    解決策

    /page/2/みたいにならなければいいんじゃないか。

    WordPressでは、上記のようなURL構造でなくとも、?page=2みたいなパラメータでもページネーションになります。

    ただし、デフォルトだと?page=2にアクセスしても、/page/2/にリダイレクトされてしまう。

    よって、ページネーションのURLの形式を?page=2にして、なおかつ勝手にリダイレクトさせないようにすればOK

    実装

    functions.phpに以下を記述

    add_filter('redirect_canonical','my_disable_redirect_canonical');
    function my_disable_redirect_canonical( $redirect_url ) {
    
        if ( is_archive() ){
            $subject = $redirect_url;
            $pattern = '/\/page\//'; // URLに「/page/」があるかチェック
            preg_match($pattern, $subject, $matches);
    
            if ($matches){
            //リクエストURLに「/page/」があれば、リダイレクトしない。
            $redirect_url = false;
            return $redirect_url;
            }
        }
    
    }

    続いて、ページネーションのほうは以下のようにする。

    <?php
    $paged = (int) get_query_var('paged'); // $pagedを定義。これがないとページネーションが動かないっぽい
    $wp_query = new WP_Query();
    $param = array(
      'post_type' => 'hoge',
      'paged' => $paged
    );
    $wp_query->query($param);
    if($wp_query->have_posts()):
    while($wp_query->have_posts()) : $wp_query->the_post();
    ?>
    ここで記事をループさせる
    <?php endwhile; endif; ?>
    
    <?php
    if ($wp_query->max_num_pages > 1): // ここからページネーション
    echo '<div class="new-pagenation">';
    echo paginate_links(array(
      'base' => get_pagenum_link(1) . '%_%',
      'format' => '?paged=%#%',
      'current' => max(1, $paged),
      'total' => $wp_query->max_num_pages,
      'next_text' => '次へ',
      'prev_text' => '前へ'
    ));
    echo '</div>';
    endif;
    ?>

    paginate_links()というナイスな関数を使うのが肝で、パラメータでURLのフォーマットを設定することができる。他にもいろいろパラメータを設定できる優れもので、僕もこんな関数があることを初めて知りました。具体的な使用方法はWordPress Codexを参照してください。

    次回以降普通のページネーションでもこれ使おう…

    あとは、paginate_links()で出力されるhtmlに合わせ、スタイリングしてやりましょう。

     

    以上、現場からでした。

    これでも動かない場合は、こっちも見てみてね。

    WordPress カスタム投稿でページネーションが404になる原因と解決法

  • jQuery メニューを開いているときはbodyのスクロールを禁止する

    jQuery メニューを開いているときはbodyのスクロールを禁止する

    スマホのハンバーガーメニューとかでメニューが開いているとき、bodyがスクロールするのが嫌な人が多いらしいので、スクロールできないようにする。

    よく実装する割にややこしいので、実装方法をメモ。




    実装

    $(function () {
      /*
      * Menu SP
      */
      var flag = false;
      $('.header-sp__menu a').on('click', function () {
        if (flag == false) {
          bodyFix(); // bodyを固定させる関数
    
          // その他、ナビを開くときに起きるあれこれを記述
    
          flag = true;
        } else {
          closeNavi();
          flag = false;
        }
      });
    });
    
    //ナビを閉じるときの関数
    function closeNavi() {
      bodyFixReset(); // body固定を解除する関数
    
      // その他、ナビを閉じるときに起きるあれこれを記述
    
    }
    
    //以下、bodyを固定する関数
    function bodyFix() {
      const scrollPosi = $(window).scrollTop();
      $('body').css({
        'position': 'fixed',
        'width': '100%',
        'z-index': '1',
        'top': -scrollPosi
      });
    }
    
    //以下、body固定を解除する関数
    function bodyFixReset() {
      const scrollPosi = $('body').offset().top;
      $('body').css({
        'position': 'relative',
        'width': 'auto',
        'top': 'auto'
      });
      //scroll位置を調整
      $('html, body').scrollTop(-scrollPosi);
    }

    bodyを固定する記述、bodyの固定を解除する記述をそれぞれ関数にして、メニューを開くボタンを押したとき、メニューを閉じるボタンを押したときにそれぞれ実行されるようにしています。

    メニューを閉じるときの処理は、いろんなボタンで行われる可能性があるので、使いまわせるように関数化。

    以前、以下の記事でflagを使わずにclickイベントを交互に制御する方法を書いたのですが、

    jQuery clickするごとに交互に処理を行う関数を作ってしまう

    例えば「ハンバーガーメニューをタップするとメニューが開き、閉じるときはメニュー内の”閉じるボタン”をクリックする」のように、別のボタン間で開閉を制御してやる必要がある場合は使えないので、素直にflagを使ってます。

    メニューの開閉、意外とややこしいよね。

     

    以上、現場からでした。

  • WP-Membersの閲覧制限で、カスタムフィールドも非表示にする方法

    WP-Membersの閲覧制限で、カスタムフィールドも非表示にする方法

    WordPressで会員制サイトを作るためのプラグイン「WP-Members」、めっちゃ便利ですねこれ。

    会員登録機能も簡単に作れて、記事に閲覧制限もかけられる。

    ただし、閲覧制限で非表示になる部分は投稿コンテンツ(the_content();)のみなので、カスタムフィールドを使っている場合、カスタムフィールドにも閲覧制限設定を実装する必要があります。

    そんなに難しくないので、サクッとやっちゃいましょう。




    実装

    まず、「記事に閲覧制限をかけているかどうか」を取得します。下記を記事用テンプレートに記述。

    $block_flag = get_post_meta($post->ID, '_wpmem_block', true); // 閲覧制限のチェック

    閲覧制限がかかっていると、”$block_flag”に”1″が、かかっていないと”0″が入ります。

     

    続いて、カスタムフィールドの出力を制御します。

    if( !$block_flag || is_user_logged_in() ) {
      // ここに書かれたものは、「閲覧制限がない」または「ログインしているとき」に表示される
    }

    ややこしい言い回しになってしまいましたが、要するに「閲覧制限をかけていない場合か、ログインしている場合に表示される」というわけで、この中に書いたものは、閲覧制限で非表示になります。

    これを、カスタムフィールドが出力される場所ごとに書いてもいいんですが、面倒だし見づらくなるので、まとめちゃいましょう。

    例えばこんな感じ

    $block_flag = get_post_meta($post->ID, '_wpmem_block', true); // 閲覧制限のチェック
    
    if( !$block_flag || is_user_logged_in() ) {
      // カスタムフィールドの値を先に全部取得しとく
      $custom_url = get_field('custom_url');
      $custom_client = get_field('custom_client');
      $custom_editor = get_field('custom_editor');
    }
    
    // 以下、出力部分
    if( $custom_url ) {
      echo $custom_url;
    }
    if( $custom_client ) {
      echo $custom_editor;
    }
    if( $custom_editor ) {
      echo $custom_editor;
    }

    これで、「ログインしていないとそもそもカスタムフィールドの値を取得しない。カスタムフィールドの値がなければ、出力もされない」というロジックになりますので、コード量を大幅に削減でき、見やすくなります。

    この方法がまかり通らない場合(リピーターフィールド等)は、仕方ないので別個対応してあげましょう。

     

    以上、現場からでした。

  • WP_Queryで「タイトルもしくはカスタムフィールドに一致したら」という条件で検索

    WP_Queryで「タイトルもしくはカスタムフィールドに一致したら」という条件で検索

    WP_Queryでループの検索条件を文字列で絞り込むとき、だいたい以下のように書くと思います。

    <?php
    $wp_query = new WP_Query();
    $param = array(
      'posts_per_page' => '5',
      'post_type' => 'post',
      's' => '検索用テキスト',
      'post_status' => 'publish',
    );
    $wp_query->query($param); if($wp_query->have_posts()):
    // ここに出力を書く
    endwhile; endif; wp_reset_query();
    ?>

    普通は’s’のところに、検索のための文字列を入れますよね。

    ただ、これはデフォルトだとタイトルと投稿内容しか対象にならない。「カスタムフィールドも検索対象にしたいんじゃ!」ってこと、あると思います。

    ここで’s’も’meta_query’も普通に使っちゃうと、AND検索になります。なので、例えば「東京駅」で検索かけたときに、カスタムフィールドには入ってるけどタイトルには入ってないから検索結果に出ないということになっちゃうんですよね。それじゃ困る。

    「タイトルか、もしくはカスタムフィールドにあれば表示する」というOR検索にしたいわけです。

    そんなときは、こうしましょう。




    実装

    以下コードをfunctions.phpに記述

    add_action( 'pre_get_posts', function( $q )
    {
        if( $title = $q->get( '_meta_or_title' ) )
        {
            add_filter( 'get_meta_sql', function( $sql ) use ( $title )
            {
                global $wpdb;
    
                // Only run once:
                static $nr = 0; 
                if( 0 != $nr++ ) return $sql;
    
                // Modify WHERE part:
                $sql['where'] = sprintf(
                    " AND ( %s OR %s ) ",
                    $wpdb->prepare( "{$wpdb->posts}.post_title = '%s'", $title ),
                    mb_substr( $sql['where'], 5, mb_strlen( $sql['where'] ) )
                );
                return $sql;
            });
        }
    });

    そしてループの条件を以下のようにします。これは、カスタムフィールド「station」もしくはタイトルで、「東京駅」という単語でOR検索をかけるときの例。

    <?php
    $wp_query = new WP_Query();
    $param = array(
      'posts_per_page' => '5',
      'post_type' => 'post',
      'post_status' => 'publish',
      '_meta_or_title' => '東京駅',
      'meta_query' => array(
        array(
          'key' => 'station', // 検索をかけるカスタムフィールドのkey
          'value' => '東京駅',
          'compare' => 'LIKE'
        )
      )
    );
    $wp_query->query($param); if($wp_query->have_posts()):
    // ここに出力を書く
    endwhile; endif; wp_reset_query();
    ?>

    これでヨシ!

    以上、現場からでした。

  • jQuery clickするごとに交互に処理を行う関数を作ってしまう

    jQuery clickするごとに交互に処理を行う関数を作ってしまう

    jQueryで’click()’というと、クリックしたときのイベント処理を行うメソッド。

    例えば以下のように使います

    <script>
        $('button').on('click', function() {
            alert('クリックしたぞ');
        })
    </script>

    しかし、これだけでは「クリックするごとに交互に処理を行う」というときに、若干めんどくさい。アコーディオンとかね。

    slideToggleとかtoggleClassでなんとかなるレベルの処理ならいいけど、それ以上のこと、例えばテキストを変えたりしなきゃいけないとき、よく紹介されているのは、なんかflagをfalseにしといて、1回クリックされたらflagをtrueにして、もしflagがtrueだったときはこっちの処理を…とかもうややこしいので、もっとシンプルにやりたい。そうだ、どうせなら関数を作ってしまおうよ。




    関数を作る

    こんな感じで関数を作りましょう

    $.fn.clickToggle = function (a, b) {
      return this.each(function () {
        var clicked = false;
        $(this).on('click', function () {
          clicked = !clicked;
          if (clicked) {
            return a.apply(this, arguments);
          }
          return b.apply(this, arguments);
        });
      });
    };

    これで、’clickToggle()‘という関数が使えるようになりました!関数は一度作ってしまえばどこでも使えます。

    使う

    使うときは以下のように使います

    $('button').clickToggle(function () {
      // 1回目のクリック
      $(this).next('.target').slideDown(300);
      $(this).text('閉じる');
    }, function () {
      // 2回目のクリック
      $(this).next('.target').slideUp(300);
      $(this).text('開く');
    });

    だいぶすっきり書けますね!’hover’とだいたい同じような書き方になる。

     

    昔は’toggle()’という超便利な関数があったんですが、jQuery2以上から使えなくなりました。今でも普通に紹介されている記事いっぱいありますが、使えません。気をつけましょう

    現場からは以上です。

  • WordPress カスタム投稿でページネーションが404になる原因と解決法

    WordPress カスタム投稿でページネーションが404になる原因と解決法

    WordPressで、「カスタム投稿タイプのページネーション2ページ目以降(2ページ目以降じゃなくても、nページ目以降で)が404になる」という現象にちょいちょい陥ったことがあるものの、いつもその場しのぎの応急処置しかしていなかったけど、今回それじゃだめな仕様を実装しなければいけなくなったので、その原因とちゃんとした解決法を調べた。




    現象が発生する条件

    この現象が発生するのは以下のとき。

    1. カスタム投稿タイプの一覧ページで、
    2. WP_Queryによる定義を行っており、
    3. ‘posts_per_page’で1ページの記事表示数を指定していて、
    4. 管理画面の「設定→表示→1ページに表示する最大投稿数」で設定した数値より3の数値のほうが小さいとき。

    つまり、管理画面で「1ページに表示する最大投稿数」を10にしていて、カスタム投稿タイプ”shop”の表示数を5とかにしたい場合、ページネーションがうまく機能しなくなる。

     

    原因

    この原因は、かいつまんで言うと

    WordPressさんが、表示させるテンプレートを決定する前に、管理画面から設定した値を参照する。このときはまだそのテンプレートに書かれたquery_postsは読まれていない。

    そして、テンプレートが読まれquery_postsが読まれた段階でも管理画面から設定した値は参照されたままになっており、2つの値がぶつかり合う

    という感じのようです。

    つまり、例えば

    • デフォルト投稿記事数が20
    • 管理画面からの設定数が10

    だった場合、デフォルト投稿は2ページ目まで表示されます。

    そしてなんと、カスタム投稿タイプもこれに合わせて2ページ目までしか表示されないということらしいです。

    カスタム投稿の記事数が30,管理画面の設定数が5だとしても、どんな値でもデフォルト投稿のページ数になってしまう。

    そういうことか。。。一見ほとんどバグじゃないかと思いますが、WordPressの仕様らしいのでしょうがないですね。

    しょうがないので、解決してみましょう。

     

    応急処置

    ググったらよく出てくるやつ。

    管理画面の最大投稿数を1にする

    シンプルでいいです。確かにこれなら理論上いけますね。

    簡単なテーマやサイトであればこれでいいと思いますが、「いや、それじゃ困る。なぜならデフォルト投稿の表示数も管理画面から設定できるようにしないといけないから」というパターン、あると思います。

    というわけで、もっと自然に解決する方法がこちら。

    自然に解決

    functions.phpに以下を記述

    <?php
    add_filter( 'parse_query', 'custom_per_page' );
    function custom_per_page( $query ) {
      if ( is_admin() || is_singular() || !is_main_query() ) { // 管理画面とsingleとメインループじゃない部分は除く
        return false;
      }
    
      if ( get_query_var( 'post_type' ) == 'event' ) {
          $query->set( 'posts_per_page', '6' );
      }
    }

    そして、テンプレート側では’posts_per_page’を指定しない

    カスタム投稿ごとに表示数を設定したい場合は、単純に増やせばOK

    <?php
    add_filter( 'parse_query', 'custom_per_page' );
    function custom_per_page( $query ) {
      if ( is_admin() || is_singular() || !is_main_query() ) { // 管理画面とsingleとメインループじゃない部分は除く
        return false;
      }
    
      if ( get_query_var( 'post_type' ) == 'event' ) {
          $query->set( 'posts_per_page', '6' );
      }
    
      if ( get_query_var( 'post_type' ) == 'blog' ) {
        $query->set( 'posts_per_page', '5' );
      }
    }

     

    以上、現場からでした。

    こっちの記事もどうぞ

    WordPress 固定ページ内でページネーションを使ったら404になる原因と対策

  • Web制作の効率爆上がり!超便利なChromeの拡張機能10選

    Web制作の効率爆上がり!超便利なChromeの拡張機能10選

    Web制作の際、ブラウザで表示や動作の確認をしますね。ブラウザにはコンソールという機能があり、ページ上の様々な情報を見たりデバッグを行ったりできますが、ブラウザの拡張機能を使えば、より効率的に制作を進めることができます。

    今回は、みなさんの仕事の効率化をお手伝いするべく、僕もよく使っている現場で役に立つGoogle Chromeの拡張機能たちをご紹介。

     

    今回紹介するのは以下の10個。ゆっくりしていってね!

    • Awesome Screenshot
    • ColorPick Eyedropper
    • Page Ruler
    • The QR Code Extension
    • HTMLエラーチェッカー
    • Google Analytics オプトアウト アドオン
    • Tag Assistant
    • Wappalyzer<
    • Web Maker
    • Save to Pocket




    Awesome Screenshot

    さっそくの大目玉、これはもう関わる人全員に使ってもらいたいという拡張機能。Awesome Screenshotは、画面のスクリーンショットを撮るための拡張機能。主に以下のような便利な機能があります。

    Capture visible part of page

    今映っている画面をキャプチャします。

    Delayed capture

    このボタンを押した後、数秒後にスクショを撮ります。マウスホバー時のアクションを記録したいときなんかに便利。

    Capture entire page

    1ページまるまるスクショを撮ることができます。

    Record screen

    開いているページ上でのアクションを録画することができます。無料版では30秒まで。

    さらに…

    これだけでも十分便利なんですが、この拡張機能の真骨頂はスクショを撮ったあと

    なんと、撮ったスクショをその場で編集できちゃうんです!やばい!

    具体的には、以下のようなことができます。

    トリミング

    スクショを撮った画像をその場でザクっとトリミングできる!

    テキスト、枠、矢印の書き込み

    その場でいろいろ書き込める!!

    ぼかし

    その場でぼかしを入れられる!!!

     

    どうですか?やばいですね。僕は残念ながらこの感動を表すほどの語彙力はありません。指示の作成からちょっとSNSにアップしたいとき、超捗りますね!

     

    ColorPick Eyedropper

    画面上の色をピックアップできる拡張機能。

    「この画像に色を合わせて」なんて言われたとき、わざわざ画像ダウンロードしてPhotoshopで開いてスポイトツールで色を拾って…なんてしなくていいんです。

    拡大されてピクセル単位で拾いやすい。

     

    Page Ruler

    画面内で使える物差しツール。

    サイズだけでなく、画面端からの距離なんかも見ることができます。

     

    The QR Code Extension

    今いるページのQRコードをでかでかと表示してくれる拡張機能。

    めっちゃでかいので、離れていてもスマホでスキャンできます。実機で表示確認したいときに便利!

     

    HTMLエラーチェッカー

    ページ内のHTML構造をチェックしてくれる拡張機能。

    「あれ!?CSS完璧なはずなのにめっちゃ崩れとるやん!!」ってときは、タグの閉じ忘れとかで構造がおかしくなっているときが多々あります。

    HTMLチェッカーで構造をチェックしてみましょう。エラーが出ていれば、わかりやすく教えてくれます。

     

    Google Analytics オプトアウト アドオン

    われわれWeb屋は、ページの表示確認や動作確認をするためにページを見て回ったりめっちゃリロードしますよね。

    そういったアクションをGoogle Analyticsに拾われると解析がぐちゃぐちゃになりますので、できれば自分のアクセスはカウントしないようにしたいところ。

    この拡張機能は、ONにしておくと自分のアクセスをGoogle Analyticsにカウントさせないことができます。スニーキングのようなものですね。

    エンジニアブログのアクセスが比較的少ないのは、みんなこれを入れているからに違いありません!!!!



    Tag Assistant

    今いるページで、Google系のタグ(タグマネージャ、Analytics、Adwords等)が正常に機能しているかを確認することができる拡張機能。

    Adwordsのコンバージョンタグを入れている場合は、どのような値が送信されているかを詳しく知ることができます。

    注意点として、上で紹介した「Google Analytics オプトアウト アドオン」を有効にしているとうまく計測されないため、使うときはGoogle Analytics オプトアウト アドオンをオフにするか、シークレットモードで必要な拡張機能だけ有効にして使うと効率的。

     

    Wappalyzer

    今のページの、表からはぱっと見わからない情報を知ることができる拡張機能。

    使っているCMSや言語、サーバー、データベースの種類等、丸見え!

    「このサイト、何で作られてるかわかりますか?」って言われたとき、「たぶんWordPressだと思います」って言えますね!

    地味にすごい。

     

    Web Maker

    これはもう拡張機能というかWebアプリなんですが、ブラウザ上でコードを書いて即座に表示確認できるという神ツール。

    ブラウザ越しにいる誰かに説明するときとか、ちょっと実験してみたいことがあるときとか、いちいちローカル環境構築してとかやってるとしんどいときに使える。

    ライブラリもサクッと導入可能。

    何気にEmmetも使える。

    使い方は無限大です。これを説明しようとするとこれだけで1記事書けるくらいの規模なので、ぜひ皆さんの目で確かめてみてください。

     

    Save to Pocket

    「Pocket」というのはいわゆるブックマークサービスで、「このページええやん!あとでもっかい見よ!」ということができるものです。はてブとは違い、誰かとシェアしたりすることなくこっそり自分だけのリストが作れて、編集も楽という理由で最近よく使っています。

    僕のブログの記事は、はてブよりPocketのほうが多くつく印象です。ちょっとメモして、あとでまた見ようという感じですかね。

     

    話は逸れましたが、こちらはそのPocketをツールバーからワンクリックでブックマークできる拡張機能です。はてブにもありますね。

    これがあれば、PocketのシェアボタンがないサイトでもPocketすることができます。




    おわり

    こんな感じで、ChromeにはWeb制作に役立つツールがいっぱいあります。

    僕も知らないことが多いので、他にもオススメがあれば教えてください!

     

    コーディングも爆速でやって、さっさと定時で帰ってやりましょう!

    初心者がコーディングを3倍速くするために知っておきたい6つの技術

     

    それでは、マッハなWeb制作ライフを。

  • WordPress 「カスタマイズ」内のメニューを非表示にする方法

    WordPress 「カスタマイズ」内のメニューを非表示にする方法

    WordPressの管理画面、「外観→カスタマイズ」内にデフォルトで表示されているメニューたちを非表示にする方法。テーマによって追加で表示されている項目を非表示にする方法も添えて。

    なんだか苦戦しがちな「メニュー」項目も非表示にできました。




    実装

    functions.phpに以下を記述

    // カスタマイズからメニューを削除
    function my_custom_customizer( $wp_customize ) {
      $wp_customize->remove_section( 'add_menu' ); // メニュー
      $wp_customize->remove_panel( 'widgets' ); // ウィジェット
      $wp_customize->remove_section( 'colors' ); // 色
      $wp_customize->remove_section( 'static_front_page' ); // 固定フロントページ
      $wp_customize->remove_section( 'title_tagline' ); // サイト基本情報
      $wp_customize->remove_section( 'custom_css' ); // 追加CSS
    }
    add_action( 'customize_register', 'my_custom_customizer', 20 );

     

    テーマによっては他のメニューもあるかもしれないですね。そんなときは、以下のような流れで実装しましょう。

    カスタマイズ画面でコンソールを開く

    カスタマイズ画面でF12を押して、コンソールを開きます(Chrome)。

    ①非表示にしたい項目にカーソルを合わせ、
    ②<li>のソースを見てみましょう。

    例えば以下のようになってると思います。

    <li id="accordion-section-skin_section" class="...">
    

    この<li>のidが重要。

    今回の場合、

    accordion-section_skin_section

    黄色マーカーの部分”skin_section”を抜粋しremove_section()の引数とします。

    $wp_customize->remove_section( 'skin_section' );

    ちなみに、赤の部分がsectionではなくpanelだった場合、こうなります。

    $wp_customize->remove_panel( 'skin_section' );

     

    これでだいたいどんな項目も非表示にできますね!

    現場からは以上です。