2017年9月27日水曜日

カスタム投稿タイプでのパンくずリスト対応

前回からの続き

半分自作のパンくずリスト表示コードがカスタム投稿タイプに対応してなかった

前回まででひととおりカスタム投稿タイプ対応はできたかと思ったけど、よく見たらパンくずリストがちゃんと表示されない。カテゴリーのところが空欄になってしまう。

パンくずリストの表示にプラグインを使っていない。ネットを検索して見つけたパンくずリストを表示するソースコードを自分のブログ向けに修正して使っていた。
このコードがカスタム投稿タイプのことを考慮していないコードだった。

パンくずリストを表示するコードはだいたい

if (is_date()) {
...
} elseif (is_category()) {
...
} elseif (is_page()) {
...
} elseif (is_single()) {
...
} elseif ...

という感じになる。
個別投稿での表示は以下のようにしてた。
なお以降のコードでは項目間の区切り文字や<li>とか<span>などは省略しています。

elseif (is_single()) {
  $categories = get_the_category($post->ID);
  $cat = $categories[0];
  if ($cat->parent != 0) {
    // 親子関係をさかのぼる 
  }
  $output .= '<a href="' . get_category_link($cat->term_id) 
             . '">' . $cat->cat_name . '</a>';
...

みたいな感じだったのだけど get_the_category() がカスタム投稿タイプのときに値を返さない。それは当たり前ではある。

カスタム投稿タイプの個別投稿でのパンくずリスト対応

ということで カスタム投稿タイプかの判定があまり良くないとは思うけれど以下のようにした。以前も書いたけど目的のものを得るためにはカスタム投稿タイプやタクソノミー関連は関数が多いので何をどうしたらいいのか調べるのが大変。

$categories = get_the_category($post->ID);
  $cat = $categories[0];
  if (empty($cat)) {
    $cpt = get_post_type();
    $cptobj = get_post_type_object($cpt);
    $output .= '<a href="' . get_post_type_archive_link($cpt) 
               . '">' . $cptobj->label . '</a>';
    $output .= get_the_term_list($post->ID, $cptobj->taxonomies[0]);
  } else {
    // 標準の投稿タイプのときの処理
  }

このコードはカテゴリーの親子関係は考慮していない。
自分のブログではカテゴリーに親子関係を持たせないことにしてるし、過去ブログのインポートのための使っているカスタム投稿タイプなのでとりあえずこれでいいのだ。

カスタム投稿タイプのカテゴリーアーカイブページのパンくずリスト対応

さてこれだとカテゴリーへのリンクがあるけれどこれも実際はタクソノミーなのでタクソノミーを表示するテンプレートが必要となる。それを書いたらそのページでのパンくずリストがちゃんと表示されなかったのでさらにコードに追加が必要だった。

タクソノミーを表示するページでのパンくずリストのためには以下のように  if (is_single()) と同じレベルで if (is_tax()) で判断して表示する。

... elseif (is_category()) {
...
} elseif (is_tax()) {
  $termobj = get_queried_object();
  $cpt = get_post_type();
  $cptobj = get_post_type_object($cpt);
  $output .= '<a href="' . get_post_type_archive_link($cpt) 
             . '">' . $cptobj->label . '</a>'
  $output .= get_taxonomy($termobj->taxonomy)->label 
             . ':' . $termobj->name
}

下の方の get_taxonomy($termobj->taxonomy)->label はいらない人が多いと思うけど一応。

これでやっと自分に必要な最低限のパンくずリストへの追加ができた。

taxonomy.php の作成

taxonomy.phpの内容は 標準の カテゴリー category.php や タグ tag.php とほぼ同じでタイトルを single_cat_title() を single_term_title() にすればいい。

これで「旧ブログを専用のカスタム投稿タイプへインポートする」関連の作業は終了。

たぶんこれでとりあえずOKということにして運用中。旧ブログをインポートし標準の投稿と区別することが目的だったのでこのカスタム投稿タイプに新規投稿などはしないのでこれで十分なはず。

自分、おつかれさまでした。


2017年9月22日金曜日

カスタム投稿タイプのカテゴリーとタグの表示

前回からの続き

カスタム投稿タイプの個別投稿でのカテゴリーとタグの表示

Wordpressでカスタム投稿タイプの個別投稿を表示したらカテゴリーとタグがちゃんと表示されなかった。それは当然で標準の投稿タイプのテンプレート (single.phpから呼び出す)content.php をコピーした content-oldblog.phpにそのあたりの修正をしなかったから。

というわけで以下のように修正する。

<?php the_category(' '); ?>
<?php the_tags('', ', '); ?>
↓
<?php $tax = get_post_type_object(get_post_type())->taxonomies; ?>
<?php echo get_the_term_list($post->ID, $tax[0]); ?>
<?php echo get_the_term_list($post->ID, $tax[1], '', ', '); ?>

こんな感じで。本当はCSSで表示の調整ができるように<div>や<span>を適度に使用しているけどここでは省略した。以下も同じです。

ところでタクソノミー関連の関数がたくさんあって戻り値も複雑で軽く混乱した。
すべてが終わってから考えたんだけどカスタム投稿タイプも標準の投稿タイプのようにカテゴリーとタグを標準で使えるようにすればいいのにと思った。で、the_category() とか the_tags() のような関数もカスタム投稿タイプで使えるようにすれば楽だし統一感もある。the_title()とかはそのまま使えてるわけだし。でカテゴリーとタグだけでは足りない場合にタクソノミーを使えばいいわけで。

サイドバーのカテゴリー、タグ、月別アーカイブのカスタム投稿タイプ対応

カテゴリー一覧とタグ一覧

管理画面のウィジェットにあるカテゴリーとタグクラウドではカスタム投稿タイプのは表示されないので sidebar-oldblog.php にコードを書くことになる。

<!-- カテゴリー -->
<li class="widget widget_categories">
<h2>旧ブログでのカテゴリー</h2>
  <ul>
  <?php wp_list_categories(array(
     'taxonomy' => 'oldblog_cat',
     'title_li' => '',
//     'hide_empty' => false,
    )); ?>
  </ul>
</li>
<!-- タグ --> <li class="widget widget_tag"> <h2>旧ブログでのタグ</h2> <ul> <?php wp_list_categories(array( 'taxonomy' => 'oldblog_tag', 'title_li' => '', // 'hide_empty' => false, )); ?> </ul> </li>

こうして構築中はカスタム投稿タイプへの投稿はすべて非公開にしていたのだけどそうするとカテゴリーやタグが表示されない。そのため確認が行えない。こういうときは 'hide_empty' => false とすれば非公開にしている投稿のカテゴリーやタグも表示される。
で、確認が済んだらコメントアウトした。もちろんその行を削除してもいい。

<li class="widget widget_categories"> とかはサイドバーウィジェットの仕組みに合わせた形にするため。

今思うとパラメータ指定の
'taxonomy' => 'oldblog_cat'
'taxonomy' => 'oldblog_tag'
 のところは上記の single-oldblog.php の修正のように get_post_type_object(get_post_type())->taxonomies;
を使ったほうが汎用性が高まったかな。

月別アーカイブへのリンクリストの表示

<!-- 月別 -->
<li class="widget widget_archive">
<h2>旧ブログの月別アーカイブ</h2>
 <ul>
 <?php wp_get_archives(array(
    'post_type' => 'densan',
   )); ?>
 </ul>
</li>
とする。これにはちょっと気になることがあるけどそれは後の投稿で。

これでサイドバーへの表示の修正は一応完了した。

あとは検索して見つけて使用しているパンくずリスト表示のコードの修正をする。

次回に続く…

2017年9月19日火曜日

カスタム投稿タイプ用のテンプレートを用意しCSSファイル指定の記述をしようとしたら

前回からの続き

インポートしたのでテンプレートを書き始める

Wordpressのカスタム投稿タイプへインポートしただけではどこにも記事へのリンクがない。のでこのままだと直接URLを打ち込むしか投稿を見る方法がない。
この段階ではまだカスタム投稿タイプへの投稿は非公開状態にしているのでまだリンクは用意しない。
Wordpressにログインしていれば
http://ドメイン名/{カスタム投稿タイプ名}
とURLを直接入力すればとりあえず見ることができるのでこれで調整を確認してから公開する。

カスタム投稿タイプの投稿一覧のテンプレートをつくる

まずは一覧表示のために archive-oldblog.php を作成する。
Wordpressは xxxx-{カスタム投稿タイプ名}.php
とすれば該当するカスタム投稿タイプの場合そちらを利用するという仕組みですからね。

これはすでに利用していた 一覧表示用のテンプレートをコピーしたあと修正した。一覧表示では各投稿タイトル・日時・抜粋を表示しているだけなので
ページタイトル表示を the_archive_title() に
抜粋表示を
get_template_part('content', 'excerpt');
↓
get_template_part('content', 'oldblogexcerpt');
のようにカスタム投稿タイプ用のテンプレートを呼び出すようにした程度。

カスタム投稿タイプの個別投稿ページのテンプレートをつくる

つづいて single.php をコピーして single-oldblog.php を作成し内容を修正する。
これも上記同様
get_template_part('content');
↓
get_template_part('content', 'oldblog');
のようにした。

カスタム投稿タイプ用のCSSファイルを用意する だけど…

カスタム投稿タイプであることを判定せずにすます方法を探す

これで最低限の 一覧表示→個別投稿 という流れができた。ここでCSSを追加しようとして考慮不足が発覚した。
通常のCSSファイルを読み込んだ後にカスタム投稿タイプ専用CSSファイルを読み込ませればいいとぼんやり思っていただけだった。

CSSファイルを読み込む記述は<head></head>の中なので header.php ファイル内のことになる。
ということはやっぱりすべての投稿でカスタム投稿タイプかどうか判定することになってしまう。いちいち判定を入れたくないからカスタム投稿タイプを使ったのでこれでは意味がない。

get_headerの呼び出し方で対応

少し考えて get_header() をカスタム投稿タイプ用のテンプレートでは get_header('oldblog') のようにすればいいことに気づいたけどそうすると header.php と header-oldblog.php の内容はほとんど同じでカスタム投稿タイプ用CSSファイル読み込みのための一行があるかないかだけになってしまう。

共通部分を別ファイルにして読み込むという形にするのもやたらファイルが増えてかっこわるい。
すべてをひとつのCSSファイルに入れてCSSのクラスを使って区別するというのがいちばん楽な気もするけどやっぱりCSSファイルは別にしたい。
どうしたものかしばらく考えたけどいい案が浮かばなかったのでCSSファイル読み込みのための一行を追加しただけの header-oldblog.php を用意することにした。
もっといい方法を思いつたら改良したい。

CSSファイル読み込みに関して検索したところ wp_enqueue_style() などを使うのが本来のWordpressの用法だという記事を見つけた。でも最初に勉強に使ったWordpressの本にそんなこと書いてなかったし、自分だけが使うブログなので今のところwp_enqueue_style()などは使わない。


CSSを編集しレイアウトは現ブログと同じにして背景色やタイトルの色などを旧ブログに似た感じにした。

これで完成だと思ったけど

というわけでちょっと惜しいところがあるけれどこれでよしとする。完成だ!と思ったけどよく見るといくつかおかしなところがある。

  • 個別投稿でカテゴリーとタグが表示されない。
  • サイドバーのカテゴリー一覧とタグ一覧が現ブログのものになってる。
  • サイドバーの月別アーカイブが現ブログのものになってる。
  • パンくずリストに抜けが発生している。
まあ当たり前といえば当たり前ですね。
ということでこれらを修正する必要がある。

というわけで次回に続く…


2017年9月18日月曜日

Wordpressでインポートした投稿を区別するためにカスタム投稿タイプを利用した

カスタム投稿タイプ側にインポートしたときの記録

どうやってスマートに通常投稿とインポートした投稿を視覚的に区別するか

Wordpressで現ブログを運営しているところへ旧ブログをインポートしたときに旧ブログであったことを背景色とかで区別しようと思った。
となると現ブログと旧ブログをどのように判定したらいいのか。一番簡単なのは投稿日時で判定することだろう。
でもそれだと現ブログですでに公開した投稿だけでなく今後公開する未来の投稿でも判定することになる。この程度なら技術的にも速度的にもほとんど問題ないだろうけどなんかかっこわるいので避けたかった。

カスタム投稿タイプを使うというアイデア

なんかいい方法はないかなとぼんやり考えているうちに時間は過ぎていった。そしてあるときひらめいた。
カスタム投稿タイプを使えばいいんじゃないか。
そうすればテンプレートファイルはカスタム投稿タイプ専用のをWordpressのシステムが自動的に選択して使うので旧ブログかどうかの判定は必要ない。(あとから考えたらWordpressがカスタム投稿タイプかどうかの処理はあるけど)

これならカスタム投稿タイプのときだけのCSSファイルを追加で読み込んで必要な部分だけ色などを変えればいいじゃない。

とこのときは思ったんだけど実際やってみたらそう簡単な話ではなかった。それはおいおい書く予定。

作業した内容

いったん通常投稿とインポートする

このとき現ブログの延長としてすでに旧ブログをインポートしていた。ただ旧ブログは公開状態にしていなかった。カテゴリーとタグを現ブログにあうようにひとつひとつ調整はしていた。

カスタム投稿タイプを使うことにしたので、このすでにインポートしていた旧ブログの投稿をあとでエクスポートして使うことになる。

カスタム投稿タイプの作成

Wordpressでカスタム投稿タイプを使うにはfunction.phpに以下のようなコードを追加すればいいのだけど今回はプラグイン形式にした。これは単にやってみたかったからというだけの理由。自分しか使わないので必要最小限の記述。
function.phpではなくWordpressのプラグインディレクトリにそれなりのファイル名.phpで置いてからWordpressのプラグインメニューから有効化する。

/**
 * Plugin Name: Oldblog Post Type
 * Description: Custom Post Type for Old blog
 * Author:      kenji2199
 * Version:     0.1
 */
// ********************************
// カスタム投稿タイプ'densan'を設定
// ********************************
function create_post_type_oldblog() {
 // **********************
 // 旧ブログ専用投稿タイプ
 register_post_type(
   'oldblog',
   array(
     'label' => '旧ブログ',
     'description' => '旧ブログからインポートした投稿',
     'public' => true,
//     'show_in_nav_menus' => false,
    'show_in_admin_bar' => false,
     'has_archive' => true,
     'supports' => array('title', 'editor', 'excerpt', 'author', 'comments'),
     'menu_position' => 5,
     'taxonomies' => array('oldblog_cat', 'oldblog_tag'),
   )
 );

  // ********************
  // 旧ブログ専用カテゴリ
  register_taxonomy(
    'oldblog_cat',
    'oldblog',
    array(
      'label' => 'カテゴリー',
      'description' => '旧ブログ用のカテゴリー',
      'hierarchical' => true,  // trueなので階層あり、つまりカテゴリ
      'public' => true,
//      'show_ui' => true,
//      'show_in_nav_menus' => false,
      'show_admin_column' => true,
      'show_tagcloud' => false,
      'update_count_callback' => '_update_post_term_count',
    )
  );

  // ****************
  // 旧ブログ専用タグ
  register_taxonomy(
    'oldblog_tag',
    'oldblog',
    array(
      'label' => 'タグ',
      'description' => '旧ブログ用のタグ',
      'hierarchical' => false, // falseなので階層なし、つまりタグ
      'public' => true,
//      'show_ui' => true,
//      'show_in_nav_menus' => false,
      'show_admin_column' => true,
      'show_tagcloud' => false,
      'update_count_callback' => '_update_post_term_count',
    )
  );
}
add_action('init', 'create_post_type_oldblog');

本来はきちっとパラメータを設定するのが正しいのだろうけど個人ブログであり自分しか使わないのでこれで十分。
基本的にデフォルトの値で十分なところは記述せず、ほんとに最低限必要なところだけ書いている。でもpublicだけは一応明示した。

カスタム投稿タイプの投稿管理画面

あとカスタム投稿タイプの設定の仕方を調べていくと管理画面にカテゴリとタグが表示されないので追加する方法という記事が見つかった。それもしないといけないかなと思ったけれど公式の regsiter_taxonomy() のパラメータの説明に show_admin_column を trueにすれば表示されるとあったのでそれを使った。
ただこれだとカテゴリーとタグの幅が広くてタイトルの幅がちょっと狭くなる。なにか調整する方法はあるとは思うけど今回の旧ブログ用のカスタム投稿タイプに新たに記事を追加しないのでそのままとした。

カスタム投稿タイプへインポートできるようにデータを修正

うまく行ったら今度は旧ブログをインポートする。すでに通常の投稿としてインポートしてあった旧ブログデータをエクスポートする。
それをそのままインポートしても元に戻るだけでカスタム投稿タイプ側にインポートされないのでエクスポートしたデータを少しいじる必要がある。

エクスポートしたファイルは .xml なのでテキストエディタでいくつか修正する。
まずはカスタム投稿タイプへインポートされるように CDATA[post] を CDATA[oldblog] に変更する。
<wp:post_type><![CDATA[post]]></wp:post_type>
↓
<wp:post_type><![CDATA[oldblog]]></wp:post_type>
さらにカテゴリーとタグもカスタム投稿タイプ側になるように修正する。
<category domain="post_tag" nicename="abc"><![CDATA[エービーシー]]></category>
<category domain="category" nicename="xyz"><![CDATA[エクスワイゼト]]></category>
<category domain="oldblog_tag" nicename="def"><![CDATA[デーイーエフ]]></category> <category domain="oldblog_cat" nicename="uvw"><![CDATA[ユブイダブル]]></category>
これらはエディタの置換機能であっという間ですね。
こうして修正したデータをWordpressにインポート。

コメントがインポートされない

ただコメントがインポートされなかった。通常の投稿タイプだとコメントもインポートされたんだけに残念。コメントは基本あきらめることになる。
ただ数が少なければコピー&ペーストで入力したあと管理画面のコメントから日時・作成者・メールアドレスを修正することで再現できる。入力したIPアドレスはここから修正はできないけど。

インポートは終了し後は調整だけのはずだった

あとは通常の投稿タイプの方にインポートした投稿を削除したらとりあえずの作業は終了。
あとはCSSの追加だけ… と思ったら考慮不足があったし、その先もまたいろいろやることがあって大変だった。

次回に続く…



2017年9月17日日曜日

ウェブリブログから移転の際にrel="canonical"をタグを設定した話

ウェブリブログからWordpressにブログを移転したけどウェブリブログへの投稿は消すつもりはなかった。こういうとき内容が重複する投稿が出来てしまうので検索エンジンには移動したことを伝えたほうがいいらしい。
一番正しいのは301リダイレクトすることだけどウェブリブログではそれはできない。無料ブログサービスはたいていそうだと思われる。

次点としてHTMLに
<link rel="canonical" href=".....">
を記述することになる。
ただそれもウェブリブログではできない。

なにか方法はないかと検索してみたけどウェブリブログから引っ越したという記事はほとんど見つからない。そんな中ひとつ有用な記事を見つけることができた。
JavaScriptで埋め込むという方法だ。ウェブリブログならJavaScriptを使える。この方式だとHTMLに直接書いてあるわけではないけれどクローラーはJavaScript実行後のHTMLを見てくれるようだ、とその記事にはかいてあったのでそれを信じることにした。

この記事を見つけてから実際に作業するまでずいぶん長いこと期間を開けてしまったらその間にこの記事がサイトごとなくなってしまった。でもJavaScriptのソースは控えておいたのでここにそのソースを置こうと思う。たぶん問題ないよね。

<script type="text/javascript">
var Hash = new Object();
Hash['1'] = '記事タイトル1;
Hash['2'] = '記事タイトル2';
var URL = "";
var meta = "";
for (var key in Hash){
  if(document.title.indexOf(Hash[key]) != -1){
    //meta = "<link rel=\"canonical\" href=\"http://example.com" + key + "\">" ;
    var meta = document.createElement("link");
    meta.setAttribute("rel", "canonical");
    meta.setAttribute("href", "http://example.com/" + key);
  }
}
document.getElementsByTagName("head")[0].appendChild(meta);
alert(document.head.innerHTML);
</script>

見ての通り特別なことはしていない。
Hash['1']='記事タイトル1';
配列の'1'の部分に移転先のURLからドメインを取ったものを、'記事タイトル1'の部分にウェブリブログでの記事タイトルを記述する。
ウェブリブログでの投稿数が多いと大変かもしれないけどエクスポートで出力されたデータをエディタなどで置換とかをすればそんなに苦労はしない。

このコードをウェブリブログのフリースペースに置けばいい。「表示項目設定」から「サイドバー表示項目設定」にある。フリースペースは4つあってどれを使ってもいいと思う。
一応の注意点として
  • コードを記述したフリースペースは「□表示」にチェックを入れるのを忘れないように。
  • 「フリースペース3」は反映が翌日になること。それ以外は即反映される。
  • フリースペース3に記述するとブラウザでHTMLのソースコードを表示するとこのコードがそのまま見えるけど「フリースペース」「フリースペース2」は別ファイルから読み込む形になるのでHTMLのソースコードでは見えない。
  • 実行後ブラウザでHTMLのソースコードを見ても<link rel=....>は見えない。F12を押すなどして開発者ツールからみると埋め込まれているのを確認できる。
がある。

これを移転先ブログで引っ越した記事を公開直後に実施した。


ウェブリブログに投稿した記事をWordpressにインポートしたとき意外と大変だった話

ウェブリブログからWordpressへ引っ越したときの概要

何年も前にウェブリブログ(旧ブログ)を使っていたけど数年前にWordpress(現ブログ)に移行した。そのときから旧ブログの投稿を現ブログにインポートしようと思っていた。ただちょっと面倒なので引越しに関する情報だけ集めてた。

そして先日思い切ってインポートしたんだけど多少の手間はあっても簡単に終わるとおもった。ただちょっとしたこだわりを入れたら意外といろいろなことをやらなきゃいけなかった、というおはなし。

旧ブログをどうするか

現ブログに移行しても旧ブログは削除せずそのままにしておくことにしていた。なんとなくもったいないし入り口が多い方がいいだろうから。
とすると同じ内容のブログがふたつあることになる。Googleさんはそれをあまり良しとはしてないらしい。ひとつの投稿の文字数がそんなに多いわけではないし閲覧数もごくわずかな自分のブログはそんなこと気にしなくても良さそうではある。
でも一応ちゃんとしておきたい。車がほとんど通らない道でも信号はちゃんと守る、みたいな感覚。

こういうとき301リダイレクトというものをやるのがいちばんいいらしい。けどウェブリブログではそれはできない。次点でrel="canonical"という指定をHTMLのhead部に書けばいいらしいがそれもできない。
検索するとブログの引越しに関する記事はおおいけれどウェブリブログからの引っ越しはほとんど見つからない。そんな中ひとつみつけた記事でJavascriptでhead部に書き込むという方法。なるほど。GoogleさんもJavascript実行後のhead部を見ると書いてある。
といわけでそれを採用。

旧ブログから現ブログへインポート

ウェブリブログがエクスポートしたデータ形式はMT形式。とくに問題はない。テキストエディタで写真のリンク先を修正するぐらい。
写真もダウンロードして現ブログ用のサーバーにアップロード。
インポートしたらカテゴリー・タグ変換ツールを実施。ウェブリブログにはカテゴリーやタグというものはなく代わりにテーマというのがある。これがたしかタグとして取り込まれるのでカテゴリーに変換し現ブログに合うように調整。そのときタグも追加する。
変換は一発でできるけどカテゴリー・タグの調整は記事ひとつずつ行ったので時間がかかった。
この時点では引っ越してきた記事はまだ非公開の状態。とりあえずこのまま公開してもいいんだけどやりたいことがあったので(それは次項で)。
ここまでやってしばらく放置してた。

旧ブログからインポートしたことを明確にしたい

引っ越してきた旧ブログの記事と現ブログで書いた記事を区別できるようにしたい。記事画面の上になにか文言をいれるとか背景の色を変えるとか。
そしてその違いをどう判定するか。投稿日時が旧ブログ最終記事以前であれば旧ブログと判定するのがいちばん簡単なんだろうけどこれだとこれから新しく書く記事すべてでも常に判定する処理が入るのでなんかかっこわるい。
これをどうしたらいいか解決策を思いつくのに時間がかかった。

カスタム投稿タイプを使うというアイデア

どうしたらいいかとずっと思っていたところ思いついたのがWordpressのカスタム投稿タイプという機能。これなら判定処理は必要ないと思った。カスタム投稿タイプ用に背景の色を変えるCSSを追加で読み込ませるようにテンプレートに書くだけだ。
これはいいアイデアを思いついたと思って実行したのだけどこれが簡単ではなかった。全く別のブログの開発するのに近い手間がかかってしまった。

CSSの変更は背景色だけというわけには行かないし、カスタム投稿タイプ用のカテゴリー・タグを表示するテンプレートを用意しないといけないし、サイドバーも全く別のものになるし。自分のブログにさえ対応していればいいと作ったパンくずリストも改造がひつようだし。
まあおかげでWordpressの知識は増えました。ほかに活用する機会は無いけど。

そんなこんなを次の投稿からもう少し詳しく書いていこうと思う。


2017年5月2日火曜日

NURO光開通!その記録

4月にNURO光が無事開通した。

去年のうちから申し込んでから開通するまでどんな作業があってどれくらいの時間がかかるのか調べていた。
申し込んでから開通までは1ヶ月くらいの場合もあれば2~3ヶ月くらいの場合もあるようなのでWiMAXを解約する7月までに開通できるようにと4月に申込んだ。

4月は世間的に新生活が始まる月だし5月には連休もあるし工事が多くて時間がかかるのではないかと思っていたけど4月中に開通した。

開通までの記録

4月8日

NURO光の公式サイトから申し込み。この申込で住所などを記入する流れで宅内工事の希望日時が指定できる。家の事情もあって4月18日午後に宅内工事を希望した。

すぐに登録した連絡先メールアドレスにSO-NETのメールアドレスの本登録確認メールがきたので登録。SO-NETのメールアドレスを取得。
メールアドレスはとったけどこの段階でユーザーIDは不明。へたなことしないようにそのままにしておいた。

4月9日

連絡先メールアドレスに宅内工事実施日の連絡がきた。希望通りの日時だった。SO-NETのマイページから進捗状況がわかるとあったけどユーザーIDがわからないので見ることはできない。たぶんよくある“ユーザーIDを忘れたら”のリンクから操作していけばわかるんだろうけどなにもせず。

4月11日

NURO光担当から屋外工事の日程を決めるために電話がきた。ネットで調べたとき屋内工事をしたときに屋外工事の日程を決めるとあったように思ったのだけどその前だったのでちょっと驚いた。
4月29日を勧められたのでそのまま受け入れた。開通月は無料なのでこの日だと無料期間が無いのも同じだと思ったけどなるべく早く開通してほしかったし連休に入ると遅くなりそうなので(確認しなかったけど)まあいいかと。

4月12日

SO-NETからはがきが到着。申し込んだコースなどの通知と一緒にユーザーIDやパスワードなどが書いてあった。それをみてSO-NETのマイページを確認した。

4月17日

屋内工事担当の方から電話。18日午前でもいいかと言われたけど午後にしてもらった。

4月18日

屋内工事実施。室内の電話口を開けてみるとチューブがあったけど外壁の電話線入り口にはチューブが見当たらない。なので光ケーブルを壁の中を通すことを諦めて外壁を這わし壁に穴をあけて部屋に通すことになった。
そのためちょっと時間がかかったんだろうけど無事工事終了。
ONUに光ケーブルを差し込むのも工事のうちだった。

4月28日

宅外工事担当の方から電話。予定通り29日の午後に他での工事が終わってこちらに来る前に電話するとのこと。

4月29日

宅外工事実施。まず少し離れた電柱から作業が始まり、家の近くの電柱での作業、電柱から外壁への作業という流れ。ケーブルをつなげるだけと思ってたんだけどそれぞれでの作業が意外に時間がかかっていた。しかし簡単に作業してあとでトラブルが発生するよりかはそのほうがもちろんいい。

工事が終わった瞬間からネットが開通!

使い心地

さすが光回線!はやい。
WiMAXで使っていたときはリンクをクリックしてから表示開始までわずかだけど間があった。画像の多いページは順番に表示してるなという感じだった。
光にしたらリンクをクリックしたらすぐに表示開始される。そして画像が多くてもほぼ瞬時に表示される。

WiMAXも速度制限がかかってないときはそんなに遅くはないんだけどやっぱり光回線の速さはすごいね。

NURO光は最大2Gbpsを謳っているが実際の速度はそこまでではないとわかっている。とはいえある程度の速さは期待して通信速度を測定するサイトで測ってみたら思ったほどではなかった。たまたまその時調子悪かったのか自宅の地域ではこんなものかわからない。

だけど待たされる感じがほとんどなくいい感じで使えていてとっても満足している。

2017年4月23日日曜日

WiMAXから光回線へ移行することにした

WiMAXの2年契約更新をきっかけにネット環境を見直し

現在、WiMAXを自宅の固定回線として使っている。だからルーターはURoad-Home2+でありこれはAC電源専用なので持ち歩いて使うことはできない。最初から持ち歩いて使うつもりはないのでこれで問題ない。

さて、今度の7月にこのWiMAXの更新月を迎える。これまでキャンペーンで2年間で月3696円(税抜)で使っていたのだけど更新月を過ぎたら月4880円(税抜)※となる。

※WiMAX契約時に受けた説明の記録では月4880円となってるけどUQ WiMAXのサイトを見ると現時点では月4380円になってる。

もともとWiMAXを固定回線で使っていた理由はふたつあってひとつは工事の必要が無いから、もうひとつは料金が光回線よりは安いからだった。

でも、更新月を過ぎてからは光回線とは料金的にたいして差がない。だったら工事の手間があるけど光回線にしようと決めた。

工事の手間が…と書いたけどじつは部屋の片付けが大変という方が本当のところ(^o^)
その部屋の片付けも少しづつ進めていった。

7月にWiMAXを解約するときにはすでに光回線を開通済にしておく必要がある。光回線は工事があるので申し込んでから開通するまでのそれなりに日数がかかるし何か問題が発生する可能性も考えて4月に申し込みをすることにした。

WiMAX速度制限の仕様が変更されたけど

ネット環境の見直しを去年のうちから考えていたらWiMAXの速度制限の仕方が変わるという案内が年末に出た。

変更前
3日間で3GB以上利用したら翌日の昼から翌々日の昼間でYouTubeが見られるくらいの速度に制限

変更後
3日間で10GB以上利用したら翌日の18時頃から翌々日の2時頃まで1Mbpsほどに速度制限

この変更は制限がかなり緩和されているようにみえる。これなら光回線への移行をしないことも検討しようかと思った。でも2月になって実際にこの運用に変わったら使いにくいものになってしまった。

自宅でそれなりの通信量があって変更前は常に速度制限を受けてる状態だったけどその状態でも使ってて遅いと思うようなことはなかった。
変更後でも制限を受ける条件に当てはまったのだけどこれがまあ遅い。

Windows 10のタスクマネージャーを見てると変更前は速度制限時で4Mbpsくらいだったのが変更後は案内通り速度制限時で1Mbpsになっている。これが思った以上に遅くて画像が多めのサイトを見ると表示完了まで時間がかかってしょうがない。

もともとWiMAXから光回線へ移行することにしてたけどこれがとどめとなった


2017年3月8日水曜日

「さくらのブログ」から「Blogger」へ引っ越すときの“canonical”に関する処理

投稿データのエクスポートとインポート

さくらのブログであるブログを書いていたけど思うところあってBloggerに引っ越した。(もちろんこのブログのことではない)

さくらのブログで書いていた投稿をエクスポートして形式と時間を変換してBloggerにインポートした。さくらのブログのエクスポートはMT形式、Bloggerのインポートできる形式はXMLなので変換してくれるサイトを使わせてもらった。また投稿時間もタイムゾーンの関係でずれてるのでこれも変換してくれるサイトを使わせてもらった。
そうしてインポートした投稿はとりあえず下書き状態にしておいた。

検索エンジンにパクリでなく引っ越しであることを明示する方法の検討

さて、同じ内容のブログがふたつになったときはパクリではないことやどちらがメインであるかを検索エンジンにわかるようにしておいたほうが良いということなので対策をとらないといけない。
引っ越しの時点での投稿数は100くらいで見ている人も少ない自己満足的なブログなのでそんなこと気にしなくてもいいじゃないかとは思ったけど技術的興味もあったし。

理想的なのは301ダイレクトだそうだけどそれはしなかった。.htaccessファイルの書き方をちゃんと理解するのに時間がかかりそうだったし、たぶんだけどさくらのブログではできない。それに別のウェブリブログで書いたブログの引っ越しも考えていてそれもこのやり方は使えないから。

rel="canonical"を使うことにしたけど

HTMLの編集できないブログでもJavaScriptで埋め込むことができるということで
<link rel="canonical" href="">
を挿入することにした。

このやり方は"引越し元の投稿"と"引越し先の投稿のURL"を1対1で対応させる必要がある。最初に知った方法では「引っ越し元の記事のタイトルが一致した配列から引越し先URLを取り出して上記href部分に埋め込む」という形式だった。
これだと"引越し元のタイトル一覧"と"引越し先URL一覧"を用意する必要がある。これだと投稿件数が多いと大変なのでもう少しいい方法を探した。

さくらのブログではHTMLの編集が可能でここに"投稿のタイトルを取得する変数"を使えば"引越し先URL"一覧があればなんとかなりそう。
と思ってarticle.subjectを使って簡単なJavaScriptで試したところエラーになってしまった。article.XXXXXは<head></head>のあいだでは使えないからだった。
投稿タイトルの代わりに日時を取得して…とも考えたけど同じ理由で使えない。

本来の使い方と違うけどkeywordsを使う

さらにいろいろ調べていくうちにシーサーブログで無理やりWordpressのカスタムフィールドに相当するものを使う方法というの見つけた。それは検索エンジンは見ていない<meta keywords="" content="">に使うためのキーワード入力欄を使う方法だった。
なるほどこれは使える。
さくらのブログも同じブログシステムだしキーワード入力欄に入力した文字列はextra_keywords変数に入り<head>の部分でもちゃんと使える。

そしてこの文字列と同じになるように引越し先投稿のURLのパーマリンクを設定すれば"引越し先投稿のURL"の一覧も必要ないということに気づいた。

さくらのブログでは投稿記事のURLはランダム風のIDにしかならないのでこれを"引越し元のキーワード入力欄"と"引越し先投稿のパーマリンク"に設定すればいい。
ただこれだと一覧を用意する必要はないけれど全記事に対してひとつひとつ設定をしていくことになるので時間と手間がかかる。

Blogger側で設定するときの注意点

引越し先となるBlogger側でのパーマリンクは"/yyyy/mm/設定した値.html"となるので引越し元のキーワード入力欄には "yyyy/mm/設定した値"を入力する必要がある。

またBloggerでパーマリンク設定したあとそのまま保存や公開すると投稿日時がその時点のものになってしまうのでスケジュール入力欄で"日付と時刻を設定"にチェックを入れておく必要がある。インポートしたデータの日時になっているので改めて入力する必要はない。

実施した手順

ということで以下のような手順で設定した。

a.引越し元のさくらのブログ

  1. 記事の編集画面を開く。
  2. URLから記事IDをコピー
  3. それをキーワード入力欄に"yyyy/mm/記事ID"という形式で入力。
    例 "2017/03/123456789"

b.引越し先のBlogger

  1. 記事の編集画面を開く
  2. コピーした記事IDをカスタムパーマリンクに設定する。
  3. スケジュール(公開日時を引越し前の投稿のものにする)


a.b.を繰り返してすべての記事に対して行う。

さくらのブログの設定→デザイン→HTMLでHTMLの編集画面にして<head></head>の間に
<%- if:page_name eq 'article' -%><%- if:extra_keywords -%><link rel="canonical" href="引越し先BloggerのURL/<% extra_keywords %>.html" /><% /if -%><% /if -%>
を挿入する。

感想

投稿数が100くらいだったのでぎりぎり手作業の繰り返しができたけどもっと多いときはやっぱり一覧を用意する方式がいいでしょうね。


2017年2月8日水曜日

dlvr.itによるtwitterへの自動投稿でtwitterカード表示にならない理由がやっとわかった。大した理由じゃなかった。

どうしてもエラーが出てた

あるサイトだけ更新情報をdlvr.itでトラッキングのためのパラメータが付加された状態でtwitterに投稿してもtwitterカード表示されなくて困ってた。
twitterカード検証ツールでもトラッキングのためのパラメータがあるときはエラーになった。

Fetching the page failed because it's denied by robots.txt.

こんなメッセージが出る。robots.txtはWordpressで余計なクロールをされないようにしてあるけど記事や画像は弾いてないのに、というかrobots.txtって関係あるの?と思っていた。

さらに検索して調べてたらやっと原因がわかった。

Wordpressで余計なクロールをされないための記述は何年か前にいろいろ検索した結果を元に書いていた。その中ある指定がtwitterカードを表示させなくしていた。

Disallow: /*?*
Disallow: /*?

この記述だ。URLにパラメータを付加したものは弾くようになっている。dlvr.itがトラッキングのためのパラメータを付加したらこれで弾かれてたのでtwitterカードが表示されなかったわけだ。
twitterカードの表示にrobots.txtって影響あるんだとやっと理解した。

あらためてrobots.txtを確認してみるとちょっと過剰に制限していたみたい。なので上記の記述を無くしたのはもちろんもっとシンプルにした。

この修正をしたら過去の投稿も含めてtwitterカード表示されるようになった。わかってみれば大した理由じゃなかったわけだけどそのへん詳しくないから思い至らなかった。

これでおしまい

ということでtwitterカードに関してはこれですべて完了となりました。



2017年2月6日月曜日

tumblrを更新したらdlvr.itにtwitterにカード表示で投稿する方法を模索

まずは特に設定せずにtumblrの更新をdlvr.itを通してtwitterに投稿してみる

tumblrをtwitterカードに対応させるにはtwitterで認証させるだけでいい。tumblrには設定やカスタマイズは必要ない。

tumblrを更新したらdlvr.itでtwitterに自動投稿する。特に変わったことする必要はないが、dlvr.itの設定で「Post As Photo」はオフにしておいたほうが良さそう。

という調査結果をもとに設定などをした
その結果twitterカード表示されなかった。

tumblrのURLがリダイレクトされるのが原因なのか?

twitterに表示されるurlは「dlvr.it/DDDDD
twitter的には「t.co/TTTTT」
となっている。

これらを直接ブラウザにURLを貼り付けて表示させると「AAAAA.tumblr.com/post/NNNNN/BBBBB」
のようになる。
またRSSフィードを直接見るとURLは
「AAAAA.tumblr.com/post/NNNNN」
になっている。

上記URLをtwitterカード認証ツールに通すとうまく表示されるのは「AAAAA.tumblr.com/post/NNNNN/BBBBB」
だけで、他はエラーになる。エラーメッセージは
ERROR: Fetching the page failed because it resulted in too many redirects.
とある。
AAAAA.tumblr.com/post/NNNNN → AAAAA.tumblr.com/post/NNNNN/BBBBB
このリダイレクトがエラーになるのが一番の原因なのだろうか。

それでもdlvr.itを通したい

twitterに自動投稿するだけならdlvr.itを通さずにtumblrにもともとあるtwitter連携機能をオンにするだけでいいのだ。
ただこのtwitterにはほかのサイトの更新情報も投稿するので区別のために頭に「tumblr更新:」という文字列を加えたい。となるとやっぱりdlvr.itを通したい。

となるとtumblrのURLのリダイレクトをなくす方法があればいいことになる。tumblrの設定にはそんな項目はない。
しかしtumblrの各投稿のURLのパーマリンク(tumblrではフレンドリーURL)を自分で設定することができるのでそれをすればリダイレクトのないURLになるかもしれない。
と思って試したらそうではなかった。
AAAAA.tumblr.com/post/NNNNN → AAAAA.tumblr.com/post/NNNNN/BBBBB
となる。ただtwitterの認証ツールに通すとエラーにならない。

ここで本当のエラー原因らしきものがわかった。エラーしていたのはBBBBBの部分が日本語だったからみたい。

どうすることにしたか

BBBBBの部分は投稿内容からtumblrが自動で抜き出しているから日本語になるので英数字になるようにしなくてはいけない。
そのためにはtumblr投稿時にパーマリンク(フレンドリーURL)を自分で設定すればいい。これは手間が増えていまひとつすっきりしないけれどいまのところこれしかない。
tumblrではない別のサイトの更新時も毎回URLを英数字で決めていたのである意味慣れてはいるし。

どうなったか

カード表示になるときとならない場合がある。
どうやら画像があるとうまくいくがテキストのみだとカード表示にならない。
HTMLソースをみたらtwitterカードのためのコードがなかったのでこれがtumblrの仕様のようだ。

少し不完全だけどtumblrのtwitterカード対応の件はこれでおしまいにします。




2017年1月29日日曜日

TumblrをTwitterカードに対応させ、自動ツイートもIFTTTからdlvr.itに変更した

TumblrをTwitterカードに対応させる

Twitterカードに対応させる方法を調べてたらたまたまTumblrの対応のさせ方を見つけていた。
それはTumblrは設定・カスタマイズといったことをなにもしなくてもTwitterの検証ツールを通すだけでいいらしい。

そこでTumblrのHTMLをみたらたしかにTwitterカード向けの記述があった。ということでTwitterの検証ツールに通したので対応したはず。

TumblrからTwitterへの連携をdlvr.itに変更

Tumblrを更新したらTwitterに更新したことをIFTTTを使って自動ツイートするようにしてた。IFTTT経由でツイートするとIFTTTの短縮URLになる。これもTwitterカードは認識するのかな?と思いつつふとこのURLをクリックしたらTumblrのページが開かなかった。

TumblrのURLに日本語が含まれていてそれをうまくデコードできていないみたい。でもこれまでうまくいかないという話は聞かないなと思ってたのでちょっと確認をした。
Windows 10のEdgeだとURLがおかしくなってIFTTTの短縮URLをクリックしてもTumblrのページが表示されないけれど、chromeで同じ短縮URLを開くとTumblrのページが表示された。Edgeだとうまくいかないみたい。

たぶんIFTTTは悪くなくてEdgeの方がだめなんだろうけどこうなってしまうのなら別の手を考えるしかない。といってもそんな大げさのことではなくTumblrを更新したらdlvr.itで自動ツイートするように変更した。

ただdlvr.itの短縮URLに日本語が含まれていても大丈夫なのかはまだ検証していないのでこれでいいのかはまだわからない。



2017年1月28日土曜日

dlvr.itでtwitterに自動投稿してもtwitter cardがうまく表示されなかったのは設定のせいかもしれない

dlvr.itによる投稿でTwitterカードが表示されないことについて


dlvr.itでTwitterに自動投稿したけれどカード表示されなかった。ただ画像だけが表示されて概要が表示されないのだ。

で、いろいろ調べたところdlvr.itの設定にある「Enable Photo Posting」や「Post As Photo」のせいかもしれない。これはデフォルトでオンになっている。
これはたぶん投稿した記事内になる画像を自動で付加してるものみたい。

WordPressで投稿した記事に画像がないときFaviconの画像が表示されるが概要は表示されない。画像があるときはその画像が表示れてやはり概要は表示されない。
どちらもTwitterカードの形式になっていない。

また全く別のブログも書いていてそれもTwitter Cardsに対応させたのだけど、こちらは全体にほぼ画像がない。
このブログの場合、記事に画像がないときはTwitterカードがちゃんと表示される。しかし、記事に画像があるときはその画像が表示されて概要は表示されなずTwitterカードの形式になっていない。

このことからdlvr.itが自動的に投稿した記事から画像を取り出してTwitterで表示させようとしているように見える。そしてこういう形で画像を付加するとTwitterカード形式での表示にならない。

ということでdlvr.itの「Enable Photo Posting」「Post As Photo」の設定のせいでTwitterカード形式で表示されないのではないかということになる。

とりあえず両方の設定をオフにした。これでうまくいくのかはまだ実践していないのでわからない。厳密にどちらの設定の影響なのか調べたいところだけどテスト投稿を頻繁にするわけにもいかないので機会待ちの状態だ。

トラッキングのためのパラメータ付加がTwitterカードに影響するのか


もうひとつdlvr.itがトラッキングのためのパラメータをつけることがTwitterカード形式で表示されることに影響するかもしれないのだけどなんだかすっきりしないでいる。

一方のブログに書いた投稿のURLにトラッキングのためのパラメータがついたものをTwitterの検証ツールで試すとエラーになってしまう。
だけど他方のブログではトラッキングのためのパラメータをURLに付加していてもエラーにならない。

これにはどんな違いがあるのかわからずにいる。とりあえずどちらもトラッキングのためのパラメータを付ける設定にして様子を見ることにする。こちらもまだ実践していないので正確なことは言えない状態だ。

追記:

上記の設定で画像は表示されなくなったがTwitterカードの表示はされなかった。こんどはトラッキングのためのパラメータを付加しない設定で試してみる。
ちなみに過去のIFTTTで投稿されたツイートを改めて見てるとTwitterカードがちゃんと表示されていた。過去のツイートもTwitterカード表示されるんですね。

さらに追記:

Twitterカード形式で表示されない原因が判明。それは
に書いた。


2017年1月23日月曜日

ブログからツイッターへの連携をIFTTTからdlvr.itに変更した

運営してるサイトを更新したらツイッターに更新したことをツイートする、っていうのは今は当たり前のことといえるんでしょうね。でも自動でツイートするとなるといろいろな手段があってどの方式にするか悩みどころ。

ずいぶん前にdlvr.itを使っていたけどIFTTTに切り替えてました。なぜそうしたのか覚えてない。せっかくのこのブログの意味が無いね。

IFTTTから切り替えた理由

で、先日ブログ更新したことの自動投稿をIFTTTからdlvr.itに戻した。理由はGoogle+にも投稿できるから。
ブログ更新情報をGoogle+へ自動投稿するためだけにHootSuiteを使っていた。だけどときどきログインしないと投稿されないときがあったので使うのをやめた。本来の使い方とはちがうからしかたがない。

Google+へ投稿する機能があるサービスは少なく、あっても有料なことが多い。だけど最近ふとdlvr.itを思い出して確認してみたらGoogle+への投稿が普通にできることがわかったので切り替えたというわけ。

IFTTTは面白い仕組みだし有効活用したいんだけど今のところ自分にとっていい使い方が見つかっていない。

dlvr.itの初期設定

基本設定はウィザード形式で簡単に行える。

  1. dlvr.itのアカウントをとる
  2. ブログのFeedのURLを入力する
  3. Twitterアカウントを入力し認証する。
  4. Google+アカウントを入力し認証する。

これだけ。ただTwitter Cardsへの対応するためには少し設定を変える必要があった。

Twitter Cardsに対応するための設定

※2017年1月27日追記:以下の設定に関して書いてることはちょっと違いがあるみたいなので別の投稿(dlvr.itでtwitterに自動投稿してもtwitter cardがうまく表示されなかったのは設定のせいかもしれない)に記述する。

設定を変える前の最初の投稿はTwitter Cardsが認識されなかった。ただTwitter Cards表示用に指定した画像はツイッターの画像添付の形式で表示された。

dlvr.itの短縮URLでは認識されないのかと思って短縮されない設定にしてみたけど変化なし。

そこでTwitter Cardsの検証ツールでTwitterに投稿されたURLを確認してみたところエラーになった。じつはURLにdlvr.itのトラッキング用パラメータがついていてこれがあるとTwitter Cardsに認識されないことがわかった。ということでこのトラッキング用パラメータがつかないように設定を変更した。まだ試していないけどこれで大丈夫のはず。

このトラッキング用パラメータを外すにはFeedやTwitter、Google+の各個別設定のところではなくルート設定から行う。あるFeedからソーシャルサービスへの連携の単位をdlvr.itはルートと表現してる。

dlvr.itアカウントをメールアドレスで取ったかTwitterアカウントで取ったかで違う?

ただこのトラッキング用パラメータの設定があるのはdlvr.itにメールアドレスでアカウントをとった場合で、ツイッターアカウントからこのアカウントをとるとこの設定はないみたい。


その他の設定

Twitter、Google+各投稿の頭に「トピックス更新:」という文字列を付加するようにした。ブログ記事のタイトルだけ投稿されるよりもブログ更新情報であることを明確にするため。
これはルート設定からもできるしTwiiter、Google+ごとの個別設定からもできる。


2017年1月22日日曜日

WordPressで運用している個人サイトをTwitter Cards対応にした

先日、自分が運営してる個人サイトをTwitter Cardsに対応させました。

一度ずいぶん前にTwitter Cardsに対応させようとして調べたらFacebookがどうのこうのとあって面倒そうだったのでやめちゃいました。Facebookのアカウントをとる気がないし。

で、最近ふとやっぱりなんとかならないかなと思ってもう一度調べたら別にFacebookとは関係なく対応できることがわかりました。Facebookの仕組みも使うことができるってだけであったのでした。しかもHTMLのMETAタグを数行追加するだけだし。

とはいえちゃんとやろうとするとやはりそれなりに手間がかかりますね。その記録を書きます。WordPressでの対応のさせ方となります。あと比較的簡単なことであればプラグインなしで対応せたいのでプラグインは使っていません。

Twitter Cardsには数種類あるけど今回は一番シンプルなSummaryにしました。
twitte.com → 開発者 → Learn about discovering and embedding Tweets → Twitter Cards → Learn More about Twitter Cards → Summary Card
によると以下の5行を追加するだけ。

<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@ツイッターユーザー名" />
<meta name="twitter:title" content="タイトル" />
<meta name="twitter:description" content="概要" />
<meta name="twitter:image" content="表示する画像のURL" />

twitter:card

<meta name="twitter:card" content="summary" />
summaryはTwitter Cardsの種類なのでそのまま書くだけ。

twitter:site

<meta name="twitter:site" content="@ツイッターユーザー名" />
ツイッターユーザー名も自分のtwitterのユーザー名を書くだけ。

twitter:title

<meta name="twitter:title" content="タイトル" />
タイトルは記事のタイトルなのでWordpressならget_the_title()を使えばいいんだけどトップページのときはサイトのタイトルにするためにbloginfo('name')にします。
と書いてから気づいだんだけどひょっとしてbloginfo()を使わなくてもget_the_title()でもいいのかな?
if(is_home()) {
 $title = get_bloginfo('name');
} elseif(is_single()) {
 $title = get_the_title($post->ID);
} elseif(ispage()) {
 $title = get_the_title($post->ID);
} else {
 $title = get_bloginf('name');
}
<meta name="twitter:title" content="<?php echo $title; >" />

twitter:description

<meta name="twitter:description" content="概要" />
概要は個人サイト構築時にget_meta_description()というのを作成していたのでそれを利用。Wordpressの本だったか検索して見つけたかどっちだったか忘れましたがそれを自分のサイトに合わせて変更したものを使ってます。
これはdescriptionを記事、固定ページ、カテゴリページ、などにあわせた内容を返す関数をfunction.phpに記述してあります。

そのまま使うだけのつもりだったんですが一言書いた後にYouTubeへのリンクを書いた記事があってそれだとそのURLが表示されてしました。それではまずいだろうとURLを削除する行を一行追加しました。

このURLを削除するってPHPやWordpressの関数にありそうでないんですね。検索しても見つけられませんでした。HTMLのタグを消す関数はあるみたいですが。
で、PHPの置換関数で削除したのですがURLの正規表現を検索するとなかなか複雑。ちゃんと意味を理解してから使いたかったのですが解読するのが面倒だったので自分なりの簡易的な正規表現を使うことにしました。厳密な表現をする必要はないので。

とりあえず
$str = preg_replace('^https?://[\w./?=&%-]+^', '', $str);
こんな感じで。もちろんこの前にstrip_tags()などの処理を行ってます。

if(is_home()) {
 $description = get_bloginfo('description');
} elseif(is_single()) {
 $description = get_meta_description(); /* 自作関数 */
} elseif(is_page()) {
 $description = get_meta_description(); /*自作関数 */
} else {
 $description = get_bloginfo('description');
}
<meta name="twitter:description" content="" />

twitter:image

<meta name="twitter:image" content="表示する画像のURL" />
これも内容にあわせて何を指定するか調整しなければいけません。
個別記事以外はサイトをイメージした画像、例えばロゴとかFaviconとかを表示させます。
個別記事のときがちょっと面倒でアイキャッチ画像があればそれを、なければ記事に貼り付けた最初の画像を、なければサイトのイメージ画像にします。

サイト構築時に「記事の最初の画像」を表示するコードを作ってあったのでそれを使います。これは検索してweb上で見つけたものを使ってます。
get_children()とwp_get_attachment_image_src()を使ってURLを得ています。

if(is_home()) {
 $image = get_template_directory_uri() . '/images/XXXXXXXX.jpg';
} elseif(is_single()) {
 if(has_post_thumbnail()) {
  $image = wp_get_attachment_image_url(get_post_thumnail_id(), 'medium');
 } else {
  $attachments = get_children(
    "post_parent=$post->ID&post_type=attachment&post_mime_type=image");
  $att_images = array_reverse($attachments);
  $att_image  = array_shift($images);
  if($att_image) {
   $image = wp_get_attachment_image_url($att_image->ID, 'medium');
  } else {
   $image = get_templage_directory_uri() . '/images/XXXXXXXX.jpg';
  }
 }
} elseif(is_page()) {
 $image = get_template_directory_uri() . '/images/XXXXXXXX.jpg';
} else {
 $image = get_template_directory_uri() . '/images/XXXXXXXX.jpg';
}
<meta name="twitter:image" content="" />

コードのまとめ

上記のコードで無駄があるように見えると思いますがmetaタグごとに記述したからでこうなったのであって実際にはif文をひとつにまとめて記述しています。
if(is_home()) {
  $title = get_bloginfo('name');
  $description = get_bloginfo('description');
  $image = get_template_directory_url() . '/images/XXXXXXXX.jpg';
} elseif(is_single()) {
 $title = get_the_title($post->ID);
 $description = get_meta_description();
 ...
のように。

このコードをtwittercard.phpとして保存し、header.phpのの間に
<?php get_template_part('twittercard'); ?>
を追加することでTwitter Cardsに対応できました。

Twitterに申請

で、ただ上記のmetaタグを入れただけではだめでTwitterに申請しないといけないらしいので早速実行した。

うまく表示されるか確認することができるページがあるのでそこで確認。
twitte.com → 開発者 → Learn about discovering and embedding Tweets → Twitter Cards → Learn More about Twitter Cards → validator tool (日本語のページなら:検証ツール)

以前はエラーがなければ申請する必要があったらしいけど、現在はこの検証ツールで正常に表示されるだけでOKになる。たぶん申請の数がものすごく多くて承認作業が大変になったからじゃないだろうか。

Twitterに投稿して実際の表示も確認できたのですべての作業はこれで終わりました。




2017年1月15日日曜日

3年ぶりの更新その2 自分のモバイルの現状

久しぶりの更新ということで、現状確認2回目モバイル編。といってたいしたことないけど。

スマートフォン

前まではF-12CとイオンSIMを使っていたけど、今はXPERIA Z SO-02Eとb-mobile おかわりSIMとなっている。
スマートフォンは買い替えた(中古)。SIMはb-mobileの都合でイオンSIMからおかわりSIMへとある意味自動的に変更。正確には申込みが必要だったけど手数料とかはなし。

タブレット

去年、BIGカメラ専売のSG080iBKをアウトレットで購入。Twitterやちょっとホームページ見るのにスマホだと小さいしPC起動するのはなんか大げさだしということで買った。
だけどWindows10のアップデートをしてしばらくしてからタッチパネルが反応しなくなって困ってる。USBポートにキーボードやマウスをつなぐと使えるのでそれで操作してる。

ただ自分の使い方だとタブレットは今ひとつだった。こうしてちょっとしたブログを書くときにも使えたらと思っていたけどそれをやるには画面が少し狭いことやソフトキーボードを使うとなるとちょっとやる気がおきない。

できれば2in1タブレットPCがほしいなと思っている。


2017年1月14日土曜日

3年ぶりの更新 自分のPC関連の現状

このブログをいつの間にか更新しなくなって気づいたら3年も経ってた。

PCハードの現状

3年経ったけれどハードはほぼそのまま。
たぶんデュアルモニターのひとつをフルHDにしたこととUSB3.0拡張カードをつけた。
あとHDDを1TBのものに交換し、ファイルのバックアップ用にUSB外付けHDD1TBのものもつけた。
マウスの調子がわるくなったので交換した。
プリンターも購入した。

PCソフトウエアの現状

Windows 10にアップグレードして最新バージョンにしてある。
インターネット全盛の今アプリはあんまり入れてない。

ネット上のサービス

OneDriveとかGoogle Driveとかはそれなりに使ってる。TwitterとかIFTTとかいったものもそれなりに使ってる。
現在はレンタルサーバー上にWordpressをインストールして使っているのがメインだけど、このブログやTumblrなども使っている。

ネットワーク

現在はWiMAXのホームルータを使っている。

予定

なんとか自分のPC関連の記録として再開したいと思う。