Недавно мой хороший знакомый спросил меня: «а как выключить ненужные виджеты в панели администратора WordPress для всех пользователей?». Уже было собравшись ответить — «воспользуйся закладкой „настройки экрана“ в правом верхнем углу» я вспомнил один момент — меня всегда раздражало, что эта опция не является глобальной, то есть настраивается отдельно для каждой учетной записи вручную, после авторизации.

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

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

Третьей стороной является тот факт, что иногда нужно назначить заказчику доступ уровня «Администратор», но при этом отключать, например, возможность изменения параметров — что называется, «во избежание».

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

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

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

Многоязычные сайты в принципе своем — источник постоянной головной боли. С одной стороны — техническая реализация, которая в большинстве CMS (в том числе и платных), хромает на все четыре ноги. С другой — необходимость постоянно поддерживать в актуальном состоянии уже не одну, а несколько версий сайта. А с третьей — постоянная необходимость перевода оригинальных материалов.

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

А с мультиязычным сайтом эта проблема увеличивается ровно в то число раз, сколько языковых версий ресурса было реализовано. Ядром проблемы является сам процесс получения новых материалов для сайта — сложный, длительный и дорогостоящий. Кстати, именно по этой причине, многие владельцы ресурсов, в ответ на вопрос о причинах отсутствия на сайте нескольких языков, отмахиваются и говорят: «делать мультиязычный сайт не будем — слишком сложно и дорого».

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

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

Понятно, что сразу же суетиться я не стал — потенциально, мог произойти лишь небольшой сбой в работе серверов и через максимум сутки сайт бы снова заработал (неприятно, но пережить можно). Но учитывая, что сервер «упал» во вторник утром и по состоянию на утро четверга все так же валялся пузом кверху и даже не пытался встать, я понял, что тут счастья мне точно не будет — и принял решение переезжать. (Кстати, сервер поднялся только вечером в воскресенье — через 6 дней с момента падения).

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

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

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

Но самым главным постулатом, который выражал мой собеседник практически в любой части обсуждения, был: «каким бы замечательным — даже великолепным — не был бы дизайн твоего сайта, он не поможет решить проблемы твоего бизнеса».

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

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

Короткие ссылки стали де-факто нормой для социальных сетей. Несколько лет назад толчок этому тренду дал сервис Tinyurl.com, а с повсеместным распространением Twitter и его ограничением в 140 символов, использование сокращенных URL шагнуло вперед семимильными шагами.

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

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

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

По существующим на сегодняшний день правилам, все доменные имена могут быть приобретены как физическим, так и юридическим лицом. Единственным исключением является домен .ua, владение которым закрепляется только при наличии свидетельства на торговую марку. Но с одной стороны, стоимость регистрации и продления .ua практически в шесть раз выше по сравнению с, например, .com.ua, а с другой — если у Вас нет торговой марки, приобрести доменное имя .ua Вы не имеете права.

Соответственно, даже если доменное имя регистрировалось для компании-клиента, это совершенно не гарантирует, что официально оно оформлено на владельца. Например, у хостинг-площадок есть такое понятие как «регистрация доменного имени в интересах клиента». Однако «интерес клиента» совсем не означает, что сам клиент является владельцем этого доменного имени — официально оно будет принадлежать хостеру.

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

Давайте разберемся — почему?