Firefox Beta34で確認した際にマウスイベント時のselectionの破損バグが無くなっていると判断していたので、
touchイベントとrange状態を判別した上でコンテキストメニューの表示と非表示を切り替えることで対応させようとしたのですが、
Firefox Beta35で試したところ、修正されていると思っていたselectionの破損バグが存在したようで、contextmenuイベント時にrangeの取得が出来なかったので諦めました・・・

以前からタッチパネル端末へのブログエディター対応が最大の課題だと考えていますが、相変わらず厳しいです。

ブログエディターでは、テキストの特定範囲を選択して選択範囲へ処理を行う機能が搭載されていますが、
PCではコマンドをマウス右クリックのコンテキストメニューから選択するようになっていますが、
タッチパネル用のブラウザでは、

• テキスト選択 → テキスト長押し
• コンテキストメニュー → テキスト長押し

と、コンテキストメニューとテキスト選択が同じ操作なのでブラウザがコンテキストメニュー機能に完全に対応出来ていません。

range状態を判別して、こちらでコンテキストメニューの有効・無効を切り替えれば実用的なレベルで対応できそうなのですが、

1. マウスイベント時にrangeを取得しようとするとエラーが発生する。
2. oncontextmenuイベント時にイベント伝達を停止するとコンテキストメニューが表示されない。

というバグを把握しています。
2に関してはセキュリティーを犠牲にすれば対応できるのですが、
1に関してタッチに対応させようとすると見た目の選択範囲と処理範囲に食い違いが生じてしまう可能性があるので避けたいです。

通常の方法ではマウスイベント時にrangeに対して処理が行えないので、エディター上部メニューからの処理も行えません。


Google Chromeの場合はバージョンによって挙動が変わる気もしますが、テキスト上で長押しすると選択が優先されてコンテキストメニュー（Firefox以外では擬似コンテキストメニュー）が表示されないようです。
こちらはコンテキストメニュー自体が非対応なので仕様に問題があるとは思いますが、
バグは無さそうなので、テキスト選択をした上でエディター上部メニューから処理を行うことは可能です。


現状ではタッチパネル端末でブログエディターを利用する場合は、Google Chromeの方をおすすめしますが、機能に制限がある状態です。
Firefox以外のブラウザはコアがBlink又はWebKitですので、Firefox以外のブラウザはほぼ全てChrome互換です。

放置アカウント対策で、200日以上ログインしていないアカウントのドメインを停止することを計画しています。

準備の方は完了しているので近日中に処理を行い、以後日毎に自動処理とします。

この処理で確認されるログイン日時はパスワードの入力をしないセッションログインでも更新されますので、
ログイン状態のまま200日以内に公式サイトに訪れている場合は停止の対象にはなりません。
（ただし、誤差が最長24時間生じますので、199日以上200日未満でも対象となる可能性があります。）

XML-RPCやメール投稿によりブログを更新している場合でも、
200日以上公式サイトへログインしていないアカウントのブログは配信停止となります。

停止処理に該当した場合ユーザーサイトの配信が停止しますが、アカウントは停止しません。
次回パスワードでアカウントにログインした際に即時停止解除となります。

うちのサービスでは現在のところ放置ブログ等への広告挿入は行っていないですが、
放置ブログに広告挿入を行っても効果は少ないと考えているのですが、
放置アカウントのサイトが増え続けるのは好ましくないので、
対策として放置アカウントに属するサイトの配信停止を行おうかと考えています。

同種サービスでは30日等の期間で未更新のブログへの広告挿入を行っているところが多いですが、
広告による収益効果よりも、放置アカウント対策として考えているので、
管理者にログインしてもらえれば放置サイトが存在してもいいと思うので、
サイトの更新ではなく、アカウントのログイン状況で処理を行う方向で考えています。

期間は、
広告挿入なら100日放置
配信停止なら200日放置
程度で考えてます。

対象となったアカウントも、再度ログインすれば即時解除する方向で。

ここのところサービスの修正等は全然行っていませんが、
サービスの機能自体には影響ないことですが、データはとってあるのでログイン履歴を表示できるようにしようかと思ってます。

履歴はパスワードを利用してログインした際に時刻とIPアドレスが記録されますので、それが表示可能です。
ログアウトしなければ基本的に次回はパスワードを使わずにセッション認証となりますが、パスワード認証分のみです。

現在は公式サイトへのログインとXML-RPCの履歴を区別できるようにしてありますが、
公式サイトへのログインをHTTPとHTTPSの2種類に分けようかなと考えていますが、
現時点までの分は区別していないので補正することはできません。

