このサイトでの記事は、Wordpressのテキストモードで入力していて、テキストモードだと空行で段落の区切りを意味するようになっていたはずなのだが、５月後半にwordpress-4.9.6 へ更新してからか、この段落空行が無視されるようになったのか、記事が過去分も含め全て段落なしのベタうちで表示されるようになってしまった。
何か動作変更があったのか。
追記）
設定で変更した箇所がなかったか見直していたら、使っていたテーマのLibrioに自前で機能を追加しようかと子テーマを作成していたことが判明。子テーマの導入自体は何か解説サイトだかを見ながら確認もして行なっていたので、動作自体は問題なかったはず（段落が詰まってしまうのは見落としていたかも？）なのだが、とりあえず自前子テーマをやめて、元のテーマに戻してみた。
するときちんと動作するようになりましたわ…。子テーマで記述不足等があったのかも？
あまりのFirefox56の遅さに、観念してFirefox 60.0.2へ自動更新した…。
で、Greasemonkeyのユーザスクリプトを復活させようとしているがうまく行かない。
そのままだと、同じタブにインストール確認画面になるのだが、「インストール」ボタンを押しても、一瞬スクリプトのソースが表示されて、また確認画面に戻って来て先へ進めない。
Greasemonkey自体の問題かと確認してみると、入っていた4.1だか4.0よりも新しい、4.4があったので更新してみた。
確かに動作は変わって、確認画面がポップアップされるようになって、「インストール」ボタンで先へ進めるようにはなったのだが、「インストールに失敗しました。undefined」などと出てしまう。
なんじゃこれ。
アマゾンにアクセスして書誌情報を取得するスクリプトを書いていたら、Rubyの場合はけっこうサクサク動くのにPHPだと、１件の情報を取得するのにも１０数秒かかったりと動きがもっさりしていた。
それぞれ、使っているライブラリやらアマゾンで取得する情報の量の大小などであって動作に違いがあるのかと思っていたが、PHP側で情報取得に使っていた@simplexml_load_file()が内部的にfile_get_contents()を呼び出して？いて、それが激重だったらしい…。
該当部分をcURLでの取得処理に変えてみた。
処理時間を計測してみたのがこちら：
（1件の検索を４回）×２回繰り返した場合
| 方法 | 時間 | 総時間 | |
|---|---|---|---|
| 1. | cURL | 27秒+34秒 | 1分1秒 |
| 2. | simplexml_load_file | 2分3秒+1分33秒 | 3分36秒 |
| 3. | simplexml_load_string + file_get_contents | 2分13秒+1分39秒 | 3分52秒 |
前にcURLに切り替えた際にはせいぜい時間は2/3になるかならないか程度かなと思っていたが、今回測ってみるとなんと約1/4になっていた！
file_get_contents()遅過ぎ…。
リンク
使っているアドオンの関係で古いFirefox 56のまま使い続けているパソコンがあるのだが、それほどタブを開いていない場合（３０～４０個）でも反応がめちゃめちゃ鈍くなり、キー入力すら効かなくなる場合がある。
Firefoxの公式サイトの対応リスト↓に従って、設定フォルダ内の content-prefs.sqlite, places.sqlite, sessionstore.js を削除したりリネームしたりしてみた。とりあえず、少しは改善したかな？
早めに最新Firefoxに更新したいとこだけど、今までのアドオンの代替がないのがなー。
Firefoxで何度ファイルをダウンロードしようとしても反応せず、メモリ関連などでの動作異常なのかとFirefoxを再起動してもダメで別ファイルのダウンロードを試してもダメ。
どこか設定が壊れたのかと思っていたが、別作業があって電源オフにしていた別モニタを表示させたら、そちらの画面に保存確認のダイアログがいくつも出ていた…。
なぜ、別モニタ側に表示されたのか不明（標準動作なのかも？）だが、ダイアログは現在操作中のFirefoxが表示されている画面に出てもらったほうがいいかなぁ…。