Как заставить работать устаревший плагин с новым FireFox

Хотелось бы поделиться с вами небольшим хинтом.
Я думаю, что у заядлых пользователей FireFox (я его использую с версии 1.0) есть стандартный набор плагинов, который кочует с ними из версии в версию и безоговорочно устанавливается на "чистую" лису. Своим списком я поделюсь чуть позже, а пока хотел бы затронуть такой неприятный момент, как обновление Огнелиса и его плагинов.

Не всегда выходу новой версии браузера сопутствует обновление всех "избранных" плагинов. Хорошо, когда авторы плагина, зная, что особо изменений в нём не предвидится и работать он будет стабильно с любой версией, проставляют поддержку в виде 3.х.х.х, т.е. с любой версией, начинающейся на 3, но так бывает не всегда.

Взять, к примеру, недавнее обновление браузера до 3.0.1 — пара плагинов до сих пор не обновились на сайте и висели бы в отключенном состоянии, если бы не…

Перейдём к конкретике. Одним из моих фейворит плагинов является FasterFox. Он производит внутреннюю настройку FireFox для загрузки страниц в несколько потоков + содержит несколько функций, которыми я не пользуюсь. Если зайти на страницу плагина, то видно, что его поддержка остановилась на версии 2.0. В действительности же, так как все действия плагина сводятся к модификации about:config под оптимальные настройки производительности, он без проблем может работать и с новой версией.

Как же показать Огнелису, что плагин МОЖЕТ работать в новой версии?
fasterfox_error_message

Для дальнейшей работы нам потребуются две программы — архиватор (я предпочитаю WinRAR) и текстовый редактор (сойдёт и блокнот).

Первым делом скачиваем себе xpi-файл плагина.
Теперь открою небольшую тайну — этот самый xpi-файл представляет собой ничто иное, как обычный zip-архив, поэтому просто-напросто открываем его архиватором.

xpi-winrar

Из всего, что мы тут видим, нам необходим лишь файл install.rdf, содержащий информацию о названии плагина, его версии и совместимости. Извлекаем файл в какую-нибудь папку и открываем своим любимым текстовым редактором.

Перед нами самый обычный xml-документ, поэтому не пугаемся и ищем следующую строчку:
<em:maxVersion>2.0.0.*</em:maxVersion>

и меняем её, например, на такую, позволяющую плагину работать со всеми подверсиями 3-ей лисы:
<em:maxVersion>3.*.*.*</em:maxVersion>

Теперь запаковываем файл обратно в xpi-архив (в WinRAR достаточно просто перетащить его в окно с открытым архивом, а потом кликнуть ок).

Пробуем закинуть модифицированный файл в FireFox и вуаля —

fasterfox-installed

Что ещё хочется добавить? Пытливый читатель, открывший install.rdf, мог заметить строку, содержащую <em>em:version</em>, которая, как не трудно догадаться, указывает на версию самого плагина. Если вдруг решите её менять, то делайте это осторожно. Иначе вполне возможно, что при выходе действительно обновленного плагина, FireFox решит, что ваша версия новей и не сообщит вам об апдейте.

Вообще этот метод "обмана" браузера полезен как раз в переходный период, пока авторы плагинов не обновили свои детища, поэтому, как вариант, можно просто повременить с обновлением самого FireFox, но мы ведь не ищем лёгких путей 😀

Update спасибо тов. EvilFaeton за ссылку на такой полезный плагин, как Nightly Tester Tools, который позволяет активировать даже «не совместимые плагины», так же есть целый список дополнительных возможностей, но думаю они больше потребуются действительно тестировщикам. Если плагинов много, то лучше поставить Nightly Tester Tools, если же 1-2, то подойдёт и описанный вариант, дабы не плодить лишних аддонов.

13 вопросов, которые следует задать себе перед публикацией в блог

Мой перевод прикольного списка от Даррена Роуза под названием «13 Questions to Ask Before Publishing a Post On Your Blog» или как я перевел это «13 вопросов, которые следует задать себе перед публикацией в блог».


  1. Какая основная цель поста? Достаточно чётко удалось её выразить?
  2. Что я хочу, чтобы читатель сделал по прочтении поста? Удалось ли мне побудить его к этому?
  3. Написал ли я нечто полезное?
  4. Написал ли я нечто уникальное?
  5. Написанное приблизило или отдалило меня от целей блога?
  6. Использовал ли я привлекающий внимание людей заголовок?
  7. Нет ли грамматических и орфографических ошибок в тексте?
  8. Мог бы я написать тоже самое более лаконично?
  9. Указал ли я источники цитат и вдохновения?
  10. Были ли у меня посты на похожую тему, на которые я мог бы поставить ссылку? Может кто-то другой писал об этом?
  11. Оставил ли я читателям возможность что-то добавить по теме поста? Предложил ли я им сделать это?
  12. По какому словосочетанию должны попадать люди на этот пост из поисковых систем? Оптимизировал ли я текст под это слово/словосочетание?
  13. Как я могу развить тему поста в своих дальнейших публикациях?

А какие вопросы помимо этих вы задаёте себе?

“Не-не” отрицательный php-хинт

Сейчас занят запуском одного блога на игровую тематику, а так же пошли уже первые клиенты с курса Сергея Жуковского, что радует. Практикуюсь в быстрой и качественной настройке WordPress.
Чтобы вы не скучали напишу небольшой php-хинт, который, мне кажется, понравится изучающим этот язык. Во всяком случае мне он показался забавным и не лишённым изысканности)


Кто из вас не встречал подобный php-код?

Всё очень просто — требуется вернуть булевое значение (true/false), только проблема в том, что сама переменная $foo не обязательно булевого типа, поэтому нельзя вернуть её напрямую.

Вариант 1, приводим его к булевому значению

Вариант 2, приводим его к булевому значению (укороченный вариант)

Вариант 3, двойное-отрицание!!!

Первое отрицание (оператор не — !) приводит $foo к отрицательному булевому значению, т.е. false, а следующее «не» переворачивает уже к изначальному значению, но в булевом виде).

И напоследок — не сложно догадаться, что если вам нужно вернуть true, когда передаваемая переменная false, то убираем одно «не»:

Вот и всё, надеюсь вам понравилось;-)