先ほど気づいたのですが、MicrosoftのInternet Explorer 11でUserAgentの表記が大きく変わっているようで、

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
↑10まではこんな感じだったのが、

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
↑11はこんな感じで、

MSIEを名乗らずにGeckoを名乗るように変わっており、現在アクセス解析でMSIEと認識できずGeckoに分類されています。

後ほど対応させようと思いますが、IE11の表記からIEのバージョンを抽出してしまうと互換ブラウザで問題が生じそうな気もするので、
IE11ではなくTrident7としてグループ化しようかと思います。
その場合IE8がTrident4となりますが、IE7以前はTridentではなくMSIEとして分類されるようになると思います。

メインサーバーの新調がまだなので、今月も機能変更等の修正は無しです。

今月も残り僅かですが、メインサーバーの新調は早ければ今月末、遅くとも来月中にはやります。

IPアドレスの変更を伴う作業になりますので、ダウンは数分で完了する見込みではありますが、お使いのDNSによっては長時間接続できなくなります。

独自ドメインを使用している方で、もしAレコードでドメインを向けている方がいましたら、IPアドレスが変わるので作業完了後にDNSの変更が必要になります。
独自ドメインはCNAMEレコードで設定するように指示していますので、通常はユーザー様が作業をする必要はありません。

先月はサービスの公開部分には何も変更を行いませんでしたが、
4月末か5月上旬にメインサーバーの新調を考えているんで、今月と来月も機能追加等は行わないと思います。

昨今データのバックアップ処理時のダウンタイムが分レベルでかかってしまっていますが、メインサーバーの新調後はダウンタイムは1秒程度になる見込みです。

既存機能に明らかな問題が判明しなければ当面は公開部分に修正は加えないと思いますが、
5月以降にはブログの検索時の処理を変えようか検討しています。

以前からセキュリティー面で、トップページのログインフォームをDOMアクセスできないようにしたいと考えており、
HTMLでDOMツリーからの隔離をするには<iframe>のsandbox以外に方法がありませんが、
<iframe>のsrcdocでフォームを作っても<iframe>のサイズが自動で最適化されないため諦めていましたが、
一旦普通にフォームを設置してサイズを取得し<iframe>のサイズを設定すれば解決しそうだったんで実験してみました。

で、予定通り<iframe>のサイズを最適化してsandboxすることができたのですが、

• <form>のonsubmit時のaction動的変更が何故かできなくなる。
• <iframe>化するとFirefoxのパスワードマネージャが機能しなくなる。

という問題が生じました。
actionの方は別の方法で解決出来ましたが、パスワードマネージャの方はどうにもならなそうなんで、この件は実装見送りにします。

Wikiの変更を予定していますが、追加で、
Wikiの登録ユーザーに管理者権限を与える機能をなくそうか検討しています。

現在は登録ユーザーに管理者権限を設定すれば、公開ページ側でログインして編集することで管理者権限となりますが、
管理者権限は管理ページでの編集のみにして、登録ユーザーは一般ユーザーのみにするということです。

それにより、公開ページの編集関連の機能をいくつか省けるのと、
編集に管理者権限の必要なページは公開ページから編集できないので、管理者権限が必要なページでは編集リンクを表示しないようにできると思います。


ユーザーサイトのドメインでHTTPのPOST通信が必要な箇所はWikiページの編集機能のみなので、
Wikiページの編集機能を別ドメイン化して、スパム対策でユーザーサイトのドメインでPOSTを全面禁止にすることを以前検討していましたが、
Wikiのページ編集関連を修正するなら、ついでにそれも行うかもしれません。

Wikiの仕様にいくつか修正したい箇所があるので近いうちに修正しようかと思います。

1. &から始まる特殊ページがFeedに含まれるが、含むべきではない。
2. ページ名の変更とページの削除機能が存在しない。

&から始まる特殊ページは、現在の仕様では通常のページ区別していませんが、フラグをつけて区別しようかと思います。
それに加え&は通常のページと同じで文字参照&amp;となりますが、特殊ページに限り文字参照化せずに、通常の方法で作成・編集ができないようにし、管理ページからの編集のみ可能にしようと思います。

ページの削除とページ名の変更は、サービス開始当初からつけようと思っていましたが、いまだについていません。
難しいことではないはずなので、近いうちに付けたいと思います。
ページの削除ができれば、ページ名の変更は要らないかも・・・