Я постарался располагать советы по степени важности, начиная с самого важного. 1. Задавайте ширину страниц в процентах, а не в пикселях. Горизонтальная прокрутка это единственный из самых существенных недостатков любого сайта. 2. Размещайте самую интересную для посетителей информацию в верхней части страницы, так, чтобы она была без прокрутки. Ваша первая проблема - заинтересовать пользователя, потом, вам придётся приложить усилия чтобы удержать его, но если посетители уходят тотчас, то держать будет легко некого.

3. Если на вашем сайте вместо текстовых ссылок кнопки, то во что бы то ни стало разместите альтернативный текстовый вариант навигации, по иному, пользователи с отключенной графикой не смогут перемещаться по вашему сайту. 4. Ссылки вечно должны быть подчёркнуты - это стандарт.

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

Используйте для выделения тучный шрифт, или курсив, прочий кегель и шрифт. 5. Выделяйте разным цветом пройденные и не пройденные ссылки. В особенности это правило актуально для страниц с содержанием для больших архивов. Никто не любит гулять по одной ссылке два раза. 7. Навигационные ссылки в виде картинок должны обладать комментарий с разъяснением, куда попадёт посетитель.

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

9. Логотип сайта постоянно должен быть ссылкой на главную страницу сайта. 10. Посетитель должен несложно и стремительно выискивать ссылку на архив информации на сайте. Может быть, он ищет какую то конкретную статью 11. Если вы предлагаете скачать какой-либо файл, то обязательно укажите его габарит, не заставляйтё посетителей лишаться личное момент. 12.

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

Если на сайте присутствует больше одного раздела желательно сотворить карту вашего ресурса. Если вы сделаете карту древовидной, то она будет больше наглядной. 15. Старайтесь не совершать на странице ссылок на эту же страницу, в результате удаться рядовой рефреш и посетитель только потеряет час. Согласитесь неприятная обстановка, когда вы собираетесь куда-то сходить, а в результате оказываетесь заново там же, откель только что собирались покинуть.

16. Если ваш сайт представляет собой информационный ресурс с большим количеством текстовой информации, то по возможности установите скрипт поиска по сайту.

Совершенно безусловно, что выполнение всех этих советов не гарантирует успеха на 100%, уж очень страсть сколько других критериев влияет на популярность ресурса, но в любом случае ваши посетители оценят ваш работа. Успехов вам в этом нелёгком деле!

По материалам http://wm-help.net/articles/print/28.06

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

Предлагаем следующий алгоритм действий: Каждый день в 5 утра, cron на сервере www запускает скрипт backup.pl, тот, что выполняет следующий строй действий: Создает дамп базы и архив каталога htdocs. Копирует дамп и архив на backup-сервер. Запускает на backup-сервере скрипт store backup.pl, который выполняет следующие дествия: Удаляет каталог htdocs и пересоздает пустую базу данных. Разархивирует архив файлов и восстанавливает базу данных из дампа. Добавляет информацию в. Делает иные действия, требуемые для работоспособности перенесенного сайта.

Создает каталог с именем, совпадающим с текущей датой и в него переносит новые backup-файлы. В результате живого бэкапа, на резервном сервере неизменно будет работоспособная версия сайта.

Заказчик сможет обследовать, что backup на самом деле существует и работает и это придаст ему хладнокровие и уверенность в качестве услуг. По датам сообщений на сайте будет видно, что резервная копия сделана в эти дни в 5 утра. Образец В качестве примера рассмотрим бэкап сайта webew.ru. На каждом сервере настроен apache, на первом на адрес webew.ru, на втором на адрес backup.webew.ru.

На каждом сервере есть пользователь webew, база данных webew, а корневой каталог сайта - каталог htdocs в домашнем каталоге пользователя webew. Помимо того, для удобства поместим имя и пароль для доступа к базе данных в файл. Start backup. 2... 2 webew backup. Скрипт store backup.pl на сервере backup: ! AuthType Basic AuthName webew AuthUserFile home webew. Файл. Если вы опасаетесь взлома основного сервера, то процедуру разрешено направить: скрипт.

В таком случае злоумышленник, получивший доступ к основному серверу не сможет принять ssh-доступ к резервному. Заключение Живой бэкап позволяет заказчику быть уверенным, что резервная копия в действительности есть. Кроме живого бэкапа, не забывайте беречь копии проектов на локальной машине и на сменных физических носителях. Все права на данную статью принадлежат порталу webew.ru.

Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в печатных изданиях допускается только с разрешения редакции. Резервный сервер находится в "теплом" состоянии. Т.е. MySQL и Apache не запущены. При необходимости запускаем Apache и MySQL и получаем рабочую копию сервера. Попутно решается задача, когда бекапить надобно кучу сайтов. Копирование файлов базы при том, что первостепенный сервер работает, с большущий вероятностью приведет к битым таблицам.

Оптимальный вариант: rsync + репликация базы данных, но в этом случае испытать работоспособность сайта-копии будет нельзя, так как это нарушит репликацию. Если бинарики таблиц напрямую копировать будут траблы. Ибо это только усложняет задачу, причем, не совершенно обоснованно. С дампом может быть ряд неприятностей.

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

Если загружается главная страничка сайта, то это крайне славный тест всех аспектов корректности дампа. Кроме того, по главной странице видно является ли дамп актуальным. Предложенный подход - это, по сути дела, автоматизация процесса тестирования восстанавливаемости бэкапа. Поясню свойский вопросительный мотив.

Предположим, на моем VDS у меня есть план projectname.ru и я решил произвести его резервную копию на backup.projectname.ru на том же VDS. Всё великолепно работает, но в единственный не хороший день на сервере сыпется хард и я теряю как основную версию сайта, так и бекап. Нет смысла живой backup действовать на том же сервере. В частности, рассмотренный в примере сайт webew переносится на backup.webew.ru, размещенный на отдельном георгафически удаленном VDS.

Как отметил paulus, лучше эти скритпы прямо строчить на bash.

По материалам http://webew.ru/articles/1462.webew