Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. В этой статье я продолжу тему оптимизации WordPress с целью снижения его нагрузки на сервер хостинга. Этот вопрос будет становиться для вас тем актуальнее, чем больше посетителей будет приходить на ваш блог.
В предыдущей статье были описаны некоторые способы снижения нагрузки Вордпресс на хостинг за счет уменьшения количества запросов к базе данных WP. Но это, конечно же, только полумеры, которые нужно выполнять обязательно в комплексе с другими способами.
Способов оптимизации очень много и обо всех я подробно буду рассказывать в этой серии статей. Сегодня мы рассмотрим один из самых действенных из них, а именно кэширование. Сначала нужно определиться с тем, что же это такое и зачем его нужно использовать. Для начала рассмотрим работу блога на WordPress без кэша.
Кэширование в WordPress и как при этом работает блог
Все дело в том, что браузеры работают только с вебстраницами в формате HTML и напрочь не понимают язык PHP, на котором, собственно, и написан данный движок. Поэтому Вордпресс, после того как пользователь обратится к той или иной страничке блога, должен успеть сформировать эту страницу опираясь на алгоритм, прописанный в ее коде на языке PHP.
В классическом статичном сайте (сейчас таких осталось очень мало) все вебстраницы реально существуют и находятся на сервере вашего хостинга. К ним всегда можно обратиться, введя соответствующий адрес в браузере, или даже физически, через FTP скачать какую-нибудь страничку с сервера себе на компьютер и открыть двойным щелчком по ней. Как говорится, ее можно пощупать.
В случае же CMS , базирующейся на PHP и MySql, странички в формате HTML генерятся непосредственно на сервере хостинга, в момент обращения к ним. Каким образом они генерятся?
Ну, в соответствии с содержанием запрашиваемой вебстраницы загружается определенный набор шаблонов (файлов) из используемой вами в текущий момент темы Вордпресс.
На основе этих шаблонов создается графическое оформление запрашиваемой вебстраницы, а затем в область контента загружается из базы данных MySql, например, текст статьи. В область сайдбара так же могут загружаться данные из базы данных MySQL, если вы используете вывод в нем какой-либо информации штатными средствами WordPress или с помощью плагинов.
Как вы уже, наверное, заметили, такой способ формирования вебстраниц для браузера скрывает в себе некоторую проблему, которая особенно остро может встать при большом количестве посетителей на блоге. Код файлов, написанных на PHP, интерпретируется в HTML-страничку на лету.
Если запросов к базе данных на создание страничек будет очень много (при высокой посещаемости блога), то это может существенно нагрузить хостинг. Даже если предположить, что все посетители, находящиеся в данный момент на вашем сайте, запросили одну и ту же страничку, она все равно будет создаваться в вордпресс заново столько раз, сколько посетителей нажали по соответствующей ей ссылке.
Выход из этой ситуации состоит в использовании кэша. Как работает кэширование в WordPress? Довольно просто. Каждый раз, когда по требованию посетителя на сервере генерится страничка в формате HTML, то она не только передается браузеру пользователя нажавшего по ссылке, но и сохраняется в соответствующей папке вашего сайта.
И уже при следующем обращении к этой страничке, она не будет заново генерится, отнимая ресурс сервера (создавая дополнительную нагрузку на его процессор и оперативную память), а будет передана браузеру пользователя, запросившему эту страничку, из той самой папки на вашем сайте, где хранятся кэшированные вебстраницы.
Такой способ, когда кэшируется вся вебстраница, является самым эффективным, но не единственно возможным. Кроме того, некоторые динамичные элементы вашего блога могут при этом не работать.
Некоторые плагины для Вордпресса кэшируют только запросы к базе данных и, следовательно, позволяют работать динамическим элементам. Но все же кэширование вебстраниц целиком является, на мой взгляд, наиболее эффективным способом.
Герой сегодняшней публикации (плагин Hyper Cache) кэширует странички целиком и хранит их HTML версии в своей папке с кэшем. Что примечательно, кэширование работает только для незарегистрированных посетителей вашего блога. Т.к. у большинства блогеров регистрация не используется, то единственным зарегистрированным пользователем в этом случае будет лишь администратор, т.е. вы.
Для вас кэширование работать не будет и это очень удобно. Например, при внесении изменений в дизайн вам не надо будет каждый раз сбрасывать кэш, чтобы посмотреть результаты произведенных изменений. Хочу привести пример эффективности использования этого расширения в WordPress.
Вот такой вот замечательный плагин для кэширования в Вордпрессе. Ну, думаю, что уже достаточно теории и пришла пора рассмотреть непосредственно его установку и настройку.
Установка плагина Hyper Cache на Вордпресс
Скачать Hyper Cache вы можете с официальной страницы. Далее осуществляем стандартные действия по установке. Распакуйте архив hyper-cache.zip, используя ftp-менеджер подключитесь к вашему сайту и загрузите папку hyper-cache в папку с плагинами wp-content/plugins/ на удаленном хосте.
Дальше нужно будет включить кэширование в самом движке WordPress. Для этого нам потребуется открыть на редактирование файл конфигурации wp-config.php, который вы сможете найти в корневой папке на сервере вашего сайта. Вам нужно будет добавить в него всего одну строчку кода:
|
|
Вставить ее можно в любое место до строки:
|
|
Я, например, вставил в область, где идет задание параметров для базы данных:
|
|
Войдите в админку Вордпресса, выберете вкладку «Плагины»- «Inactive», найдите строку с этим плагином и активируйте его. Далее выберете из левого меню Параметры -> Hyper Cache. Если в окне с настройками никаких предупреждающих сообщений не появилось, то все готово к работе.
Если предупреждения появились, то скорее всего поможет выставление прав доступа 777 на папку (читайте об этом в статье про Файлзилу по приведенной чуть выше ссылке) wp-content или папку wp-content/plugins/hyper-cache.
Это нужно для того, чтобы данный плагин мог создать в WordPress папку для хранения кэшированных вебстраниц под названием cache. После того, как он ее создаст, вы можете вернуть права доступа на папку wp-content и папку wp-content/plugins/hyper-cache обратно на 755, а уже папке cache, которая у меня находится в wp-content/plugins/hyper-cache/cache, назначить права 777, чтобы Hyper Cache имел возможность записывать в нее и стирать HTML-файлы с кэшем.
Настройки Hyper Cache для снижения нагрузки на сервер
В первом поле настроек (в левом меню выбрать Параметры — Хипер Кеш) под названием «Файлы в кэше» вы можете видеть, сколько вебстраниц вашего блога в данный момент сохранено в кэше.
В этом же поле имеется очень важная кнопка «Clear cache», которая позволяет сбросить кэш, т.е. удалить из отведенной для этой цели папки все имеющиеся там файлы. Эта кнопка вам может понадобиться в том случае, если вы, например, внесли изменения в дизайн и хотите, чтобы их увидели ваши посетители как можно быстрее. Потому как в противном случае, им будет по-прежнему доступна только кэшированные версии вебстраниц.
В области «Конфигурация» сосредоточены основные настройки.
В поле «Таймаут кэшированных страниц» вы можете выставить время жизни кэша в WordPress. В течении этого времени в папке cache будут храниться HTML копии вебстраниц вашего блога и все пользователи, запрашивающие их, будут получать именно эти копии.
Но как только заданное в этом поле время для какой-то вебстраницы истечет, при очередном обращении к ней посетителя, она будет открыта уже не из кэша, а стандартным образом. При этом она будет заново закэширована плагином и помещена в папку cache. Если время жизни поставить слишком маленьким, то Hyper Cache вместо разгрузки сервера будет давать на него повышенную нагрузку, связанную с постоянным записыванием кешированных вебстраниц.
В поле «Режим аннулирования кэша» задается способ очистки кэша при добавлении новых материалов на ваш блог или обновлении уже существующих статей (в том числе и при добавлении комментариев). Если из выпадающего списка выбрать «Все кешированные страницы», то при добавлении новой записи или обновлении существующей будет обновлен (очищен) весь кэш в WordPress. При выборе «Ничего» кеш останется без изменений.
При выборе «Только измененные записи» будут обновляться (удалены из кэша) только файлы кэша тех вебстраниц, которые были изменены. Галочка в поле «При аннулировании записи также аннулировать домашнюю страницу, страницы архивов и категорий» добавит вам удобства при работе с блогом.
В поле «Отключить кэш для комментаторов» можно поставить галочку. В этом случае пользователи смогут видеть добавленные ими комментарии не дожидаясь истечения времени жизни кэша для данной вебстраницы. Это делает кеширование в Вордпрессе менее эффективным, но сам блог более удобным. Галочка в поле «Кэширование RSS» позволит кэшировать RSS ленту.
В области «Сжатие», поставив галочку в приведенных полях, вы можете активировать gzip сжатие страниц находящихся в кеше. Это позволит немного ускорить загрузку страниц вашего блога.
В области «Экспертные настройки» желательно будет поставить галочку в поле «URL с параметрами». В моем случае, после ее установки нагрузка блога на хостинг уменьшилась вдвое.
Не знаю всей подноготной, но несмотря на запрет индексации в robotx.txt урлов со всякими там знаками вопросами и прочей ерундой что умеет генерировать Вордпресс, к таким страницам кто-то обращается (боты или еще кто) и их тоже следует кешировать.
В поле «Кэширование Домашней» вы можете поставить галочку для отключения кеширования главной страницы. Это может понадобиться, если она интенсивно обновляется и включение ее кэширования может вызывать дополнительную нагрузку за счет постоянной перезаписи файла.
Не забудьте сохранить произведенные изменения в окне настроек плагина Hyper Cache, нажав на кнопу «Обновление». Для того, чтобы проверить работает ли кэширование, вам надо будет зайти на свой блог не под зарегистрированным пользователем, а как обычный посетитель. Для этого его можно просто открыть в браузере, отличном от того, в котором вы работаете как администратор.
Если вы увидите в самом низу окна с исходным кодом что-то вроде
|
|
то это будет означать, что Hyper Cache работает и при следующем запросе эта страница будет открываться им из кэша.
Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ruОригинал: ktonanovenkogo.ru/wordpress/plagini_wordpress/plagin-hyper-cache-optimizaciya-bloga-na-wordpress-2.html
З плагина для создания раскрывающихся рубрик. Плагин WP-dTree
Плагин WP-dTree – достаточно широко распространен в Рунете, он используется для создания динамически раскрывающихся рубрик на сайте, что облегчает пользователям поиск нужной и/или дополнительной информации. Мы попробуем установить и претестировать плагин версии 4.3.1 (самой последней из находящихся в депозитарии WordPress) на WordPress 3.3.1. Ниже Вы поймете, почему я об этом так подробно говорю.
Структура статьи:
- Скачивание и установка плагина WP-dTree
- Настройки плагина WP-dTree
- Настройки виджетов плагина
- Настройки виджетов WP-dTree Archives и WP-dTree Categories:
- Настройка внешнего вида виджета
- Настройка порядка сортировки и показа рубрик, подрубрик и статей
1. Скачивание и установка плагина WP-dTree
Если Вы будете скачивать плагин с сайта wordpress.org, то, несомненно, обратите внимание на то, что автор предлагает его с надеждой, что он будет полезен, но без всякой гарантии и даже без подразумеваемой гарантии, — все это несколько настораживает.
Чтобы Вам было легче искать плагин, я закачал его на свой сервер, поэтому скачать его, естественно, бесплатно можно ЗДЕСЬ. [Плагин скачан уже 175 раз(а)] .
Плагин WP-dTree находится в формате ZIP , поэтому устанавливать его на сайт можно прямо из консоли управления: «Плагины» — «Добавить новый». Установка его самая обычная, активация тоже, но после активации Вас ждет неожиданность:
Рис.1
Честно сказать, после такого предупреждения пропадает желание продолжать с ним работать, но мы продолжим: для того и создан учебный сайт.
2. Настройки плагина WP-dTree
Настройки плагина находятся в админке – «Настройки» — «WP-dTree» (да, в настройках появилась новая строчка). Кликаем по ней, открывается страница настроек:
Рис.2
Сразу хочу предупредить: к этим настройкам лучше всего обратить чуть позже, после установки виджетов в сайдбар, чтобы можно было на сайте посмотреть что к чему. Поэтому прямо сейчас перейдите на страницу «Виджеты» и перетащите их в сайдбар. Отличить от других их легко: их 5 штук и начинаются их названия с фразы WP-dTree. Потом возвращайтесь в настройкам.
В желтом квадрате – кто автор и его просьба помочь материально с помощью сервиса микроплатежей Flattr. Или купить ему книгу в магазине Amazon.com, стоимость — от 15 до 70 долларов. Еще там есть ссылка на форум поддержки, расположенный на wordpress.org (англоязычный).
Теперь перейдем собственно к настройкам. И сразу обратим внимание, что для настройки виджетов нас отправляют на страницу виджетов.
Строка «Animate» подключает анимацию, т.е. рубрики могут сворачиваться/разворачиваться в течении какого-то промежутка времени. По умолчанию – не подключено. Чтобы включить эту функцию, надо поставить галочку в чекбокс и указать в окне количество миллисекунд. Потом попробуйте поставить 1000 (т.е. 1 сек) и посмотрите как это работает.
Строка «Disable WP-dTree’s…» позволяет сменить стили CSS: если Вам не нравится стили, которые есть в плагине по умолчанию, то Вы можете их изменить. Для новичков это изменение будет несколько затруднительным, поэтому рекомендую оставить по умолчанию.
Строка «Include noscript fallbacks» подключает интересную функцию: если у Вашего посетителя отключен показ Java- скриптов, а такие есть (а меня у 32% посетителей Java отключена), то ему будет показываться другой вариант рубрик, но для этого создается дублирование раскрывающихся рубрик, архивов и т.д. Функция сама по себе полезная, ставим галочку.
Строка «Javascript escape method» — не знаю, что это такое. Языка Java не знаю, увы. Оставляем по умолчанию.
Закончив с настройками, надо нажать кнопку «Update setting», чтобы сохранить внесенные изменения. И теперь можно переходить к настройкам виджетов.
3. Настройки виджетов плагина WP-dTree
Когда я впервые увидел, что этот плагин создает 5 (!) виджетов, и сколько имеется настроек в каждом, то сначала опешил: это мне писать о них отсюда и завтрашнего обеда. Присмотревшись, я понял, что не так все страшно. Что ж, приступим, помолясь.
Сначала отбросим те, которые, по моему разумению, нам на сайте не нужны: таких я нашел 3 – Links, Pages и Taxonomy и еще один – Archives – под вопросом (понятно, что в названии каждого виджета еще написано впереди WP-dTree, но это опускаю, т.к. вся статья про этот плагин).
Виджет Links показывает всякие нужные и не очень ссылки:
Рис.3
Мне кажется, что этот виджет совершенно ни к чему. Убираем.
Далее идет виджет «Pages»: страниц у нас не так много, чтобы была необходимость в этом виджете – убираем.
Виджет «Taxonomy» — с ним я ничего не понял. Должны быть определены настройки показа, но мои попытки что-то изменить ни к чему не привели: наверно, я что-то не учел, не знаю. Оставляем все настройки по умолчанию и виджет из сайдбара убираем. Тем более, что он пока еще в бета-версии.
Виджет Archives показывает на сайте архивы по месяцам. Выглядит это так (развернутый вид):
Рис.4
Мне кажется, что это ни к чему: у меня почти полтысячи статей и их список займет чрезмерно много места. Но если Вы хотите оставить его на сайте – пожалуйста. Переходим к настройкам оставшихся двух виджетов.
4. Настройки виджетов WP-dTree Archives и WP-dTree
Настройки виджетов Archives и Categories практически идентичны. Показывать я буду на примере виджета Categories (Рубрики), настройки второго виджета (Архивы) сделайте по аналогии.
А). Настройка внешнего вида виджета WP-dTree Categories
Открываем этот виджет:
Рис.5 Верхняя часть настроек
Строка Title – вписываем заголовок виджета, например, «Рубрики».
Строка «Cache» оставляем по умолчанию.
Далее меняем «open all» и «close all» на «открыть все» и «закрыть все». Можете изменить и разделитель (separator), поставив другой символ, например, дефис или слеш.
Строка «Use lines» и «Use icons» определяет показывать или нет линии, соединяющие папки, и подключать ли картинки папок и файлов в стиле Windows.
Строка « Close same level» подключает полезную функцию, когда раскрытой будет только одна папка, а остальные – в свернутом состоянии. Аналог стиля «Аккордеон» в плагине Collapsing Categories. Галочку оставляем.
Строка «Highlight selection», по идее, как-то должна выделять открытую статью в общем списке статей. Выделение зависит, видимо, от стилей Вашего шаблона. По крайней мере, у меня в установленном шаблоне никакого выделения не было, хотя я крутил и так, и этак, правда, в CSS не лазил, т.к. стараюсь во время тестирования делать только те вещи, которые будут делать и мои читатели.
Строка «Open to selection» раскрывает в списке рубрик ту, к которой относится открытая статья. Как-то коряво у меня это обьястнение получилось. Словом, Вы открываете какую-то статью и автоматически в списке рубрик раскрывается та рубрика, к которой эта статья относится, открываете другую статью – раскрывается другая рубрика и т.д. Своеобразный аналог «хлебных крошек» — показывает, где именно на сайте Вы находитесь. Вещь полезная – галочку оставляем.
Рис.6. Средняя часть настроек
Строка «Truncate titles» определяет длину названия, значение 0 (ноль) – название показывается полностью (в сайдбаре в виджете «Рубрики», естественно) , устанавливаете другое значение, например, 50 – будет показано только первых 50 знаков. При этом подсказка (title) при наведении курсора будет содержать полное название статьи. Полезно для экономии места на сайте. Но тогда заголовки статей надо переделать: в начале заголовка должно стоять самое важное!
Строка «Exclude» позволяет исключить из навигации какие-то рубрики. Для этого надо перечислить ID рубрик, через запятую. Бывает полезным, например, если Вы участвует в статейных биржах и добавление статей на сайт идет в автоматическом режиме: качество и тематика статей зачастую просто повергает меня в шоковое состояние.
Как узнать ID рубрики (а заодно и статей, страниц, тэгов и т.д.)? Установите плагин Reveal IDs, тогда перечень рубрик у Вас в админке будет выглядеть так:
Рис.7
У Вас появится новая колонка ID (показана стрелкой), цифры в ней это и есть ID рубрик. Точно такая же картина будет и на других страницах со списками – статей и т.д.
Строка «Include» позволяет, наоборот, подключить какие-то рубрики. Эта строчка отличается от предыдущей, как я понимаю, вот чем: в той строке Вы из большого перечня рубрик какую-то рубрику удаляете, а в этой — из этого перечня разрешаете показывать только определенное – небольшое — число. Зачем это надо? Не знаю, голову сломал. Здесь надо точно так же указать через запятую ID рубрик.
Строка «Force open to» позволяет держать раскрытой какую-то рубрику при посещении сайта, т.е. посетитель заходит к Вам на сайт и сразу видит одну (или несколько) рубрик раскрытыми. Полезно для акцентирования внимания на каких-то материалах. В окне надо через запятую указать такие рубрики. (В скобках замечу, что заодно посетитель увидит, как устроены Ваши раскрывающиеся рубрики. Посетители-то разные ведь бывают)
Строка «Order» определяет порядок сортировки – в порядке увеличения (от А до Я или от 1 до 9) или уменьшения (от Я до А или от 9 до 1). По умолчанию стоит значение ASC – увеличение.
Далее, после горизонтальной линии, идут настройки показа рубрик, подрубрик и статей.
Б). Настройка порядка сортировки и показа рубрик, подрубрик и статей
Строка «Sort by» позволяет указать, по каким параметрам производить сортировку рубрик – по алфавиту (name, стоит по умолчанию), по ID, по URL, по количеству статей и т.д. Предлагаю оставить по умолчанию.
Строка «Sort posts by» позволяет указать порядок сортировки заголовков статей – по дате публикации (стоит по умолчанию), по заголовку статьи (post title), т.е. по алфавиту или по ID статьи.
Строка «Post order» определяет порядок сортировки статей. По умолчанию стоит значение DESC – самые последние статьи из опубликованных стоят на самом верху.
Рис.8 Нижняя часть настроек
Строка «Limit» определяет максимальное количество показываемых рубрик. Количество определяет общее число и рубрик, и подрубрик, причем выбираются самые верхние. По умолчанию стоит 0 (ноль) – будут показаны все рубрики и подрубрики, причем выбираются самые верхние. Зачем сделана эта функция? Наверное, на всякий случай.
Строка «Limit Posts» определяет максимальное количество статей в рубриках. По умолчанию стоит 0 (ноль) – будут показаны все статьи. Очень полезная функция, когда в рубрике очень много статей. Однако здесь пара подводных камней.
Камень первый. Как показать читателю, что в этой рубрике есть и другие статьи, и показать заголовки этих статей? Частично эту задачу решает следующая строка.
Строка «Show more link» предназначена для вывода в сайдбаре сообщения о скрытых статьях. Сначала мы изменим текст в окошке, а потом посмотрим как все это выглядит на сайте.
Вам надо вместо текста Show more написать «Показать больше» или что-нибудь в таком роде. То, что написано в скобках, трогать не надо – это показано количество скрытых статей. Чтобы Вам было наглядно видно действие этой функции, установите в строке «Limit Posts» число, заведомо меньшее, чем количество статей в рубрике. У Вас должно получить так:
Рис.9
Сохраняете внесенные изменения и смотрите на сайте:
Рис.10
Вот тут кроется второй подводный камень: при нажатии на ссылку «Показать еще» Вам откроется … нет, не заголовки скрытых статей, а архив этой рубрики. Если же нажать на ссылку «Открыть все», то просто раскроются остальные рубрики и подрубрики, но заголовки скрытых статей все равно не будут видны. Учтите этот момент.
Строка «Show descendands of:» — из всех рубрик на сайте показывается только подрубрики выбранной рубрики. Если у рубрики нет подрубрик, то не показывается ничего — раздел рубрик на сайте просто девственно чист. Зачем это сделано – не знаю. Оставляем значение по умолчанию.
Строка «Only *direct* children of:» вводит фильтр для просмотра тех или иных рубрик детьми. На Западе широко распространен родительский контроль за тем, что смотрят их дети в Интернете. У нас же… сами понимаете.
Строка «Exclude posts», как я понимаю, относится тоже к запрещениям, только она фильтрует не рубрики, а статьи.
Строка «Allow duplicate entries» разрешает показ повторяющихся записей. Здесь имеется ввиду, что одна и та же статья может быть в двух и более рубриках. По умолчанию в этой строке стоит галочка, значит, эта статья будет во всех этих рубриках. Если Вы эту галочку уберете, то она будет показана только в самой первой рубрике, если считать сверху.
Строка «Hide empty categories» скрывает пустые категории (т.е. не имеющие еще статей). По умолчанию отметка в этой строке не стоит, значит, пустые рубрики будут показаны. Нам лучше поставить галочку.
Строка «List posts» разрешает или запрещает показ заголовков статей. Когда они разрешены к показу, то выглядеть все будет так, как на скриншотах выше, а если запретить, то будет показаны только рубрики и подрубрики, т.е. просто как в WordPress’е. Зачем тогда этот плагин? Галочку оставляем.
Строка «Show post count» — показать или нет количество статей в рубриках и подрубриках. По умолчанию стоит – не показывать. Тут решайте сами.
Строка «Show RSS» — подключить или нет показ картинки с логотипом RSS в рубриках. Если у Вас есть RSS в рубриках, то еще можете подумать об этом, а если — нет, то и думать нечего. Оставляем значение по умолчанию – не показывать RSS (т.е. без галочки).
Сохранием внесенные изменения и обращается к настройке Архивов. В этом виджете все настраивается точно также, единственное отличие – строка «Type», она определяет как именно надо сортировать статьи в архивах – помесячно или по годам. По умолчанию стоит «помесячно», так и оставьте.
На этом все. Мне остается только выразить надежду, что плагин WP-dTree окажет Вам помощь в решении тех или иных вопросов.
P.S. О возможных ошибках плагина. Я их не заметил, если не учитывать некоторых неработающих функций, вот только RSS я совершенно не тестировал – на моем учебном сайте ленты RSS просто нет.
P.P.S. Статьи о других плагинах, которые создают раскрывающиеся рубрики:
— статья о плагине My Category Order
— статья о плагине Collapsing Categories.
Если говорить обо мне, то я выбираю плагин Collapsing Categories с связке с плагином My Category Order – мне они понравились больше.
Оригинал: novichkoff.ru/z-plagina-dlya-sozdaniya-raskryvayushhixsya-rubrik-plagin-wp-dtree.html#.UeK9_22JvSl
mcedit как редактор по умолчанию. Cron
Возможно многие знают, но я все же решил осветить этот вопрос. Очень часто в Linux требуется редактировать какой либо конфиг. Например, чтобы добавить задание в crontab,
мы пользуемся командой
crontab -e
В CentOS по умолчанию используется редактор vi, но для повседневного администрирования я все же предпочитаю mcedit, входящий в состав mc. Что бы сделать mcedit редактором по умлочанию, достаточно применить команду
export EDITOR=mcedit
И всё! Набрав crontab -e мы будем редактировать задание для нашего планировщика уже в привычном и простом mcedit (e)
на постоянку при баше в .bash_profile персонально или в /etc/skel для всех Оригинал:centos.moy.su/news/ms_po_defotu/2011-01-25-50
CentOS и CRON
На одном из CentOS серверов от FastVPS заметил отсутствие CRON в принципе, что меня довольно удивило. И ведь правда — не было.
Пришлось поставить вручную:
yum install -y vixie-cron
И запустить:
/etc/init.d/crond start
В автозагрузку же он попал без моего вмешательства 🙂
Оригинал: stableit.ru/2010/04/centos-cron.html
RSS & RSS to Email