hedgehog

Надо получить значение поля и в зависимости от него добавлять класс либо body, либо какому-нибудь другому врапперу. http://habrahabr.ru/post/163501/ PS: кстати, есть замечательный модуль Panels, позволяющий организовать контент как угодно. Например, в несколько колонок. Может, он подойдет?

У тебя нет файла wp-config.php в public_html. Либо ты его удалил, либо не установил как следует Wordpress. А ошибка возникает потому, что WP не находит конфиг в каталоге с index.php и пытается проверить, нет ли его на уровень выше, куда доступа у PHP нету.

Вордпрессу параллельно на DOCTYPE. Что в шаблоне header.php укажешь, то и будет. Это у Drupal есть дефолтный html.tpl.php, в котором указан доктайп, но его легко переопределить, создав такой же шаблон в своей теме.

Искать плагин или писать самому. Пользовался похожим плагин для архивов, буду на работе - посмотрю название.

http://htmlbook.ru/css/background-size

Тут я вижу три варианта: 1. Не включен mod_rewrite на сервере 2. Запрещено перепределение rewrite правил через .htaccess (+Options, кажется) 3. У WP нет доступа на запись в .htaccess (об этом пишется в настройках permalinks) В любом случае, первым делом надо зайти на страницу настроек пермалинков и тыцнуть "сохранить". WP попытается записать нужные правила в .htaccess и выдаст ошибку, если это сделать не удалось.

Аська? Не олдскул Был бы IRC... Извините за офтоп, не удержался

Есть один нюанс. Если это сторонняя тема, которую планируется обновлять, то лучше не трогать ее код. Свой CSS можно подключить плагином. Либо, если изменений планируется много, можно использовать дочернюю тему.

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

Я чаще встречаюсь с заказами на WP, нежели Joomla. Но с джумлой работать не хочется, совсем А WP поначалу очень даже прост и понятен. Только потом начинаешь замечать ущербность и неприятные моменты. Но как блоговый движок - очень даже неплох. PS: а по поводу плагинов... и для вп, и для джумлы плагинов - вагон, но большинство нужных плагинов и экстеншнов для джумлы - платные.

Правильно. Потому что вы ничего не возвращаете в ответ. Уберите редиректы из my_action_callback(), вместо этого возвращайте JSON объект с адресом страницы, на которую нужно редиректить (см. json_encode). А редирект выполняйте средствами javascript после получения ответа. И еще: в проверке is_home() при аякс-запросе смысла нет. my_action_callback() ничего не знает о том, какую страницу сейчас просматривает пользователь. Проверку необходимо делать на фронтенде и передавать с аякс-запросом в объекте data. Например, добавив свойство isHome: 0/1

И как, не возникает противоречий между и Ну вроде так и делаю же.. Данные должны отправляться на wp-admin/admin-ajax.php, а не к functions.php или куда-либо еще (вообще-то, если поиграться с include, можно отправлять на любой свой скипт, но сейчас этот вариант не рассматриваем). И, повторяю, не надо добавлять переменную action в сам URL, т.е. ?action=my_action можно убрать.

Эм, в ответ должен приходить URL целевой страницы, на основании которого редиректит уже Javascript, а не PHP. А данные отправляются все так же на admin-ajax.php ? Работает это так: 1. admin-ajax.php получает данные и инклудит нужные файлы (его трогать нельзя, если там есть какие-то свои модификации, их необходимо отменить) 2. если найдена функция, отвечающая за обработку нужного action, управление передается ей 3. если функция возвращает какие-то данные, они возвращаются обратно клиенту PS: '?action=my_action' в url не надо. Эти данные и так передаются POST'ом (см. объект data).

По рукам линейкой! Это "системный" файл Wordpress, его трогать противопоказано и add_action там не место. Все хуки (add_action) добавляйте в functions.php Основное предназначение фильтров - это изменение каких-либо данных перед тем, как эти данные отобразятся или пойдут обрабатываться дальше (обычный хук), в то время как action - это нечто сродни событиям

Эм, а подробнее? В корне Wordpress лежит какой-то Ваш PHP скрипт, в котором производятся манипуляции с add_action? Если нет, то в на какой файл указывает ошибка "Fatal error: Call to undefined function add_action()"?

В том, что автор не понимает суть работы setTimeout/clearTimeout. Первая функция вызывает некую функцию с задержкой, а вторая - отменяет действие первой. В описанном случае происходит так: 0. Устанавливается таймаут для вызова MoveBg через 200ms 200. Вызывается функция и начинает работать 10000. Отменяется таймаут для вызова функции MoveBg. Но всем пофиг, она уже вызвана Этот вариант сработал бы, если бы использовался setInterval при первом вызове, а каждый вызов функции MoveBg единоразово двигал бекграунд на определенное количество пикселей. Но в этом случае можно еще вызывать функцию MoveBg рекурсивно через setTimeout, проверяя перед вызовом время, счетчик, координаты или что-либо еще.

Вот: Это не "пароль у юзера имеется", а "при попытке авторизации был использован пароль". mysql -u root ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO) mysql -u root -p_Wrong_Password ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) mysql -u USER_DOESNT_EXIST -p_Wrong_Password ERROR 1045 (28000): Access denied for user 'USER_DOESNT_EXIST'@'localhost' (using password: YES) Дальше капитанить я не буду

Как по мне, так там четко написано, что связка логин/пароль не подходит.

На какой адрес отправляется запрос?

На главной странице меню находится в div#main, а на странице блога - в header#masterhead. Поэтому в первом случае меню "выталкивается" хедером вниз, а во втором - находится внутри самого хедера. Это переработанная тема twenty-twelve?

Поищите в коде wp commerce вхождения add_action и wp_head в одной строке. Ну и по canonical.

Может, у на хостинге включено кеширование/оптимизаторы?

Ну, во-первых, API виджетов для социалок обычно принимают в качестве аргумента язык, на котором должен быть отображен текст. Во-вторых, ты всегда контролируешь контент, который ты отдаешь, поэтому на стороне сервера для русского языка ты можешь отдавать один виджет, а для английского - другой. При этом у тебя сайт один и тот же, просто меняется содержимое и, возможно, виджеты. При желании можно реализовать и небольшие различия в структуре. На вопрос "как реализовать" ответ очень простой: управляющие конструкции. Банальнейший пример на PHP: function get_widget($lang = 'ru') { switch ($lang) { case 'ru': return 'Русский VK виджет!'; break; case 'en': return 'English FB widget!'; break; } return ''; }

functions.php выбранной темы (но если тема не ваша и предполагается ее обновление, то после обновления изменения пропадут), либо плагином. Третий вариант - дочерняя тема

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