Wordpress

02/22　Ps Auto Sitemapのためにpageの記事ID、投稿IDを知るには

Ps Auto Sitemapで不要なpageを表示させないためには

記事IDを入力する必要があります。

ectoでは記事のIDがViewerに表示されますのでそれを使って入力しますが、

同期エラーでViewerに表示されない記事がありそれをどうやって知るのか？

という問題がありました。

パーマリンク設定/カスタム構造　でpost_idを設定している場合には

postは投稿一覧/編集/パーマリンク　で知ることができます。

pageはパーマリンクを個別のスラッグにしてる場合が多いので知ることができません。

そこで下記のプラグインを使って、固定ページ一覧にIDを表示させて

非表示のpageを指定することができました。

Advanced Columns

[From WordPress › フォーラム » ページIDの確認]

[From Advanced Columns | $equipress]

02/08-3　Wordpressプラグインとアプリを組み合わせてテーブルを便利に更新編集するには2

ectoの起動時にViewerで見えるpageがRetrietive Pageとすると

見えなくなってしまうのがわかりました。

とするとこのページ群のデータが壊れている可能性があります。

02/01以後に新たに作ったページはRetrietive Pageでシンクロできますので、

ここに原因があるのではないかと見当をつけました。

Retrietive後

Retrietive Pageでは 29 → 9 この9ページではシンクロできます。

Retrietive Postでは 1409 → 0 サーバエラーがかえってきますので。

WordPress、ダッシュボードでは、記事数、ページ数が別々に表示されます。

ectoでは別々に表示することができません。

これだけの記事とページを削除するかコピペして新しく作る必要がある訳です。

方向性が見えてほっとしました。

──────────後日談

カテゴリー未分類を比べてみると

ダッシュボード 82　ecto 33 で、これだけで49の差があります。

pageを直したら次にカテゴリーを一個ずつ直していけば良い

という事もわかりましたのでこちらも方向性が見えてきました。

──────────後日談2

ここまで修正しましたが、まだまだありますね。

このpageの差の分はすでに使用しているので削除できませんから、pageの修正はここまでで

あとはpostをこつこつなおしていくようでしょうね。

02/08-3　Wordpressプラグインとアプリを組み合わせてテーブルを便利に更新編集するには

ブログを書いているときに、表現するためにはどうしてもテーブルを使いたくなります。

そのテーブルを使うと、行、列、セルの編集がさらに必要になり、

ブログのアップロード、頻繁な編集では能力を発揮するectoでも手におえない場合は

OpenOfficeとフロントエンドエディター、TinyMCE Advancedを使って

便利に編集をしていました。

去年末に全データ消失 → 再構築の途中に

Web ⇆ ecto間でテーブルデータのやり取りを繰り返す機能が使えなくなりました。

Retrieve Postを行うと ecto/Activity Viewerでは

「サーバーはリクエスト処理を完了できませんでした。」というエラーが出ます。

Consoleのログを読んでみると、Postのデータのやり取りを全くしていません。

データの同期以前にエラーが発生しています。

クローンのテストサイトでは成功しますから、賢威が原因でもありません。

ectoのPost +Pageの数 = 1352

Webの　　〃　　　　 = 1435

と投稿数に差異がありますので、そのせいでシンクロできないエラーが

発生しているものと思われます。

多分それは2011/12頃に集中しているものと狙いをつけて

重複データを削除してみたいと思います。

このバグを取るという作業が地味で根気がいり、しかも時間がかかる作業です。

01/29　サイトブログデータの復旧で大変苦労しています3

ブログデータの更新はecto ⇆ サイト間でアップロード、ダウンロードを

繰り返す訳ですが、サイト上の記事数 ＞ ecto上の記事数になってしまい、

ectoとサイト上の記事が同期エラーになりました。

記事の復旧作業中に間違った操作を下可能性があります。

ectoの便利で優れた機能、Retrieve Posts,Retrieve Page,エントリを取得の

三つの機能が使えない訳です。

いずれかの記事がダブっている可能性がありますので、これを一個ずつ外して

同期が出来るまで繰り返さなければなりません。

ちょっと大変な作業です。

01/26　サイトブログデータの復旧で大変苦労しています2

去年のクリスマスにサイトデータをすべて消去することになってから一ヶ月経ちました。

それから、必要最小限の業務時間のほかはすべて復旧の時間当てて、

探しきれない写真データや、それに類するデータのほかは出来るだけもとに戻して

概ね復旧が終わってほっとしました。

次はブラウザで最初から表示して表示のおかしい点を探すことと、

リンク、掲示板、データ倉庫などの不具合点のメンテナンスをしていこうと思います。

ectoでテキストデータのバックアップがあったのは助かりましたが、

記事IDの情報がクリアされていますのでそのままアップは出来ません。

AppleScriptを使いたかったのですが、全部手作業で一個ずつコピペになりました。

邸名ごとに写真データを保存してあったもののそれを探すのにも時間がかかりました。

過去にさかのぼって記事を直していると当時の考えと現在では

考えが違いますのでつじつまが合わなくなることもしばしばで混乱しました。

ともあれ、なんとか復旧しました。

──────────サイト訪問者へお願い。

不具合ある箇所を見つけられた方はご連絡いただけると助かります。

01/22　ectoとフロントエンドエディターの連係では

ectoで反映出来ない効果ではテーブルの行、列の追加、削除、着色があります。

その作業をブラウザでTinyMCE Advancedを使ってしてからectoに取り込む

という作業をしていたのですが、ectoで取り込みエラーがでるようになりました。

