|
分かりにくくてスミマセン。
これはノウハウ集でも何でもなく「ぼくのわーどぷれすにっき」なので…
開発系WP
どうだろ、あった方が良いんじゃないかと思う。
ただ、レンタル鯖にMySQLのデータベースが一つしかないので、本番系・開発系で同一のデータベースに存在する、というあまり居心地の良くない状況になるが。
2009/09/23
現時点において、3系統立っている。
一つ目はプロトタイプで一番最初にインストールしたもの。これは消す予定。
次に今後の開発系となるべきもの。
最後に今見ている本番系。
本番系への移行だが、デフォルトの機能のエクスポート・インポートを利用。そのため、プラグイン等は全て一から設定し直し。もしかしたらもう少しクールでスマートな方法があったのかも分からんが。
ちなみに、ローカルで立ち上げない理由だが、イチイチXAMPPでApache・MySQLを立ち上げるのが面倒、という理由から。
また、ローカルのPCだと何時クリーンインストールを行なうか分からなく、その度にインストール・状態復旧を行なうのも面倒だし。
および、ほとんどあり得ないと思うが、「ローカルでは動いてもレンタル鯖で動かない」という悲しい状態を避けるため。
レンタル鯖の転送量制限に引っかかるにはマダマダ足りないし、やりたい時にすぐにできるのはありがたい。
とは言うものの、あまり開発系の必然を感じないのも事実で、やはり本番系で「えいや」とライブデバッグみたいな事を相変わらずやっている。
2009/10/12
開発系は、後述する「中規模改造、2009年11月末実施」以降、放置している状態。
そうでなくとも、本番系と開発系では導入プラグインに差異があるし、本体・プラグイン共、開発系はほとんどアップデートしていない。投稿も中途半端だがこれはテストデータなので許されるとしても、業務においてこれ程いい加減だと間違い無く銃殺モノだが。
但し、必要な時は必ずあるだろうから、規模の大きな改修が入った場合に、一から構築するよりは効率的かなと。場合によってはクリーンインストール直後の状態が欲しいと言う場合もあるかもしれないが。
なので、このまま放置することとする。
2010/02/11
トップページ
「ブログ」という枠に捕らわれなければ、例えば、トップを(投稿に相対する)ページにして更新日時順にブログ・ページ、場合によってはWebサービスRSS取り込み更新日時順、みたいな方法も考えられるのだが、実装方法がまだ良く分からない状況。
2009/09/21
ページテンプレートの使い方が何となく分かった。
なお、該当テーマにアップロードするだけでなく、「リフレッシュ」に相当する工程を踏まなければ、ページ作成時、アップしたテンプレートが選択できない…んじゃないかと思う。
2009/09/23
Tumblrとの棲み分け
現時点でメインにpostしているTumblrとWordPressに関して、二つの面から。
一つ目は、あくまでもTumblrを「スクラップブック」として捉えた場合、(半)永久的な状態ではなく、あくまでもフローの情報なので、これらの投稿をストックと言うか、まとめておきたいなぁという欲望が出てくる。
自分のTumblrの中で大半のpostを占めるdeviantARTに関して、実験的にdeviantARTの投稿をまとめてみて、それなにりイイカンジだったのだが、問題は、手動をベースにしているので面倒な点があるのと、Tumblrに投稿したサムネールを掴んでいるので*、サイズに統一感が無い、という問題がある。
とは言え、例えばTumblrに投稿したイメージのサイズを統一化させるためにImageMagicで、となると、ちょっと対応に時間がかかるかな、という状況。
二つ目は、このサイトを見ての通り「日記」は基本的には放棄したので、日記的な記事をTumblrからこちらにマージする必要ってあるかなと。
強いて言えば日記的な投稿は、Tumblrのテキスト(regular)が該当するので、そちらをここに移行する可能性はある。
結構重い記事が多い気がするが。
2009/09/20
別途Asaphを立ち上げて現在調査中。
2010/02/27
Slug・Permanent link
デフォルトで作成される
http://hoge.com/?p=123
だが、気になって色々と調べてみた結果、例えばExport、truncate tabale、importするとID、この例の場合だと123が変わるそうだ…(未確認)
だからと言って、テーブル構造&データの持たせ方を確認して、IDが辻褄が合う様にupdateする方法は、システム的によろしくない模様だし、そもそもテーブルキーをupdateするってちょっと気持ち悪いし。
いずれにせよ、それは困ると言う事で、パーマリンク設定を「/%postname%.htm」に変更。
かつ、.htaccessをWordPressの仰せの通りに設定。
Slugに関しては、日々日記を書いている訳でも無いので煩雑でも無く、大半が過去ログのコンバートがメインで、ファイル名(= Slug)と投稿タイトルが分離していたので特に過度の作業は発生せず。
結果、
http://hoge.com/hoge.htm
になる訳だが、後述するページに分割していると、
http://hoge.com/hoge.htm/2
…と、ちょっと気持ち悪いURLになってしまうが、「見なかった事にする」
2009/09/21
ページ送り?
…と言うのか?
一覧で表示される「続きを読む」は、<!–more–>があるが、ページ送りってどうなんだろうと思って調べてみたら、<!–nextpage–>というのがあった。
これは後述する脚注にも対応していて、そのページ内の脚注はそのページで完結している。
注意点としては、テーマに下記みたいな記述が無いと表示されない模様。
<?php
wp_link_pages('before=<p>&after=</p>&next_or_number=number&pagelink=page %');
?>
および記事を追加する場合、最後に追記しないとURLがずれるよな、コレ。
欲を言えば、全てのページに<!–more–>までの情報が表示されると嬉しい。
また、ページ数だけのアンカーリンクだけでなく、次のページのタイトル、例えば次のページ(もしくは逆に前のページ)で一番最初に出てくるhタグを持ってくるとか。確かどこかのIT系の情報サイトで見た記憶があるのだが…
その辺、弄れば何とかなるのかもしれないが。
ところで<!–more–>であるが、テンプレートによっては一覧には、抜粋を利用していたり<!–more–>までの記述を利用していたりと、ちょっと扱いに困っている。取り敢えず全ての投稿に抜粋を追加したけど。
その辺は、the_excerpt() と the_content() の比較参照。
抜粋(the_excerpt())の利用においてちょっと気になるのは、個別の投稿はともかく、ページには抜粋が入力できない事かなと。
2009/09/30
Page Excerptを使えば、通常の投稿と同様にページも扱える。
尚、抜粋は全て削除。WordPressに勝手に作成してもらう方針で。
2009/10/15
脚注
Blosxomの頃は脚注(footnotes)が使えるのか使えないのか分からなかった。
なので使わずに—こういうカンジですけど—と記述していた。(短い文字列の場合は括弧に記述、みたいな)
Blosxom以前に使っていたハイパー日記システムにはFNコマンドがあり、多用していたので、Blosxomに過去ログをコンバートする時は結構面倒だった。
勿論あるだろうと思っていたが、WordPressにはWP-Footnotesがあるので使い始めた。
例えば*、みたいな。
尚、テンプレートへの修正は生じていない。
過去ログの変更が生じる訳だが、気が向いたものから逐次「明日から本気出す」状態。
2009/09/30
外部テキストファイルのinclude
テンプレートにおいてのハナシ。
できるみたい。
via WordPress › フォーラム » 外部ページにWordPressの固定ページをインクルードしたい
<?php
$res = file_get_contents("wordpress/about/");
print $res;
?>
file_get_contentsはPHPコマンドであり、引数であるファイル名はhttp://～でも絶対|相対ファイル名でも指定可能。
…と言うか、PHPコーディングできるという事は、SQLも記述できるだろうから(多分)、何でもアリアリじゃんコレ、みたいな。
ちなみにWordPressでは通常、テンプレートファイルにPHPのコードを記述する訳で、その分、テンプレートが必要になるので、詰まる所、テーマを変更する度にテンプレートも引越作業を行う必要がある。
面倒ではある。
それを回避する一つの方法として、通常の記事に直接PHPをコーディングが可能になるno sq — runPHP Plugin for WordPressがある。
こちらはまだ未導入だが。
何か…ちょっと抵抗があって…セキュリティ的に。多分問題無いとは思うけど。
これでかなり表現方法が広がった気がする。
2009/10/04
携帯電話での表示
ずばりKtai Styleを。
以前のBlosxomの場合だと、フレーバーを別に作成して、別のURLに誘導していたが、WordPressの場合だとプラグインで実装できる。
おそらくは、最初にUser Agentを見て、このプラグインに誘導してるんじゃないかと思うが。(ソースを見ていないので憶測)
なので、既存のテンプレートを修正したりという様な手間は発生していない。
2009/10/04
無視している訳では無いが*、Apple電話iPhoneの場合は、多分、Ktai Styleは適用されてないんじゃないか?
このサイトを見るであろうiPhoneユーザは分かっているだけで2名思い浮かぶのと、電車の中・街中でもそれなりに「黒いアレ」を見かけるので、そろそろ導入しておかないとマズいかなぁと。
とは言うものの、何せこちらで確認する術が無い事も無いので*、あまり優先度の高いタスクではない状態ではあるが、WPtouchを導入して、アナウンスしますのでそこんとこよしなに。
2009/10/31
hタグ
そもそもhタグって何の略かと。
ans. とほほのＷＷＷ入門
Blosxomの時の見出し構成。
h1 … サイト名(and | or 個別ページの場合、投稿記事タイトル etc)
h2 … 投稿日時
h3 … 投稿記事タイトル
h4 … 以下任意
これに対して、WorPressの場合の構成。
h1 … サイト名(and | or 個別ページの場合、投稿記事タイトル etc)
h2 … 投稿記事タイトル
h3 … 以下任意
何が言いたいかと言うと、BlosxomとWordPressでは、文書構造の考え方が違っている?
全てのテーマがこの規則に沿っている訳でも無いが。*
BlosxomにあってWordPressに無い、h2タグを投稿日付とするか否かの差が存在するため*、コンバートされた記事は、h1・h2・h4・h5…という階層になっている。
さすがにこれをコンバージョンする気にはなれないが…目に付き次第対応かなと。
2009/10/04
SIMILE Timeline
冗談で調べてみたのだが、あるんだと…
WordPress Plugin: SIMILE Timeline at freshlabs journal
無茶苦茶楽にそれっぽく設定できた。
とりあえずエラーは出ていない。
ちょっと気持ち悪いのは、どのページを見てもSIMILE Timelineの本家までJavaScriptのソースを取得に行ってる事か。
Blosxomの頃は別フレーバだったので、影響は最小限だったが。
2009/10/05
何か知らんが投稿編集画面にSIMILE Timeline関連のパラメータ設定(Event Start Date, Event End Date)が入力できる様になってるし…
現状ではどの投稿にどうやって使い込んで行くか、皆目見当が付かんけど便利そうな予感。
2009/10/06
現状では使っていない。
もし使うとするならば、wp_enqueue_script のススメ : dogmap.jpあたりを参考にするか、SIMILE Timelineのページの時のみにJavaScriptを読み込ませるとか、何等かの回避策が必要かと思われ。
2009/11/08
メンテ中
本番・開発の2系統立ち上げれば、使わなくとも良いのだろうけど。
Maintenance Mode Plugin ― Software Guideというのがあるので導入。
WordPress関連の書籍を読んでいて、ライブメンテナンスやっている最中に知り合いが辿って来て、「表示が妙だった」と後日クレームを入れられたとか…
これ、充分あり得る…
ところが使い方が分からなかった…正確には「メンテ中になってない」だったのだが、「ログアウトしないとメンテ中を確認できない」との事。
そりゃそうか。他者から見ればメンテ中でも、ログインしてるヒトまでメンテ中だったら困るわな。
以上笑い話。
2009/10/06
検索結果のハイライト
Blosxom時代、使っていた記憶があるのでWordPressの場合も当然あるだろうと調べてみたら、WordPress Plugins/JSeries ? Search Word Highlight for Multibyteというのがあった。
どうなんだろ。
サイト内検索で、テーマによっては、ハイライトしない場合もあった。*
Google経由に関しては、現在Googleに登録されているのは、Blosxomの頃の情報なので、http://morry.duelist.org/blosxom.cgi/HOGE.htm となっている影響からか、ハイライトされていない。
その辺はおいおい分かってくると思うが。
2009/10/13
どうやら見当違いで、WordPress 2.6 以降に対応した検索キーワードをハイライト表示してくれるプラグイン | Tips Communityにある、Search Unleashed – Advanced WordPress searches with highlighting, MySQL fulltext, and Lucene support | Urban Giraffeじゃないとダメみたい。
Googleのキャッシュ表示みたいに複数文字列の場合の色分けができたり、検索文字列をログ保存したりと、ナカナカ高機能なプラグインかと。
ただし、検索キーワードをハイライト表示するプラグイン Search Unleashed | WordPressで企業ウェブサイト作成・商用ホームページ制作 WordPress Go Goによると、「検索エンジンから入ってきた場合、全角スペースで区切られたキーワードが分割して認識されないということである（内部検索ではマルチバイト関連のプラグインによってきちんと分割される）。」とあるので、相変わらず日本語に関してまだ少し問題もあるみたいな。
とは言え、かなり利便性が高まったんじゃないかと。
2009/10/17
誰が見に来ているか?
さすがの仙道でもどうにもなっていない。個人的に。
現時点(2009/10)での、ハイカラで戦略的なメソッドは、Open Tech Press | Open Web Analytics：WordPress用のアクセス解析プラグイン辺りなのかも知れないが、上手くインストールできない。正確には、OWA単独ではインストールできても埋め込み方が悪かったのかトラフィックが捕捉できず、じゃぁプラグインとしてはどうか?と言うと、インストールができない状況。
そもそも自分はトラックをSEOして戦略的にどうのこうの、というのは全くのオーバースペックで、Webで祭られていないかを確認したいだけ*というレベルなので、簡単に設置できて、簡単に見れればそれでOKなのですがね。
ところが意外とトラフィック解析のアプリが少なかった、という印象、かつ、開発のピークが2007年までで終わってるのかもしかして? と感じた。
また、日本語の問題があるため、外国産のアプリにパッチ当てて…という面倒な方法を取らざるを得ないみたいな。
なので、本来なら全世界|全Webデファクトスタンダードを使いたいのだが、これに関しては、和モノの
XenoLoggerに落ち着いた。
ちょっと面倒なのは、各テーマにイチイチ解析タグを記述しなければならないコトか。…とは言うものの、基本的にはトラフィック補足は、この方法が一般的みたいなので仕方無いが。
および、携帯表示のテーマとは全く別管理なので、そちらにも対応させる必要がある。
ま、まだ慌てる様な時間じゃないので様子見。
2009/10/13
オープンソースカンファレンス2009 Tokyo/Fall*にて、WordBenchの中の人が来ていたので色々と質問してみた結果を。*
StatPressを紹介された。
実際にiPhoneで動いている画面まで見せて頂きまして、どなたか存じませんが有難うございました。
しかしまだ組み込んではいない状態で、いずれ組み込む予定。
というのも、現在XenoLoggerが、このサイト以外のアクセス解析も含めて稼動しているので、恐ろしく優先順位の高いトピックではない状態。
ただ、二重管理にはなるが、おそらくは導入する予定。
2009/10/31
あわせて読んでないけど
だいぶ前からあわせて読みたいは知っていたが、「イメージ表示でしょ…」なので避けていた。
しかしよくよく調べてみると、あわせて読みたい – 開発API (開発者向け)で、RSS|JSON配信している事を知ったので、何とかなりそうな予感がした。
当初、個人的なWordPressのウィジェット作成の習作として考えていたが、そこはそれWordPressなので既にあるんじゃないかと思ったので調べてみた結果、やはり存在した。
で、WordPress › フォーラム » あわせて読みたいプラグイン：WP-Awasete-Yomitaiを導入。
登録してから実際に配信されるまでほぼ、1日(以上?)かかった気がするけど、現在表示中。
尚、個人的には各サイトのfaviconは不要なので、JavaScriptで該当する行をコメントアウト。
ウィジェットの機能がシンプルで、かつ、管理者ページにオプションの設定項目があり、コード自体も少ないので、プラグインの雛形として使えそうな気がする。
2009/10/17
リビジョン・オートセーブ
WordPressを使い始めて未だに謎だと思ている機能に「リビジョン管理」がある。
いや良いんですよ、いざという時に効力を発揮するのは間違いないと思うし。
ただ、そういう異常事態に陥った時の有難さと、日々の運用での「ボッチ|ピンで使ってるのに何だかなぁ」を天秤にかけた結果、「要らない」という結論に達した。
および、オートセーブに関しては微妙で、あっても良いんじゃないかとは思うが、これにもIDを発行していると思うと、ちょっとグラつくものがある。
方法としては、リビジョン管理そのものを殺してしまう方法と、過去のリビジョンを削除するプラグインがある。
自分の場合、Delete Revisionでたまに過去のリビジョンを削除する、という所までは行なっていたが、「でもMySQLの削除フラグ立ててるだけでしょ」という引っかかりはあった。*
結論的には、phpMyAdminでの操作方を知ってしまえば何て事は無いのだが。
もっともコレ、InnoDBの場合、どうなるのか分からんけど。*
ところでパフォーマンス的には、無駄なデータがあっても無くとも、さほど影響を与えていないと思っている。
それよりも、Webサーバとしてのキャッシュが効いているか否か、つまり、初回のキャッシュの無い時のレスポンスと、2回目以降のアクセスのレスポンスの方が、レスポンスタイム*に差が出ている様に思えるが、体感として感じる程のものでも無いと思っている。
詳細な手順は下記参照。
- WordPress 投稿リビジョンを削除するプラグイン【Delete Revision】：トイレのうず／ぼやき
- WordPress 投稿リビジョン停止のプラグイン【Disable Revisions and Autosave plugins】と【Revision Control】：トイレのうず／ぼやき
- phpMyAdmin から MySQL の最適化 ～WordPressを快適に使うために～：トイレのうず／ぼやき
2009/10/17
導入プラグインの一覧
ありがちだが、多分誰もが通る道ではなかろうか。
とは言え、手書きで記述していくのも億劫なので、システム的に何とかならんものかと。*
pluginsUsedPlugin – AndrewSW Pages via WordPressで導入したプラグイン一覧 – HUBLOG
あたりを。
作例では、runPHP経由で通常の投稿|ページへの導入だったが、runPHPを導入する事にイマイチ抵抗があるので、テンプレを作成。
tag, etcに。
ただ…このままだとコメントを入れることができないが。および、不活性のプラグインはリストに表示されない。
2009/10/17
せお
このサイトは、マズローの言説に従えば、自分の欲求は非常に低レベルだと思う。
つまり、第1 or 第2段階で、あまり多くの人に見てもらいたい、という欲求…を仮に第4・第5とすると、全くそういう気が起こらない。
自身のサイトは有益な情報を発信しているか?、答え、ノー、みたいな。
勿論、有益な情報の発信やネット世界に何等かのコミットメントを与えている者だけの特権だとは思わないが。
All in One SEO Pack、Google (XML) Sitemaps Generatorあたりを試験的に導入。効果の程は不明。多くのWordPress関連サイトで「最初に入れておくべきプラグイン」みたいな扱いを受けて。
および、プラグイン一覧晒しているので、定番が入っていないのも気が引けるので。ちなみに、Akismetが入っていないのは、コメント受け付けていないので。
2009/10/18
Google (XML) Sitemaps なのだが、http://～/memo_wordpress.htm とマッピング?されている。
しかしながらこのページは、実際には(現状では)14ページに分割されている(ex. http://～/memo_wordpress.htm/14)ので、1ページ目以降がマッピングされているのか不明。
…普通、ブログは一つの投稿に一つの固定URLが割り当てられるからねぇ…本来ならば、今見ているページのURLは、http://～/memo_wordpress_014.htm みたいにするべきだと思うけど、記事数を増やしたくないので、こういう変則的なページ構成にしている自分が悪いのだけど。
もしくは、かつて同様に一つのページにずらっと記述する方法に戻す事もできるけど、だらだらとしてしまって、どうにも受け入れ難いモノがあって。
2009/10/19
Tag Cloud
単に表示の方法ではなく、そもそもどうやって作っているのか? のメモ。なのでオチ無し。
イメージ的には、タグ文言とそれに付随した件数をセットとした配列を何がしかの関数に与えると、タグ文言をキーにフォントサイズ等を返す、みたいなイメージがある。
例えば、Create tag cloud | roScriptsあたり。*
WordPressの場合だと、category-template.php の wp_generate_tag_cloud 関数がそれに該当するのかどうなのかは未調査。何となくそれっぽく見える。特にソースを転記しないが、最小件数を取得、各タグ件数との差を求めて何かやってるみたいに見える。
何が言いたいかと言うと、例えば、Tumblr*、delicious*、はてブ*のタグ文言と件数の取得まではこちらで行なうとして、これ以降、同一のフォーマット|ロジックでタグクラウドを生成して欲しいと言う思惑。
なので、WordPressのロジックが使えればそれはそれでありがたいが、無理っぽい場合、上記のロジックで何とかなりそうなカンジ。
2009/10/26
あまり意味の無い? Archive
…と書くとまるでこのプラグインの存在理由を問うているみたいだけど、決してそうじゃぁありません。自分は元々年月のアーカイブ表示の必然性を全く感じないヒトであるので。
Snazzy Archivesについて。
利用する気になったのは、何となくTumblrのArchiveに表示方が似てるので…
デフォルトのままで利用すると、縦軸に年、横軸に月で、スクロールが縦軸に無く、横軸方向にのみ、しかも一番下にスクロールバーがあるので、ちょっとインタフェース的に厳しい。
なので今の形に落ち着いたが、果たしてこれが便利なのかどうか…ちょっと疑問ありのまま、しなっと利用中。なので、しなっと外している可能性もあり。
2009/11/03
WordPressで過去記事一覧をつくる :宗子時空というページがあって、それなりに悩んでいる人も居るみたいな。
実際、アーカイブページに飛んでもらえば分かるが、意外と「遅い」。
アーキテクチャに依存する部分も多々あると思うが、記事数不明だが、たかだか4年分なのにこのレスポンスではちょっと厳しいかなーと思う。
うーん、本気で対応する場合、投稿時に別途用意したテーブル…年月をプライマリキー、件数フィールドを追加…に永続的に情報を保存するのが、王道かと思うが…更に上記ページの場合、年月毎に投稿タイトルを表示してるので、余計に処理を重くしてるけど…、これってMTの再構築に相当する概念だろうからちょっとねぇ…
2010/02/11
メモ：SimplePieで同時に複数のRSSを取得
Agregado: A Free WordPress Themeを解析…とまで行かなくとも、ソース(functions.php)を追っかけていたら分かるハナシ。
とあるディレクトリにsimplepie.incと、基本的には同じディレクトリに書込み可能なディレクトリを作成する*のが前提として、以下のコーディング例をgetRss.phpとして、それについてメモ。
以下はディレクトリ構成。
-+- hoge\
+- cache\
+- simplepie.inc
+- getRss.php
以下はコード(らしきもの)。
require_once("./simplepie.inc");
$simplepie_args = array(
…何がしかのRSSを複数記述(可能)…
);
$feeds = new SimplePie($simplepie_args, "./cache/", 1800);
foreach ($feeds->get_items(0, 0) as $item) {
$item_date = $item->get_date('Y/m/d');
$feed = $item->get_feed();
$address = $feed->subscribe_url();
$url = $item->get_permalink();
$title = $item->get_title();
$description = $item->get_description();
echo 上記変数を記述
}
上記の実行結果は、RSS取得元に関係無く、日付降順でRSSの情報が表示される。
ゴメンね、不親切っちゃぁ不親切だけど、ケースバイケースの面が多いので、echoで表示させて確認して下さい…
コンストラクタ(new SimplePie)にて1800とあるのは、キャッシュの間隔と言うのか、そんなカンジ。上記の例だと1800秒は間を空けてRSSのURLに最新情報を取得しに行くんだろうね*。
次のforeachのget_items()の第1引数は開始件数目、第2引数は終了件数目。なので、初回0件目～19件目、次に20件目～39件目、…みたいな使い方ができる。*
subscribe_url()は、$simplepie_argsに格納されているRSSのURL。何に使うかと言うと、
if strstr($address, ‘flickr’) {
…みたいに、各Webサービス毎に何がしかの処理を追加する。多分その時は、$description内の文字列を色々と操作する事になると思う。
さて自分の場合の使い方だが、今まで各Webサービスの最新の情報を取得、例えばTumblrの場合だと http://HOGE.tumblr.com/rss みたいな使い方しか思い浮かばなかったが、タグ単位で情報取得というのも意外と面白いんじゃないかと。*
Tumblrの場合だと http://HOGE.tumblr.com/tagged/foo/rss、はてブの場合だと http://b.hatena.ne.jp/HOGE/rss?tag=foo、Deliciousの場合だと http://feeds.delicious.com/v2/rss/HOGE/foo みたいなカンジで。
2009/11/08
WebサービスRSS取り込み
さてどうしたものか…
今まで通り投稿扱いにするか、ページにするか、単なるウィジェットにするか。もしもページにするならばWebサービス単位だとページが無駄に増えるのでブログ系とブクマ系でまとめるとか。更にまとめる場合だとアコーディオン程度は導入したいなぁと。
RSS取り込みまでは今まで通りで良いとして、MySQLへのアクセスの基本ロジックまでは分かったけど、どのテーブルのどの項目にInsert/Updateするかの解析が必要。
細かい話だが、旧Blosxomの場合だとサイドバーのWebサービスのアイコンは、更新日付順にソートされている。これを実装する場合、WordPressで言うブログロールの優先順位を変更する方法があり、My Link Orderプラグインを導入して挙動を調べてみた。
[wp_links]テーブルに元々あったのか不明だが、[link_order]という項目があり、それを書き換えてるんじゃないかと。(ソースまで追っかけていないのでデマ・ガセかも)
例えば、旧Blosxomサイトはこの仕掛けを残したままにしておくので、RSSを取得せず、Blosxomのログを読み込んでMySQLへの更新という方法をあり得る。この場合、結構実装が簡単になる気がするが、cronの実行タイミングを考慮しないと、あまりよろしくない結果になりそうな気がする。
もしくは逆にこちらでRSS取得、MySQL更新を最初に持ってきて、旧BlosxomにはMySQLからSelectして、という方法もあり得る。
いずれにせよ、新しい革袋には新しいワインが必要かと思うので、今までとは全く別の実装になるかもしれない。
2009/09/20
時代が進んでいるね…
lifestream for WordPressあたりを導入してみたのだが、多分、リアルタイムに更新されてない…と思う…
cron辺りの関係かもしれないしそうではないかも知れないし。
で。
Sweetcronというのもあるらしい。
こちらをメインにしてWordPressを各Webサービスと同等のone of themにする方法も考えられる。
後日試験導入予定。
2009/10/04
実際にSweetcronをインストールしてみた。
どうも公式や各人のサイトのインストール方法では分かり辛い箇所を適当にメモ。
.htaccessについて。
公式にもある通り、自分の場合、例えば、http://duelist.org/HOGE/ だったとすると…
RewriteBase /HOGE/
…としておかないと、インストール時のURLにも辿り着けないみたいだ。
次に、cron設定について。
[True Cron]とした場合、http://duelist.org/HOGE/foo/var/xxxxxxxx が発行される。
このURLをブラウザから実行させる事もできるが、下記のスクリプト書いてcronから起動される様にしておいた。
<?php
$fp = @fopen("http://duelist.org/HOGE/foo/var/xxxxxxxx", 'r');
?>
さて。
個人的には各Webサービス(各フィード)の最新の、例えば5件だけしか必要無いのだが、このSweetcronも他のライフストリーミングサービス同様、初回起動(or 初回アカウント設定)以降の情報がどんどん蓄積される仕組みになっている。
これはこれでアリだと思うが、個人的には最新の5件だけでなければ、各Webサービスの全フィードが欲しいトコロ。*
なのだが、全件取得は基本的にはどのWebサービスも全件取得ができないので、あまり意味が無いと言うか。(個人的には)
2009/10/10
凄いね、Cellar Heat — Free Sweetcron theme, DISQUS Comments setup tutorial included. | Inerd Husseinだそうだ。勿論早速インストール。
良く分からんのだが、FriendFeedでは、各Webサービス毎にRSSは取得できない…様に見えるが、Sweetcronではできそうなカンジ。
あとは、各取得Feed(= Webサービス)単位に、タグなりカテゴリなりが追加できれば、自分・オトモダチ、みたいな仕様ができるのだが。
それにしてもSweetcron…まだできたてほやほや…とまでは行かないけど、割と新しいWebアプリみたいで、このブログのモロモロが一段落したら、もう少し突っ込んでみようかと。
それと、今はWordPressのタスクページの一部であるが、後日、独立した投稿にするかも。
多分、このSweetcronで情報を集積して、そこ経由で3rd.なり2nd.に情報提供する可能性もあり得る。
2009/10/19
帯には長くて襷には短い状況。
2nd.の場合だと、simplexml_load_fileを使っているが、この関数、エラーハンドリング、特にリクエスト遅延時の挙動を実装しなければならないのでちょっと不便。対して、SimplePieだとキャッシュを使用してくれるので便利なのだが、如何せん、小回りが効かない。simplexml_load_fileで取得できる項目でもSimplePieでは利用できなかったり。
次に、SweetcronとFriendfeedについて。
Sweetcronのフィードはリンク元が取得できないが、Friendfeedはできそう。但し、Sweetcronはタグ単位のRSS取得(i.e. http://duelist.org/sweetcron/feed/tag/deviantart)ができるが、Friendfeedはできないんじゃないか?
うーん…SweetcronのDBを直接見れば良いんじゃないかと思ってきた…
2009/11/03
テーマ：Cellar Heat
トップページの最上段に最新の投稿を表示させているためなのか良く分からんが、[prev][next]が無い。
実際、http://hoge.com/?paged=Xとしてみても反応無し。但し、カテゴリー・タグの一覧では[prev][next]があり、動いているが、この時は最新の投稿は無い。
例えば5 Yearsも似た様なデザインなのでインストールしてみたが、2ページ目に移ったら2ページ目の最初の投稿が先頭に出ている。
…これで何となく分かった気がする。
例えば、1ページあたり5件を出力するとして、1ページ目は最新投稿プラス5件、2ページ目以降は通常だったら6件目のところを7件目からの5件で最新投稿はそのまま表示…………いや理屈ではできるよ理屈では、と考えが至って何故実装していないのか納得した。
逆に言うと5 Yearsみたいなパターンでも良いんじゃないかと思ったりもするが、結構な外科手術なので対応未定。
そういう大袈裟なのはともかく、ウィジェット(WordPressの場合は、サイドバー等のアイテム)のCSSがちょっと何とも言えない状況なので後日対応予定。
トップに表示される右のRSSボタンの部分だが、デザインにも手を付けて、デフォルトで吐き出せる限りのXMLを吐き出してやろうじゃぁないかと。何せ今まではやりたくてもできなかった|やりづらかったので。
但し、今まで通りこのサイトは「大本営発表」なので、コメント系は受け付けていないので、吐き出す必然性も無いけど。
他に対応は未定だが、テンプレートの記述がダブっている箇所が多いので、その部分だけで共通化させるかもしれないししないかもしれないし…という変更もあり得る。
2009/09/20
気に入ったテーマをインストールして思ったコトを少し。
トップページだが、いわゆる「ブログ」という形式を取るならば、一覧が表示され、[次ページ]みたいな、古い記事、もしくは[前ページ]と順次アンカーリンクが表示される。
…というのが、「固定概念」としてあった。
しかし、そもそも自分が他人のブログをどう読んでいるかを鑑みるに、こういう固定概念を一旦置いておくという方法もあり得るんじゃないかと。
例えば、Googleで何等かの検索を行なった結果、とあるブログのとある記事に飛ぶ。
そこで必要な情報を仕入れて、ソーシャルブックマークにする確立が数パーセント。
そのページにある「関連する記事」にまで飛ぶ可能性が数十パーセント。
…で通常は終わる。
例えばその記事に関連するタグ・カテゴリーまで見る可能性は数パーセントで、トップに飛ぶ可能性は殆ど無い。
…と考えると、例えば、HemingwayExみたいに、トップページを「入り口」と考えない方法というのもアリじゃないかと思えてきた。*
しかしながら、リア友がこのサイトを見ていると仮定して、彼等彼女等がRSSリーダでピンポイントの記事を見に来ている可能性は非常に少なく、そういうヒト達にとってユーザフレンドリーかどうかと言われると、確かに不親切ではある。
とは言うものの、多分、前述したHemingwayExあたりをベースにカスタマイズしていくんじゃないかと思うが。
2009/10/13
テーマ：Agregado
ある程度、前述の「Celler Heart」の改修が完了した。
で、続いてのエモノがこれ。
ブログとフィードの融合具合が何ともイイカンジのデザインなので、これをベースに色々とやってみようかと。
実は、開発系には既にインストールしてあり、挙動を確認している最中。
右半分を占めるフィードの表示だが、WordPress管理画面のテーマオプションで定型的なサイト(Twitter、Flickrなど)はユーザIDのみ、そうで無いサイトも一応は登録できるが、肝心のTumblrが取り込みはできるがイメージが表示されないので、こりゃ独自実装かなぁと。
理屈では「できる」のだが、さてどうなるものかと。
尚、フィード取り込みには、SimplePieとやらを使っているそうだ。
なので、前述した「WebサービスRSS取り込み」タスクに関しては、これを使える様にする事が当面の解決策なのかもしれないなと。
ちなみに、Sweetcronも結構イイカンジで動いているので、そちら経由、という手段も考えられないも無い。もしくは、Frendfeedという方法もあり得る。
それにしてもこのテーマ、何処でも良く採り上げられている割には、実際に使っているヒトが居るのかどうか良く分からん。
もっとも、使う場合は跡形も無く原型を留めないで使うのが筋かもしれないけど、PSDも公開されているので、全然違う色合いに変更ぐらいは自分でもできるんじゃないかと思う。
2009/10/22
修正中。
このテーマに限らず、英語圏のテーマは、文字が小さいので読みにくい。
この辺の対応のためにと色々と修正していたのだが、CSSが継承されているため、結局全てのフォント関連の属性を削除したり、index.phpで一番最初に表示されている抜粋(excerpt)がとても短い場合、イメージとレイアウトがずれてしまうため、悩んだ末、全てのイメージを削除して、ほとんどテンプレート状態で利用中。
および、自分が使っているWebサービスの取り込みのスクリプトを書いたり…の途中。*
お陰様で、テーマのオプションの記述や挙動が見えた。
フィードの取り込みにSimplePieを使っているが、このテーマにおいて、デフォルトでイメージが表示されるのはFlickrしか無いので、他のサービスに対応させるため、色々と試行錯誤中。
イチイチWordPressで確認するのも面倒なので、一からコーディングを。
但し、バージョンの違いからか、例えば、RSSやAtomフィードをパースするクラスライブラリ:SimplePie:phpspot開発日誌は $feed->cache_location とあるが自分の場合、SimplePie – PukiWikiにある $feed->set_cache_location にしないといけなかった。*
感触としては、SimplePieを使わない方が、きめ細かなフィードの属性値?を取得できるんじゃないかと。
例えばTumblrのイメージを取得する場合、simplexml_load_fileだったら漏れなく全てのフィードが取得できるが、SimplePieの場合、イメージの格納先URLが1種類(サイズが違う)しか取得できない。
但し、自動でキャッシュを作成するのでその辺のコントロール、一般的なURL・時間等の取得が汎用化されているので楽と言えば楽。
で、最終的な形としては、Agregadoの挙動にCeller Heartの皮を被せられると個人的には嬉しいがさてどうなるか。
2009/10/25
中規模改造、2009年11月末実施
右側に各Webサービスからのフィードを表示してみた。
但し、トップページのみで他のページには表示させていない。
見ての通り、Cellar Heatをベースに、Agregadoっぽくはしているが、直接コードを使ってはいない。大いに参考にしたが。
例えば、Agregadoの場合のスクロールは、ボタン押下による何かだが(未調査)、自分の場合は、jScrollPaneとやらを組み込んでいる…のだが、未だにこちらで良いのか、それとも、ボタン押下の方が良いのか悩んでいる。*
フィード取得に関しては、別途準備したフィード取得のスクリプトをテンプレート内から読み込んで表示している。対してAgregadoの場合は、テーマのオプション画面を設置し、そこでフィードの設定・取得を行なう様にfunctions.php内に記述している。なので、Wordpressとは独立したプログラムとして存在している。
この取得に利用したライブラリはSimplePieで、それなりに便利かなぁと言うのが結論*。フィードもタグ単位で取得しているため*、気が向いたら追加・削除が楽にできるようにしておいた。
CSSやテンプレそのものには大幅な修正は行なっていない。思うのだが、こういうボックス型のレイアウトだからできる技で、いわゆる普通のブログ形式だと、ちょっとデザイン的に難しいモノがあると思う。
2009/11/29
Tumblrのカスタム変数に{TimeAgo}というのがあり、前々から気になっていたので実装してみた。
これが結構面倒だった。
というのは、ファジーな要素がある事で、「今日」「昨日(1日前)」…「4日前」「今週」となっていると思うが、「今週」と表示させるのは、月曜日から? 木曜程度から? で、その日を閾値としてそれ以前は○日前? とか、水曜日の4日前は「先週」なのか「4日前」なのか*、万事がそういうカンジで、こういうのは、個人の感覚に左右される要素が多いと思うのでその辺と、単純にコーディングの問題。結構面倒だった。
それとは別に…
…改めて考えてみりゃ、何の断りも無く、いきなりR指定な画像が出てくるのって、よろしくないよなぁ…
これは、Tumblrでここに表示可能なタグを追加して対応か。
とは言え、あまりトップページへのリクエストも無いのも事実。
2010/01/10
中規模改造、2009年11月末実施の残タスク
まずはCSSの大掃除が必要かと。本文とフィード表示エリアの間隔は個人的に許容できないレベル。
他に、投稿記事のボックスみたいに下部をフェードアウトさせたり、何よりもCSSの大掃除は必要。
色々と事前勉強が必要なのだが、Ajaxを用いた部分的な更新と言うのか、そういうモノの実装。
フィード取り込みのプログラム自体には引数指定でNext/prevな動作が可能だが、Wordpress側での実装ができていない状態。
それと…考え方にもよるが、ブログ本体はほとんど更新が無く、フィード取り込みの方はどんどん最新に更新されると思うが、この場合、このサイトのRSSはどうしたら良いのかと、はたと気付いた。
なので、もしかしたら最新更新日付分のみ、ブログ側に投稿として転載するスクリプトを書くかもしれないけど今のところ未定。
他に色々あった気がするけど、大まかにはこんなカンジ。
2009/11/29
ドロップダウンメニュー回り
良く分からない。方法は千差万別あるみたいだが。
例えば、Indo Cellar Heart Darkでは実装できているので、それを参考にする予定。
いや別にドロップダウンメニューが持ちたいのでは無く、ドロップダウンメニューを持つ事で、コンテンツの充実が図れるので…
ところで、Wordpressのメニューの項目にはページしか持てないのだろうかと、ずっと前から調べている。つまり、通常の投稿をメニュー項目に加えたいのだが、どうにも方法が分からない。
例えば、Post Inserterを使う方法も考えられるし、カテゴリに属する投稿を展開するプラグインもあるみたいだが。
ところで割とこの案件に対して及び腰なのは、結構大規模な改修…と言っても実装レベルの問題では無く…とは言え、JavaScriptが絡んで来るので結構及び腰だが…、記事の見直し等いつもと使うアタマが違う対応が必要なので。なのだが、これをクリアする事で、例えばグロッサリー(用語辞典)を展開し易くなったりするが。
2009/11/29
本家プラグインリストにも、結構存在するみたいなのだが、いずれ対応予定。
2010/02/11
WordPress派生
現時点(2009年冬)の自分の「ネットのある生活」。
S12HT on Google reader (mobile)で各サイトのフィードを読む。IT系だけではないけど多分200件/日程度。
「むむっ」と思った記事はスターにしておき、自宅に帰って仕訳作業。
もしも常時外接可能で、業務中もそういうコトをしてもはばかられない環境だったら、Google readerで要約だけでなく、実際の記事に飛んでそのままブックマークするが(自宅とか)、残念ながら今はそういう環境では無いので。
思うのだが、何故ヒトはブクマするんだろうかと。
自分は、言ってしまえば「マーカーを引く感覚」程度で、後で見直す事はほとんど無い。なのに毎日毎日良くもまぁと思う。
何処かで書いた気がするけど、これらはフローの情報なので、何処かでストックの情報に価値変換したい、という誘惑に捕らわれる事があるが、如何せん、時間を作れないので日々惰性でブクマしてる気がする。言い方を変えれば、ｵｻｰﾝが毎朝日経を読むのとさほど変わらない気がする。
現在自分の場合だと、IT系のマジメな話題はdeliciousで、オタク系の話題ははてブと使い分けしている。
この入力をサポートする形で、FirefoxのShareaholicでTumblrとdelicious、はてな謹製プラグインを利用している。
ここに来て、前述した情報の価値変換とともに、はてブ・deliciousに投稿し辛い話題が多々出てきた。
大まかに言ってしまえば、IT業界|増田にゃんねるβみたいな話題で、何か申したい時はTumblrに投稿するし、そうでない時は…の扱いが、はてブなのかdeliciousなのかどっちなんだ…みたいなカンジで。
これを解決するために、まず考えたのが「新たなSBMを利用する」だった。*
例えば、ソーシャルブックマークサービス一覧 ２００８年２月３日現在 – 厳選、メタ検索・メタディレクトリ付属日記あたりのだが、何が良いんだろ、良く分からん…
と言うのも、以前に投稿したブクマをインポートする時、「オリジナルの投稿日時は保証されるか?」という、多分自分以外のヒトにとってはどうでも良い事にこだわっているので。もしもこの機能が実装されていない場合、自分があるSBMにサービスインした日にどばっと投稿があって、という状況に耐えられそうに無いので。つまり、ブックマーク先も大事だが「何時投稿したか?」も自分にとっては大切な情報の一部なので。*
次に考えたのが、「オープンソースのSBM導入」だった。
ところがこれが意外と少ない。
オープンソースのソーシャルブックマーク一覧 – 空繰再繰と、大半は2005年前後で開発が止まってたり…それでも選ぶとするならば、scuttleになると思うが。
なのでちょっとこのセンもpend。
で、この件を探している時見付けたのがpressmarkだった。
ついでに、QuickPostプラグインも。
ただ…前者はともかく後者を今の自分のWPに組み込むかと言われると否定的で、だったら別に立ち上げると思う。
多分自分が要求するのは、分かり易いテーブル設計とFirefoxでのサポートだろうかと。
「分かり易いテーブル設計」というのは、特に導入初期段階は直接RDBに対してSQLを発行する可能性があるので。また「Firefoxでのサポート」についてはこれが無いとイチイチ面倒なので。たかがリンク先を投稿するのにページを開いてURL入れて…なんて作業は耐えられない。
でもまぁここまでハナシを引っ張って何だが、今更ながらchyrpというのが改めて一つの選択肢になり得るなぁと。*
例えばSweetcronでも投稿はできるが、引用・リンク先投稿はできないので。勿論プラグインを作れば可能だろうけど、さすがにそこまでやろうとは思わない…
2009/12/21
現在Scuttle使用中。
2010/02/27
さすがにページ分割が過ぎてAdmin画面では編集しづらくなって来た…orz
以下、この記事を書いた時点では、WordPressで「気付いた事メモ」の投稿と、「残タスク」の二本立ての状態での投稿。
現在は、別途書いた「直接テーブル更新」にてWordPress関連の記事を統合化している。
また、夫々の投稿は、章毎にページ送りにしていたが、現在は1ページ内でのページ内リンクにしている。
「WordPressメモ」、現時点で18ページ。
元々ここまで増えるとは思いもよらなかった。
例えば追記だけ、つまり後ろにどんどんページが増えていくだけだったらまだしも、途中のページに追記したりするのが果てしなく面倒になってきた。
更に、この残タスクページと統合しようかと一時思っていたのだが、さすがにWebのフォームだけでの入力では辛いモノがある。
だからと言って、更新の度に全文をローカルPCのテキストエディタにコピーして、と言うのもスマートさに欠ける気がする。
一番安易でかつ、一番ブログらしい方法としては、投稿を分割するのがベストなんだろうけど、その方法を拒んでいる理由は単純で、しかしながら、他の人からすれば「何故に?」になるが、「投稿を増やしたくない」というのが心情にある。
何故増やしたくないかと言うと、WordPressを2009年の夏から使い始め、色々とメモしていくうちに「WordPressメモ」の投稿が溜まった。で、それを通常の投稿にすると一挙に18ページ(以上)増える。
ところがこのブログの全投稿数は60件程度。しかも2009年に投稿が集中し過ぎてバランスが悪いので。
実際には1998年からこういうコトをやっているのでそれなりに投稿はあるが、過去色々とブログツールを乗り換えて、過去の投稿をコンバージョンする段階で、気持ち80%の投稿はコンバージョンされなかった、という経緯がある。理由は単純な日記なのではっしょったり、気分的にコンバージョンしたくないとか、もしくはテーマ別にまとめてしまったとか。
更に更に、「WordPressメモ」の1ページ目、「コンテンツ一覧」*を入れてしまったので…そもそも自分が何処に何を投稿したのか覚えていないため…これを今後も手動でメンテするのは非常に面倒。
で、実際今後どうするかという件だが、かなり反則技を使う計画。
--+-- header.txt
+-- 01.txt
+-- 02.txt
:
仕様としては、まず、投稿は分割する。但し、ファイルとして。これをローカルに格納しておく。
で、必要に応じて追加(= ファイルの追加)なり追記(= ファイルの更新)を行ない、FTPする。
それをWeb上で、一覧を作成しつつテキストファイルを合体させ、WordPressのテーブルに直接updateする。
…どうなんだろ、上手く行くのか分からん。
と言うよりも、1回の投稿の更新において、WordPressのどのテーブルのどの項目に変更が加わっているか現状では見えてないし、もしかしたらWordPressをフレームワーク・関数の集まりと見立てて、WordPressの投稿更新時の関数を直接発行する…そう簡単に行くのか?、という手段もあり得るが…
なので、まずやらなければならない事は、「どのテーブルのどの項目に変更が加わっているか」を知る必要がある。
これにはいわゆるファイルダンプを投稿前・投稿後でdiffするツールを作成して挙動の確認を取ってからの判断になる。
とは言え、バージョンが変わったら挙動が変わるかもしれないので全く保証されない行為ではあるが。
今思ったけど、ローカルでもPHPが動いているので、もしかしたらイチイチサーバにFTPする必要は無いかもしれない。
ただ、ネット越しにデータベースに更新できるのかどうか、そこまでは調べていないが。
まぁ何にせよ、阿呆な事をやろうとしてるなぁという認識はありますよ。
2009/11/10
直接テーブル更新
これ、反則技だと思う。
なんだが、細切れの文章が増えたので、WordPressのAdmin画面のフォームでは入力できなくは無いとしても、面倒になってきた。
…と、何処かで書いた記憶がある。
当初案では、<!–page–>までを一つのファイルとして、スクリプトで投稿毎にまとめて情報を付加し(ページのトップにある一覧)、直接テーブルをupdateする。
…という目論見だったのだが、全ての投稿にページ送りがあるとは限らないため、コードが複雑になる。いわゆるキーブレイク処理なんだが、これが意外に面倒。
ならばと、一つの投稿を一つのファイルとして、前述した情報の付加をしてテーブルupdateを行なう、という方法に切り替えた。
考えてみればこの方法、以前使っていたBlosxomと同様の方法ではある。
当時、ローカルのテキストファイルで記事を書いてサーバにアップ、ファイルのが最新日付になってしまっているのを無理矢理、任意の日時に変更するスクリプトを使っていたので。
それでも無理矢理updateを発行する場合、下記に注意する必要があるのではないかと。
まず、前提としてどのテーブルかを確認する必要がある。
これに関しては、Wordpressの全テーブルを更新前と更新後での差分を確認した。具体的には、全テーブルに対して、select * from TABLE order by KEY; を実行してテキストファイルに出力するスクリプトを実行。
結果、wp_postsだけじゃねぇ?*という結論に達した。
次に最低限どのフィールドを更新すれば良いのかを確認した。
結果、
UPDATE
wp_posts
SET
post_content='本文～',
post_date='yyyy/mm/dd hh:nn:ss', // 更新日時
post_date_gmt='yyyy/mm/dd hh:nn:ss' // 更新日時(GMT)
WHERE
ID=xx;
…で何とかなるんじゃないかと。
例えば「あ、タイプミス見付けた」程度だったらpost_dateとpost_date_gmtまでは更新する必要は無いだろうし、今こうやって書いている様な場合だと必要かと思う。
また、IDに関しては、実際にテーブルを見て確認。この場合、WordPressのリビジョン管理のため、実際には使用されないレコードの場合もあり得るので、不要なレコードはDelete-Revision等で削除しておく必要がある。
次に、上記でのpost_dateを何処に持たせるか? だが、update文の元ネタになるテキストファイルに持たせている。
具体的には、この投稿の場合だと、
01: meta-title: WordPress メモ
02: meta-date: 2009/11/24 23:00:00
03: meta-wpid: 999
04:
05: <p>
06: 「それでも仙道なら… // 実際には<a href="…
07: </p>
08:
09: <!--more-->
10:
11: $$_LIST_$$
12:
13: <h4>Slug・Permanent link</h4>
:
みたいなカンジ。但し、meta-titleは実質不要。また、meta-**としているが特に規則は無い。別にこれが「HOGE-DATE:」であっても何の問題も無いし、増してや、Wordpressのメタ属性とは何の関連も無い。
尚、post_contentフィールドであるが、シングルクォートに関してはエスケープしないと…例えばシングルクォートを連続させる等…SQL文のエラーになる。安易ではあるが下記の様に。
$tmpstr = preg_replace('/\'/', '\'\'', $tmpstr);
「$$_LIST_$$」は、上記13行目にある様な<h4>タグから一覧のリストタグを作ってそれを表示させる置き換え文字列。
具体的なソース提示は今後。
…はしないです。さすがに。
2010/01/21
直接更新の弊害なのかもしれないけど、WordPressの管理画面から更新した場合と比較して、投稿ページの表示がワンテンポ遅れると言うか、モタ付いて表示されている…
気持ち悪いけど、打つ手立てが無いのでこのまま放置の方針。
いずれ「うわぁあ」と気付く時があるかもしれないけど。
2010/02/11
WordPress関連書籍
個人的にはこの2冊で充分かなぁという状態。
WordPressレッスンブック 2.8対応―ステップバイステップ形式でマスターできる
他の投稿でも書いているが、WordPress取っ掛かりの1冊。
前提条件として、「PHP・HTML・CSSの理解は必須、他のブログツールでのカスタマイズ経験はあった方が良い」になると思うが。
ゼロからテンプレートを構築するプロセスを手を動かしてコーディングして、動いている結果を見て納得する、というスタイル。
自分の場合、他の投稿で散々書いてる様にBlosxomでの経験はあったので、自分の中での「こうしたい」という想いやイメージはあっても、それを何処にどう実装すれば良いのか、WordPressを触り始めた頃には全く分からなかったので。
特にBlosxomは、フレーバー(他のブログツールだと「テンプレート」)には、Perlのコーディングができなかったので、尚更余計な葛藤があった。
勿論、オンライン上で良質なドキュメントはあるのだろうけど、そこまで探す気力が無かった。
嬉しい効果としては、他のツールのカスタマイズに出くわしても…勿論ドキュメントも改修事例も無い、それ程苦労する事無く、スムーズにテンプレートや本体ソースを修正する事ができる様になった事だろうか。
余談だが、今後自分が「コレだ、オレはコレと心中する」と思える(Web)ツールに出会ったら、このレッスンブックの作法・流儀に習って、ドキュメントを書いていけば、自分もアルファブロガーの端くれ程度にはなれるかもしれない…という野望はあるにはある。
PHPによるWordPressカスタマイズブック―2.8対応 テンプレートの改造からプラグインの作成まで
とりあえず一通り目を通しただけで、この本をリファレンスにして何かしたかと言うと、現状ではそれは無い。
自分はデザイン屋ではなく、IT土方の側なので、幸か不幸か、SQL・RDBのやらんとしてる事は分かるし、言語に関する経験もあり、これを購入した動機が「ウィジェット(= プラグイン?)の仕組みってどうなってるの、もしかしたら実装するかもしれないので」という明確な目的があった。
なので、そういうニーズに応える本だと思うので、前述したレッスンブックとはターゲットが明らかに違う。
実際にウィジェットを実装する場合、この本で流れを掴んで、分からない箇所はWordPress Codex (ja)、場合によっては、Codex本家で調べる、というスタイルになるんだろうなぁと思う。
余談だが(以下略。
ところでここに挙げた2冊、同じ出版社なんだなと。
ちらりと立ち読みしただけだけど、「XHTML&CSS超高速コーディング術」は、結構濃くて面白かった。
2010/02/11
色々なプラグインや参考になるサイト
via [WordPress]使用しているPluginの紹介 » tAkatronix’s GEEEK notes
-
SyntaxHighlighter Evolved
いずれ使うかも。
-
WP-Cumulus
日本語化が必要、見た目はイイカンジだけど、実用レベルではちょっと…
-
AddThis
自分に一番必要の無いプラグイン?
-
WP-TwitterBadge
ついっ太はともかく、改造して他のWebサービスへの導線にするには良さそうな。
例えば、404 shin1のつぶやき ないわー Not Foundあたり。
このままだとちょっと自分の芸風に合わない気がするが、後日ちょっと潜らせて貰います。*
-
Updated Today Banner
面白そうな…ただ…自分のサイトはほとんど更新しないし…「update this month」みたいに(w
-
WordPress.com Stats Helper
現在利用しているXenoLoggerのログ経由で、という野望があるにはあるが、大抵忘れているので放置
via love*moco
左にtweetboard。
うーん、このユーザインタフェース、自分のトップページに表示しているRSSフィードに応用できないかなぁと。
右側のバッジもなかなか面白そうなので、後日ちょっと潜らせて貰います。
2010/02/11
WordPressをフレームワークとして見立てて、非連動のバッチスクリプトを書く場合って?
別途記述した「直接テーブル更新」という、危険極まりない方法を採らず、WordPressの作法に則って処理する場合、要はWordPressのファンクションをコールすれば良いんじゃないの? とは思う。
具体的には、UPDATEを発行している関数を、WordPressの手順に則って事前処理して呼び出して事後の処理を行なう、みたいな。おそらくはこの方法を利用すれば、WordPressの内部構造の変更に対しても、恐ろしくは影響を受けないと思っている。
この場合、独自実装スクリプトの側で、あるWordPressの関数を呼び出しても、その関数内で使用している変数・定数・関数がincludeできていないとダメだろうけど調べるのも面倒だし、という理由から「直接テーブル更新」という方法を採っている。他に、どういう検索語で調べれば良いのか良く分からないというのもあるが。
例えば、別途、全く別の理由でScuttleに潜っていた時、気付いたのだが…
require_once('header.inc.php');
$userservice =& ServiceFactory::getServiceInstance('UserService');
$templateservice =& ServiceFactory::getServiceInstance('TemplateService');
$tplVars = array();
…みたいなカンジで、画面からリクエストされる単位でのスクリプト(index.php・about.php・…)によって微妙に違うが、何となく、こんなカンジなのかと思った。
WordPressの場合だと、サイト構築日記 » index.php 「フロントファイル」 /wordpress構造解析 wp_rootにある様に、これが自分の求めていた答えなのかどうかは分からないけど。
2010/02/11
OSC2010 Tokyo/Springにて質問。
index.php
+-- wp-blog-header.php
+-- wp-load.php
| +-- wp-config.php
| +-- wp-settings.php
+-- template-loader.php
…だそうだ。
このうち、template-loader.php は、表示を行なっているとの事。
これプラス、「更新時アクションを追っかける」という王道ではあるが、自分が面倒だからと避けていた回答を貰った。そうだよなぁ、普通そうするよなぁ…
別途作業が落ち着いたら対応。
…の予定。あくまでも予定。
2010/02/27
関数リファレンス/wp update post – WordPress Codex 日本語版
でFA?*
2011/02/11
WordBench
OSC2010 Tokyo/Springに行った。
以前のOSCでもですが、WordPressのブースで妙な質問をさせて貰っております。
なので、登録させて頂きました。
プロフィール登録にサイトURL登録があったのだが、結局掲載を辞めた。
自分を知ってるヒトにはこのサイトを教えたりもするけど、無関係者にリアルの自分とネットの活動をリンクさせる情報を無条件で提示するのはちょっと抵抗があるので。
とは言うものの、改めてこのサイトを見直した所、
「うわー分かりにくいなぁ…」
だった。
何だろ、何処かの時点で記事を整理して、古い記事を「捨てる」勇気と、現状を交通整理する必要があるよなぁと。
2010/02/27
タグの説明文をテンプレートに
[Admin画面]->[投稿のタグ]で「説明」というフィールドがある。
この説明はデフォルトではあまり重要な意味を持ちませんが、これを表示するテーマも中にはあります。
だそうで、となると、テーマを修正すればこの文言が表示されるのではないかと思い、調べてみた。
このタグ説明文を表示させるためのテンプレートタグは、tag_descriptionだそうだ。
これをタグ一覧により表示されるテンプレートに下記の様に記述。
<h3>tag <?php wp_title(); ?></h3>
<?php echo tag_description(); ?>
これが実際には下記の様に表示される。
<h3>tag » このサイトについて</h3>
<p>このサイトに関して</p>
2010/04/14
コンタクトシート
メールフォームと言うべきか。
くどいがこのサイトは「大本営発表」サイトなので、そもそもがこういう機能は必要無い。
ついでに言うと、デザインの手間も増えると言うのもあるし。
更に言うと、「トラックバック 0 コメント 0」がずーっと続くのも何かねぇ…
…と言う理由から双方向のコミュニケーションを避けていたのであるが今回、最低限のコミュニケーション手段として、メールによる問い合わせのシステムを追加した。
具体的にはContact Form 7を追加。
プラグインの導入と、コンタクトページの追加というオーソドックスな作り。
今後、スタイルシートの設定の必要あり。
2010/04/14
ソーシャルブックマークボタン
…まぁ…あまりリンクされる事を前提としていないサイトなので無くても良い、と言うより、無い方がデザイン的にも精神的にもすっきりするのだが。
方法は色々あるみたいで、個別のボタンを登録する方がデザインができて良いのだが、いかんせん、面倒臭い。
例えば、Twitter/facebookいいね/facebook Share/mixiチェック/mixiイイネ/GREEいいね/Evernote/はてブのボタンを超カンタンに作れる jQuery.socialbutton プラグインを作ったよ | アイトランス株式会社を使うのはナカナカ良い選択肢かなと思う。
今回は見送って、安易にもAddThisを。
問題、と言うより、引っかかる事があるとすれば、mixiチェックとイイネ！か。
前述したjquery_socialbutton_pluginにおいては設置できるが、AddThisでは未だ姿を現さず。*
Web業界は流れが速いので、今後どんなブクマが出てくるか分からないし、極力手間をかけたくないなぁと言うのが本音なので、AddThisにした。
例えば、jquery_socialbutton_pluginのmixiだけとAddThisの併用が自分には現状一番のベターなのだが、mixiの会員じゃないので or mixiチェックキーを発行してまで、というのが面倒なので今回見送り。
もう一つ問題があるとしたら、個別記事とは別にトップページへのAddThisの追加。
レイアウト的に何処に配置するべきか思案中。
2011/02/10
cellar-heat固有の問題で個別ページ右上、Previous Entry/Next Entryの文字数制限
ブラウザで見た目上は何も問題無い様に思えるが、HTMLコードを見ると投稿内容が全て取得されている。
ずっと前から放置状態だったのだが今回、応急処置を行なった。
functions.phpにtl_excerptという関数があり、そこがどうやら、というのは前々からうっすらとアタリは付けていたのだが…良く分からなかった…
今回、本腰を入れて調べてみたら、「$words = explode(‘ ‘, $text, $excerpt_length + 1);」と、文字数ではなくワード数を拾っている模様。
なので、日本語では上手くいかないのかなと思いつつ、関数自体を下記に書き換える。
function tl_excerpt($text, $excerpt_length = 55) {
/**
$text = str_replace(']]>', ']]>', $text);
$text = strip_tags($text);
$words = explode(' ', $text, $excerpt_length + 1);
if (count($words) > $excerpt_length) {
array_pop($words);
array_push($words, '[...]');
$text = implode(' ', $words);
}
return apply_filters('the_excerpt', $text);
**/
return apply_filters('the_excerpt', mb_substr(strip_tags($text), 0, 199, 'UTF-8') . '[...]');
}
…あまりにもどうよなコードだが…
2011/02/10
snazzy archivesも同様な実装を行なっているので、文字列が切れず、みっともなかったため、改修。
snazzy-archives.phpのfunction GetExcerpt($text, $length = 15)。
ただ…上記の場合にしてもそうだが、the_excerptじゃダメかどうかは今後試してみる。
にしても重いね、このプラグイン。全件舐めしてるから仕方無いのだが…
2011/02/15
メモ：カスタムフィールドに関して
現在何かアクションを起こしたわけではないが、WPをCMSとして企業様相手に何か行う場合に出てきそうな話題なので。
例えば、製品紹介で入力フォーマットが決まってる場合など。
きっかけは、CR（FUKUI CREATORS GUIDE）(via WordPress サイトコンテスト 2010)の各デザイナーの個別ページを見ていて、「これをどううやって…」と考えたのがきっかけ。
実際にはどうやって実装しているかは知らないが…
そう言えばWPにはカスタムフィールドがあったよなぁ…と思いながらネットで調べたので一筆啓上。
余談だけど、WordPressサイトコンテストの受賞作をもう少し詳しく見た方が良いよなぁと。
どうも自分、普通のデザインってできそうに無いので…
と言うのも、海外のポートフォリオサイト集とか、奇抜では無いにせよ、これは日本の企業風土には馴染まんだろうなぁ…というサイトばっかり見ているので。
その辺、専門家に任せる方法もあるけど、それはそれとして、という事で。
2011/02/12
WordPress脳 ── WPをブログでなくCMSとして使う場合に悩んだ事 ──
実際には一般公開されていないが、既存のサイトをWPにリプレースした場合の習作として昨年2010年秋に取り組んだ課題に関して。
勿論自分が「トロい」から、こんな阿呆なコトで詰まったのかもしれないが…
それまで自分はWPを「ブログツール」としてしか見ていなかった。
そのため「ページ」を使った事がほとんど無かった。
なので、そもそものページのアーキテクト…データ入力して、メニューでコントロールして、表示されて…が良く分かっていなかった。
「何か」ができるだろうとは思っていたが、ぼやっとしたイメージだけで…
この結果何が起こるかと言うと、既存のサイト構成の分析はできる…これはWPの能力とは別のベクトルなので…、で、次にWPに落とし込もうとした段階で、アタマが真っ白に…
結局自分でも何故その辺をクリアにできたのか良く分からないが、じっくりとリプレース後のイメージをシミュレートして実際にテンプレを作ったからかなぁ、としか。
イメージが煮詰まる原因としては、「これは実装無理でしょ」という箇所をどう対処するか、でWPの流儀に従うにしても、その流儀が見えていなかったので。
で、実装に関してはテンプレを全面的に採用する方法、テンプレを流用する方法、フルスクラッチなど色々と方法があると思うが、自分はテンプレ流用のフルスクラッチみたいな。
実装で一番面倒だったのは、メニュー周りだった。
多分これも実装する前段階でのアタマが真っ白になる要因の一つだった様に思う。
いやぁ、実際しんどかった(w
…という記憶しか…
HTML・CSS・PHP・MySQL、今回は既存のリプレースが前提だったのでJavaScriptは触らなかったが。
更に場合によっては、データ登録しながら、画像の編集も加わって来るのだからねぇ…
なのである意味、無償公開してるヒトは尊敬する。
一方で、カネ取ったからといっても非難はできないわ、自分。
それなり…じゃなくて、本気でやるとしたらかなり大変だと思う。
また、既存のサイトが動いている訳なのでインストールに関しても、および、切り替えのタイミングと方法に関してもタスクとして挙がる。
この辺は、WordPress を専用ディレクトリに配置する – WordPress Codex 日本語版を参考に、ローカルの環境で試行。
実際には別のプロジェクトで、Maintenance Mode Pluginでしのいだ事もあったが。
他のタスクとして、既存データの移行やユーザさんの教育、本体/プラグインのアップデート等が生じると思うが。
…結局の所、今何故平然と淡々としているかと言うと、「経験したから」としか言えないんだな。
2011/02/12
性分として。
あるテンプレートでの記述。
before
<ul id="nav">
<li class="<? echo (is_home())?'current_page_item':''; ?>"><a href="<?php echo get_option('home'); ?>/">Home</a></li>
<?php $pages = wp_list_pages('sort_column=menu_order&depth=1&title_li=&echo=0');
echo $pages; ?>
</ul>
after 1：上記テンプレート
<?php celler_navigation(); ?>
after 2：functions.php
function celler_navigation () {
echo '<ul id="nav">'."\\n";
echo '<li class="'.((is_home())?'current_page_item':'').'"><a href="'.get_option('home').'/">Home</a></li>'."\\n";
echo wp_list_pages('sort_column=menu_order&depth=1&title_li=&echo=0')."\\n";
echo '</ul>'."\\n";
}
性分として、同じ記述は極力一箇所にまとめたい、なので…*
ただこれ、後々追っかけにくくなる原因になりそうな…
なので、突き詰めてコーディングしたい反面、どうにもゴーストが囁くんだな…
2011/02/15
他人の構築したWPを覗き見る行為
クラックとかしたのではなく、業務の一環で。
「画像が見えないので調べて」と依頼があって、恐る恐るadminで入った。
「すげ、MUやん*」「うわー整然と作ってるなー」「なるほど、ブログじゃなくてCMSとして使う場合はこうやるのかー」
みたいなカンジで、なかなか勉強になる。
肝心の問題解決だが、詳しくは言えないが画像までのパスをWP側で意識する|しないに関わらず変えた、もしくは、物理パスを移動させていた。
なので、画像*までのパスを現状に合わせて設定しなおして解決。
当初はテンプレに修正が入っていたので、その関係で何かあったのかとアタリを付けたのだが、そうではなかった。
2011/02/17
Footnote Related posts:
- なにもかもがばらばらだ。誰もそれらをとりまとめようとしない。
|
