パインウインド

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'] = '記事タイトル１;
Hash['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.引越し元のさくらのブログ

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

b.引越し先のBlogger

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

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くらいだったのでぎりぎり手作業の繰り返しができたけどもっと多いときはやっぱり一覧を用意する方式がいいでしょうね。

登録: 投稿 (Atom)

2017年9月19日火曜日

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

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

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

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

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

get_headerの呼び出し方で対応

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

2017年9月18日月曜日

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

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

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

作業した内容

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

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

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

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

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

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

2017年9月17日日曜日

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

旧ブログをどうするか

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

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

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

2017年5月2日火曜日

開通までの記録

4月8日

4月9日

4月11日

4月12日

4月17日

4月18日

4月28日

4月29日

使い心地

2017年4月23日日曜日

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

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

2017年3月8日水曜日

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

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

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

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

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

実施した手順

感想

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