Данный обзор написан специально для SEO Digest — популярного онлайн-журнала среди вебмастеров и поисковых оптимизаторов. Публикуемые в нем материалы рассчитаны на широкую аудиторию пользователей: от профессионалов Рунета до любителей и начинающих. Журнал доступен в PDF и онлайн версии.

Wordpress является сейчас наиболее популярной платформой для одиночного хостинга блогов. Ряд хостинг-провайдеров уже даже предлагают площадки с предварительно установленным Wordpress, а в большом количества изданий рассуждают, как лучше заработать на новом блоге или правильно его использовать. Я собираюсь осветить один из основных вопросов, встающих перед администраторами блогов: как сделать так, чтобы сайт быстро работал. Нижеизложенный материал рассчитан на максимально широкую аудиторию пользователей.

Основные положения

Ускорение работы любой системы возможно в основном за счет кэширования некоторых (тут стоит подчеркнуть, что именно некоторых, а не всех подряд) часто используемых операций. Все кэширующие мероприятия, в том числе и для Wordpress, можно разбить на несколько основных частей:

• База данных
• Компиляция серверных скриптов (PHP)
• Статические страницы
• Клиентская составляющая

Что такое PHP Speedy? Это набор php-скриптов, которые позволяют объединять и сжимать CSS- и JS-файлы для веб-сайта, написанного на PHP. Изначально разрабатывался как приложение к Wordpress, но сейчас получил более широкое распространение.

PHP Speedy был выбран в качестве основы для начала разработки Web Optimizer — веб-приложения, автоматизирующего клиентскую оптимизацию. Предполагается, что такое приложение можно будет максимально быстро и максимально легко развернуть на любой платформе, а оно уже само позаботится о всех действиях, связанных со скоростью загрузки страницы.

Как показала практика, клиентская оптимизация интересует большой круг людей. Но очень многих останавливает то, что нужны специальные знания для освоения этой области. Web Optimizer создается как раз, чтобы убрать этот барьер (и как наш ответ Чемберлену www.getrpo.com :).

Начинаю вести серию статей Это статья про вёрстку html css js, начинаю с самого простого, потом планирую описать более сложные вещи и всякие тонкости и этим видимо так и закончил

Эта статья предназначена для дизайнеров, верстальщиков, разработчиков и всех остальных людей, бьющихся с тестированием сайтов в нескольких браузерах.

Всего лишь год назад, хороших средств для тестирования кроссбраузерной совместимости сайтов практически не было. Инструменты, как правило, обладали серьезными недостатками – высокой ценой, скромными возможностями или затрачиваемым временем. Однако, в последнее время, в мире тестирования браузеров появилось много новичков, и некоторые из них являются прекрасными сервисами.

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

JS Charts является бесплатным JavaScript-генератором графиков и схем, который требует минимум знаний программирования. С JS Charts рисование диаграмм становится простой и легкой задачей. Он не требует никаких дополнительных плагинов и серверных модулей. Просто подключите скрипты, подготовьте данные для схемы в XML или массиве JavaScript и ваша таблица готова.

Перевод статьи Oliver Reichenstein «The 100% Easy-2-Read Standard».

Большинство сайтов доверху наполнены мелким текстом, который больно читать. Но зачем? Нет причины вжимать так много информации в экран. Это глупая коллективная ошибка, которая относится к временам когда экраны были действительно маленькими. Так что…

Экран и журнал: 100%-размер шрифта — это не много. Фотограф: Wilson Miner.

Не заставляйте нас изменять размер шрифта

Мы не хотим изменять настройки браузера каждый раз когда посещаем новый сайт!

5й выпуск медленно, но двигающегося вперед видеопроекта Computer Science Student. На этот раз — небольшая «лекция» о такой структуре данных, как деревья.
Видео доступно в HD-качестве, но, как всегда, придется идти на vimeo.com.

Прежде чем приступать вообще к использованию веток, и даже если вы и не думаете их использовать, необходимо прочесть Этот Священный Талмуд.

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

Или об особенностях управления отдаваемым контентом в PHP.

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

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

Сегодня решил сделать то, что собирался уже давно — поставить таки кеширование скриптов у себя на сайте. Все скрипты перед отдачей пользователю собираются в один файл и сжимаются GZIP'ом — все вроде по-уму, но есть проблемка… Браузер отчаянно не хотел кешировать этот выходной скрипт.

Опытным путем было установлено, что PHP устанавливает хидеры запрета кеширования при использовании функции session_start();

Рано или поздно многие крупные проекты сталкиваются с проблемами производительности при постраничной навигации по записям. Некоторые из них решают эту проблему ограничением количества доступных для просмотра записей (скажем, не больше 1000). Вполне приемлемое решение. Но в этом случаем могут возникнуть проблемы с индексированием сайта сторонними поисковиками, которые и представляют наибольшую угрозу. В этой статье я хотел бы отказаться от привычной для всех панели навигации вида «1..2..3..4..» в пользу простой «вперед… назад» (будет проще объяснить), но это не проблема реализовать подобное и с первым вариантом.
Более точно определить тему, назвав, какое количество записей считать достаточно большим для появления тормозов, не получится, так как эта цифра для всех разная и сильно зависит от того, насколько быстрые у Вас жесткие диски, сколько памяти, и какая часть Ваших данных уже закеширована в ней и тд. Но если Вы и Ваши сервера ощущают, что n-ная страница при выводе даётся тяжелее первой, и при этом не знаете, что с этим делать – статья для Вас. Но для начала, я хотел бы на пальцах объяснить, почему ОНО работает медленно.