賢威 + ecto + TinyMCE Advancedの組み合わせが悪いのかもしれません。

ectoで編集してアップロードした方がブラウザ上より遥かに作業が楽ですので

やむを得ずプラグインを外して、ectoのみでテーブルを操作することにしました。

フロントエンドエディターの新バージョンでは、ブラウザ上で

行の挿入、セルの統合などが出来ますので代用が可能です。

1. ectoでテーブルを作成してアップロード
2. フロントエンドエディターでブラウザ上で編集
3. その変更データをectoにダウンロード

という作業の繰り返しが今までのように出来たらいいなと思います。

01/20　サイトブログデータの復旧で大変苦労しています

2011/12に悪意ある者にArras Themeの脆弱性（function.php）を突かれて

深刻な不具合がWebサーバーに生じる可能性があったものですから、

当時のデータを全部消去しました。その後復旧に鋭意つとめています。

1000超のpost、pageを復旧するのに手間がかかり大変苦労しています。

テキストデータ、掲示板はお正月休み中にectoに保存してあったデータをもとに

復旧できたのは不幸中の幸いでした。

しかし、写真データはectoに保存されていませんから、iPhoto、サブサイトから

引っ張ってきて復旧する必要がありました。

過去のフリーの時代に書いてあったブログ（ライブドア、press9ほか）などを

探してみると2005年から書いていましたのでそれを統合する作業もありましたので

さらに手間がかかることになりました。

また、未分類が1000超のカテゴリー分けもあります。

同一カテゴリーが600以上あると、賢威のサイトマップが正しく表示されないようです。

現在は2009/06まで復旧しています。全部の写真データをチェックしながら

戻すには一月一杯で仕上げたいと思っています。

01/13-2　全角スペースをはさんだ複数語検索では。賢威

サイト内検索でArras Themeは全角スペースをはさんだ複数後検索ができませんでした。

Arras Themeでエラーになった「アコーディオン」を検索したところ、ヒットしました。

また、全角スペースをはさんで検索してもヒットします。

日本語に対応しているのが助かります。

01/09　賢威5.0ではページで掲示板を作れない

今年からThemeを賢威5.0のコーポレート版にしました。

私はpageのコメント機能を使って掲示板を作っているのですが

この賢威5.0にはpageにコメント機能はありません。

こまりまして、サポートフォーラムをのぞいたところ

comments.phpを新たに作り、それをpage.phpに読み込ませて解決した。

という発言がありました。

comments.phpを新たに作るのはphpがかけないと出来ないなと思っていましたが

single.phpにはコメント機能があり、page.phpにはないのは

読み込ませる構文の有る無しではないか？と考えてソースを見たところ

comments.phpを読み込む構文がsingle.phpにあるのを見つけ、

page.phpにコピーしたところ、固定ページにコメント欄を作成できました。

解決したのは、HTML文中にコメント文が日本語であったからでもですし、

サポートフォーラムのヒントもあったからでした。

この賢威5.0はソースの中に機能を追加、削除しやすいように

日本語でコメント文が書いてあります。それが大きな助けになりました。

テーマのレイアウトがシンプルで訪問者に使いやすくなってもいるとも思います。

賢威のメリット

• 日本語のコメント文が構文中にあるのでカスタマイズで間違いにくい。
• サポートフォーラムがあるのでミスを解決しやすい。
• SEOに付いての詳細な解説書があるので思い込みを防げる。
• 各記事のタグに自動的にリンクが張られる。
• HeadSpace2と同等の処理を自動で行う。

さらに掲示板を作っていく途中での問題がありました。

50発言を超えたところで次のページが作成できず、真っ白になります。

ここでまた何かミスをしてしまったなと考えていたところ、

カテゴリー分けをあとでやるつもりで記事の投稿を未分類で投稿し続けて

未分類が600投稿あたりでサイトマップに表示されなくなりました。

記事数が多くなったので表示されないなら、

掲示板の発言数を減らせばよいのではないかと思い、

ダッシュボード/設定/コメント設定を 50 → 25にしてみたら

次ページが表示されました。

ちょっと多すぎだったのですね。解決しました。

ＳEＯの効果を得るためにtitle | sitename としていたのですが、

HeadSpace2の設定をしてリロードしたところ

title | sitename | sitename とサイトネームがダブってしまうことに気がつきました。

あれ？変だなと思って、HeadSpace2の機能を停止したところ、

title | sitename と希望通りに表示されました。

ということは、賢威にその機能があった訳です。

HeadSpace2を機能させないですみました。

01/06　URLの日本語表示（日本語の投稿スラッグ）ではパーセントエンコードされてしまう

投稿のスラッグ（ブログ記事のURL）に日本語が含まれると

URLをコピペしたときなどに文字コードがUTF-8だと、

パーセントエンコードされてしまいます。（％と英数字の羅列）

URLからはどの記事だか、予想がつきませんし、長ったらしく不便です。

それを防ぐためにWordpress/ダッシュボード/設定/パーマリンク設定 で

カスタム構造、/%year%/%monthnum%/%day%/%category%/%post_id%/

としています。

本当にこれが正解かはわかりませんが、Wordpress本サイトでは

categoryで始まるパーマリンクは非推奨ですし、

投稿の名前（postname）は日本語ですし、

記事数が多いと投稿スラッグを決めていてもバッティングする可能性があります。

そこで、まずバッティングしない記事IDと後で自分が見たときにわかりやすい

日付を入れることにしました。

本当はもっと短い方がいいんですけどね。