Tumblrのsiteinfo編集について
これまでに関わった複数のURLが適用されるsiteinfoを表にしておきます。
| 番号 | 名称 | 呼称 | 種別 |
|---|---|---|---|
| 681 | Tumblr | メイン | 汎用 |
| 31114 | Tumblr - hAtom | hAtom | 汎用 |
| 31158 | Tumblr - AutoPagerizeFORMAT | APE、APF | 汎用 |
| 63728 | Tumblr - masonry | masonry | 汎用 |
| 85560 | Tumblr - post | post | 汎用 |
| 85573 | Tumblr - article | article | 汎用 |
| 85562 | Tumblr - newDay | newDay | 集積 |
| 85564 | Tumblr - content | content | 集積 |
| 85563 | Tumblr -Dummy for uAutopagerize | ダミー１ | 集積 |
| 85566 | Tumblr -Dummy for uAutopagerize2 | ダミー２、ダミーラスト | 集積 |
pageElement
Tumblr
(id("posts")[count(//*[@id="posts"])=1]|//*[@class="main" or @role="main"][not(self::main)][not(id("posts"))])[not(@style)][not(.//article[@style])][not(.//*[contains(@class,"masonry")])][not(id("sidebar-nav"))]Tumblr - hAtom
//*[contains(concat(' ', @class, ' '), ' hentry ')]Tumblr - AutoPagerizeFORMAT
//*[contains(concat(' ',@class,' '), ' autopagerize_page_element ')]Tumblr - masonry
id("blog wrap")[./*[starts-with(@id,"1")]]Tumblr - post
(//div[@class="post"]|//div[@class="post"]/following-sibling::div[@class="date" or @class="bottom"]|//div[@class="post"]/preceding-sibling::div[@class="date" or @class="bottom"])[count(//*[./div[@class="post"]])=1][count(//div[@class="post"])>2][//div[@class="post"]/following-sibling::*[1][@class="post" or @class="bottom"]]
Tumblr - article
//article[not(contains(@class,"loaded"))][count(//*[./article[./following-sibling::article]])=1]
Tumblr - newDay
descendant::div[@id="newDay"][1]|descendant::div[@id="newDay"][1]/following-sibling::div[@id="newDay"]
Tumblr - content
id("content")Tumblr -Dummy for uAutopagerize
descendant::*[@style="display: none;"][1]
Tumblr -Dummy for uAutopagerize2
descendant::*[@style="display: none;"][last()]
uAutoPagerize ver 0.1.7の仕様変更について その２
Grieverさんからのコメントにお答えします。
私の使いたい XPath と多野さん(?)が作り上げてきた XPath が大きく違い編集しづらいこと、pageElement の取得・継ぎ足し時に JavaScript でチェックと補正を掛けたいのが大きな理由です。
動作サイトについては死ぬほどテストしたので減ってはいないと思います。
uAutoPagerize ver 0.1.7の仕様変更について - 1300
コメントありがとうございます。もちろんGrieverさんが優秀な技術者なのは認めますが、JavaScript自体が使えるとしても誤動作に気を使いながら400や649を無効にしてこれまでと同様の動作サイト数を維持するのは難しいはずです。すごい気迫ですね。
これまでと何がどう違うのかを確認したいのですが、日頃の行いが悪いのか独自設定が機能しているサイトがほとんど確認できません。MY_SITEINFO無しで以下全てのサイトが機能していません。
| wedata | URL |
|---|---|
| 400_a | https://www.newyorker.com/magazine/food-and-drink |
| 400_b | https://gadget-shot.com/ |
| 400_c | https://www.jinnsblog.com/ |
| 400_d | http://bash.org.pl/latest/ |
| 400_e | http://octech.jp/modules/wordpress/ |
| 649 | https://blog.nicovideo.jp/3d/2014/06/pmx.html |
| 650 | http://majikichi.com/ |
| 85437 | https://oiio.jp/ |
Grieverさんのコメントを読む限り、これらのサイトを切り捨てているとは思えません。私が何かを見落としているはずです。
追記
先日アップした uAutoPagerize に組み込み設定が動かないバグがあったので修正版を審査に出しました。
— Griever (@Griever2) August 26, 2020
多分明日か明後日くらいには公開されるかと思います…
無事アップデートで上記サイトが機能しています。素早く対応していただき助かりました。
uAutoPagerize ver 0.1.7の仕様変更について
あ、SITEINFOを更新してください。
— Griever (@Griever2) August 25, 2020
デバッグモードがONになっているときは400などは打ち消し線が表示されて実行されないことがわかると思います。
今回のバージョンでは 400 や 649 は全く使いません。 pic.twitter.com/QiBq0n4FtE
Build-in SITEINFO
誤作動の多い items/400 と items/649 を無効化して独自の汎用サイト設定を組み込んだ。
正確には items/80660, items/430, items/401 以外の https://www.example.com/ にマッチする SITEINFO を無効にした
400や649といった汎用のsiteinfoは無効化され、独自の設定だけで動作するようです。
一時期AutoPagerizeとか入れていたけど、これはこれで意図しないタイミングで動作して困ることも多く結局止めてしまった
— ukikagi (@ukikagi) July 3, 2020
これまでより動作するサイトが限定されるのが不満な方はMY_SITEINFOに400や649からコピペして設定されるのをお勧めします。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata
アイテム: hAtom - データベース: AutoPagerize - wedata
参考までに私の設定を置いておきます。
http://plsk.net/uap_set_general
一つ心配していることがあります。Grieverさんがこの仕様変更に踏み切った理由は、wedataのsiteinfoに不満があるからと考えるのが自然です。おそらくその原因の一つは400への私の対応でしょう。
もしこれまでより独自設定で動作するサイトが減れば、uAutoPagerizeユーザーにとっては動作する範囲が狭くなって手間が増えたと責められるのではないでしょうか。我ながら小物の発想ですね。
幸いにして今のところそういった動きはありません。uAutoPagerizeユーザーはGrieverさんに似て理性的な方ばかりでよかったなと思います。
400や650が採用されないのは悲しいですが致し方ありません。コーダーは感情に流されてはなりません。その瞬間瞬間でベストを尽くすしかありません。
wedata:400でcount()を使用した意図 その５
このシリーズはひとまずこれで終わりにしたいと思っています。
codepen.io
昨日やり残していたEntry + subとEntry 非 article + subですが、対応が難しいです。メイン側とサイドバー側をXPathで汎用的に見きわめる方法がないからですね。
多野さんの意図を自分なりに書くという当初の目的は現状で十分に果たされていますので、今後の課題として残しておきます。
自分でコードを書くのにこだわらず、もっと早い段階で多野さんやGrieverさんのコードを受け入れていればそう苦労しなかったはずです。wedataコーダーの皆さんには、ご迷惑をおかけしました。私が狭量と言ってしまえばそれまでですが保守の手間を考えればそう悪くないのかなとも感じています。
最初にexampleUrlを整理していたのがまさかA or B - A and Bの発想で活かせるとは思っていませんでした。幸運に恵まれた結果です。
Grieverさんのおかげで、XPathと向かい合う時間を作れました。コードにどういう意図があるのかを明確に伝えるのが大事だとよくわかりました。厳しい目を持ってコーディングと向き合わねばならないと教えられた気がします。ありがとうございます。
最後にこれから挑戦される方のために、メイン（メインエントリ側）とサブ（サイドバー側）に適用される数でそれぞれ現状と理想の動作を表にしておきます。n>1です。
| メイン | サブ | 現状 | 理想 |
|---|---|---|---|
| 0 | 1 | 機能しない | 機能しない |
| 0 | n | サブ側で機能する | 機能しない |
| 1 | 0 | 機能しない | 機能しない |
| 1 | 1 | 機能しない | 機能しない |
| 1 | n | サブ側で機能する | 機能しない |
| n | 0 | メイン側で機能する | メイン側で機能する |
| n | 1 | メイン側で機能する | メイン側で機能する |
| n | n | 機能しない | メイン側で機能する |
wedata:400でcount()を使用した意図 その４
また更新しました。Grieverさんのコメントを私なりに生かそうとしています。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata
今日もGrieverさんからのコメントにお答えします。
関連記事を取得したくないのではなく、関連記事を取得しそうな場合は AutoPagerize を動作させないという意図ですよね？
wedata:400でcount()を使用した意図 その２ - 1300
そもそもsiteinfoの作成に関しては優先順位をつけています。通常通り機能できればベストですが、ワーストはsiteinfoの適用によりデザインが崩れる場合です。ダミーコードが必要になるような事態は極力避けたいですね。
tanyao.hatenadiary.jp
サイトデザインの崩壊が想定される場合は機能自体を避けるべきだと考えています。機能はしませんがその分悪影響もありません。ベターと言えるでしょう。表にしておきます。
| 機能 | 優先順位 |
|---|---|
| 通常どおり機能 | 1 |
| 機能しない | 2 |
| 誤ったsitienfoが機能（デザインの崩壊） | 3 |
count()を使用したのはワーストの3を回避しベターの2にするためです。ご指摘のcaseAに関しては.sub側（サイドバー）のノードが適用されるのを避けて、機能自体をしないようにしています。もしサイドバー側へ適用されれば、デザインが崩れダミーコードが必要になる可能性が高いからです。
codepen.io
当然ながら通常通り機能させたいのはやまやまですが、下手に弄ればどう転ぶものかと腰が引けています。まず最初にここから説明するべきだったのかもしれません。
追記
なんとかもっとわかりやすくできないかと弄っていたのですが、こういうケースで異常動作を防げない事に気が付きました。
codepen.io
count(//*[./article[starts-with(@id,"post-")]])=1で条件式のチェックを通ってしまいます。どうしたものでしょうか。
追記２
なんとか対応したつもりです。これだけ頭を使うのは久しぶりですね。
http://wedata.net/items/400?rev=154714
追記３
Grieverさんからこのエントリにコメントをいただきました。
数える対象を間違えている気がします。
取得するのは『article が複数ある場合』なので数えるべきは『article を複数もつ親』では無いでしょうか？テストケースと『article を複数もつ親』が複数ある場合は動作しない例を用意しました。
wedata:400でcount()を使用した意図 その４ - 1300
https://codepen.io/Griever2/pen/YzqGNNQ
ありがとうございます。これだけ多くのテストケースを書かれている労力を考えると私より大変な思いをされている気がします。お疲れさまです。
articleとidの関係が２倍で取得する場合の条件式をより厳しくしました。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata
article 4 id 2やarticle-id 4 article 2に関してはこれで対応できるはずです。問題はEntry + subとEntry 非 article + subですね。少しだけ覚悟を決める時間をください。
wedata:400でcount()を使用した意図 その３
よく考えてみると、現状の私案だとこういうケースに対応できない事実に気が付きました。Grieverさんはこれにも対応させたいのかもしれません。
codepen.io
多野さん案なら対応可能なはずです。
どうしたものでしょうか。アイデアをお持ちの方はぜひ教えて下さい。とりあえずいい考えが浮かぶまでは、誤って動作させるのが怖いので現状を維持しようと思います。
追記
更新しました。また長くなりましたがこれなら上記のケースもどうにかなりそうです
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata
wedata:400でcount()を使用した意図 その２
前回のエントリにGrieverさんからコメントを頂きました。
前回の記事も読ませていただいきましたが、私は items/400 は 2 パターンだと解釈しています。
(//article | //*[starts-with(@id, 'post-')]) と id('content')/div[contains(@class,'post')] ですね。
article も starts-with(@id, 'post-') も単体ではどこにマッチするかわかりませんが、兄弟が複数存在する場合に限定することで「記事一覧」にマッチするように仕組まれています。（ときどき個別記事の関連記事一覧を取得して誤爆していますが…）
実際に div[@id='post-1234'] や article[@id='post-1234'] のような使われ方のページが非常に多く、区別する必要がないと思っています。
id('content')/div[contains(@class,'post')] は別パターンですが一応 div を数えて複数存在する場合に動作させようという意図が見えます。
この「複数存在する場合」という条件が Generic Post"s" Rule の要だと思います。
また重複を気にされてますが、同じ要素を二重に取得するわけではないので重複しても問題ないですが…。
wedata:400でcount()を使用した意図 - 1300
さきほどupdateを行いました。しつこいようですがこれしかできません。
http://wedata.net/items/400?rev=154703
コメントありがとうございます。//articleと//*[starts-with(@id,"post-")]のいずれか、あるいはこの重複に適用されるかを明確にしなければどこに適用されるか怖いと思うのですが…単に私が小心者なだけでしょうか。
exampleUrlを５ケースに分離したのはそれなりに意義があると言わせてください。なぜ骨を折ったのかと悲しくなります。機能上は構わないのかもしれませんがexampleUrlを整理したのが無駄とは考えたくありません。
同一階層内に複数存在するかどうかの見落としに関しては、完全に私のミスです。親ノードから見てこんな条件式を付け加えました。
count(./article)>1 or count(./*[starts-with(@id,"post-")])>1
一応提示していただいたテストケースには対応しているようです。まだおかしな点があれば遠慮なくおっしゃってください。
追記
以下の条件式で適用を回避したいケースを簡単に書きました。意図が伝わるでしょうか。
count(//article)=count(//*[starts-with(@id,"post-")]) or count(//article)=count(//*[starts-with(@id,"post-")])*2 or count(//article)*2=count(//*[starts-with(@id,"post-")]) or count(//article)<2 or count(//*[starts-with(@id,"post-")])<2