Кстати, тест происходит на виртуальной машинке, работаю я с СУБД под рутом, версия MySQL – 5.0.32.

В данной статье демонстрируются основные уязвимости веб-приложений по загрузке файлов на сервер и способы их избежать. В статье приведены самые азы, в врят-ли она будет интересна профессионалам. Но тем неменее — это должен знать каждый PHP-разработчик.

Различные веб-приложения позволяют пользователям загружать файлы. Форумы позволяют пользователям загружать «аватары». Фотогалереи позволяют загружать фотографии. Социальные сети предоставляют возможности по загрузке изображений, видео, и т.д. Блоги позволяют загружать опять же аватарки и/или изображения.

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

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

Это вторая часть перевода. Начинать прочтение лучше с первой.

Итак, после применения описанных в первой части методов, мы можем прекратить волноваться? К сожалению, нет. То, какие расширения файла будут переданы транслятору PHP, будет зависеть от конфигурации сервера. Разработчик часто не знает и не контролирует конфигурацию веб-сервера. Мы видели веб-серверы, с такой конфигурацией, что файлы .html и .js выполнялись как php. Некоторые веб-приложения могут потребовать, чтобы файлы .gif или .jpeg интерпретировались PHP (это часто случается, когда изображения, например графы и диаграммы, динамически строятся на сервере самим PHP).

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

Сегодня хочу рассказать Вам о своем недавно состоявшемся первом знакомстве с фреймворком symfony.

Так как до этого я в течение длительного срока (около полутора лет) разрабатывал свои приложения на Zend Framework'е — мне есть с чем сравнивать.

длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный-длинный код в тэге <pre> заползает на правую колонку

Чинится очень просто:

pre {
    white-space: pre-wrap; /* Последние Opera, Firefox, Safari, Chrome*/
    white-space: -o-pre-wrap; /* Старая Opera (8?) */
    word-wrap: break-word; /* IE 5.5+ */
}

А тем временем, баг с широкими картинками был исправлен в CSS самого Хабра. Теперь нет нужды в UserCSS.

Обновлено: Баг исправлен. Рад видеть, что мои замечания не пропадают даром.

Наткнулся на кучу интересных статей на webo.in и зачитался. Решил применить описанное там на реальном проекте. Вот что получилось. Проектик маленький — сайт моих друзей Bookcare. Они делают обложки для книг, а их сайт — мой «проект выходного дня».

Привет.
Думаю, среди читателей хабра найдется немало тех, кто имеет stand-alone blog на движке wordpress.

Так вот, для вас, дорогие мои, у меня есть две новости, как водится, плохая и хорошая.
Плохая состоит в том, что wordpress — довольно-таки тормознутая штука.
Виноваты в этом в основном криворукие производители тем и, особенно, криворукие производители плагинов. Особенно кривой плагин, на мой вкус, wp-ajax-edit-comments, который является образцом быдлокодинга.

Хорошая — в том, что это можно поправить.

Приведу пример класса, который можно использовать в качестве поисковика на вашем сайте.
Для работы класс использует сервис Яндекс.XML. В свободном режиме они разрешают использовать до 1000 запросов в день. Условия использования сервиса на xml.yandex.ru

Яндекс.XML — это сервис, позволяющий делать автоматические поисковые запросы к Яндексу и публиковать его ответы у себя на сайте в собственном дизайне. Поиск от Яндекса — это быстрый доступ к сотням миллионов документов и изображений.

С помощью Яндекс.XML вы можете предлагать своим пользователям:

• поиск по вашему сайту (в той мере, в какой этот сайт проиндексирован Яндексом);
• поиск по сети или ее части (регион, отрасль), результаты которого могут показываться на вашем сайте и в вашем дизайне, и сервисы на его основе — Яндекс.XML открывает большие возможности для исследователей поисковых систем и преподавателей;
• поиск изображений, опубликованных в сети.

Что и как и как много хранит MySQL?

Данный материал создан специально для программистов, которые быстро смогут определиться какой тип данных лучше выбрать для хранения значений в БД MySQL.

Для затравки, интересная цитата из мануала по MySQL:
«Максимальный размер записи в MyISAM составляет 65534 байтов. Каждый BLOB или TEXT-столбец засчитывается здесь как 5-9 байтов.» — как это трактовать однозначно не понятно. НО ясно что много-примного столбцов в таблицу на засунешь. «Извращенистые программисты» — будьте аккуратны (66000 столбцов вы точно создать не сможете).

UPD: Если найдете ошибку, или я что-то где-то утаил — отпишитесь в комментах, с удовольствием добавлю.

UPD1 В первую очередь (и самый лучший вариант для новичков) прочитать ОФИЦИАЛЬНЫЙ МАНУАЛ dev.mysql.com/doc/refman/5.0/en/data-types.html (спасибо Psyh за прямую ссылку), а здесь вырезка для META обработчиков данных (как в лице программистов так и в лице машинной обработки).

UPD2 В принципе, все что написано ниже, можно прочитать по адресу www.mysql.ru/docs/man/Column_types.html (за ссылку «русского перевода», спасибо artuska).

UPD3 Еще одну неплохую ссылку предоставил 4all: newcontinent.ru/h/mysqlc (материал на русском)

UPD4 Цитата из комментов от egorF:
# 14«Как главный редактор русскоязычного перевода доки на MySQL, я рекомендую в него не заглядывать — он уже сказочно морально устарел.»

При подгонке сайтов до единого вида во всех браузерах, верстальщик использует не один css хак.
Но зачем обычному пользователю с IE получать избыток кода для других браузеров firefox, opera, safari?!
Это проблема легко решается с помощью динамического css.