Андрей Хохлов: ну, в вашем случае реализация вполне рабочая, изначально я подозревал более упрощенную процедуру. Так что можно не заморачиваться - работает, и хорошо.
По коду в гисте - да, все именно так. Удобнее ведь, правда?
Андрей Хохлов: nginx + php-fpm это уже прошлый век, попробуйте nginx (с SPDY, скоро HTTP/2) + hhvm (c php-fpm в качестве fallback). Разница с апачем не то что большая, она космическая. Особенно при нагрузках. Да и сам php-fpm + nginx в разы шустрее и стабильнее апача. Единственная прелесть Apache, секрет из-за которого его юзнают на shared-хостингах и тд - потому что .htaccess. Потому что можно включать-выключать и менять настройки для каждого юзера/сайта или даже папки на лету. В ущерб производительности, но удобно.
Вадим Тимофеев: ссылки на файлы, шаблоны и тд (если их не захардкодили) используют get_template_directory_uri() и подобные функции, которые, в свою очередь, используют функции home_url() и site_url(), которые, в свою очередь используют значения констант WP_HOME / WP_SITEURL из wp-config.php, как написал Алексей POS_troi, а если данные константы не определены, то используются значения опций home / siteurl из таблицы wp_options. Таким образом, большая часть URLов генерируется динамически. Поменяйте эти 2 опции в БД или установите нужные константы в wp-config.php и большая часть проблем с адресами исчезнет. Останутся только значения guid для постов и страниц - они в БД прописаны в таблице wp_posts в столбце guid. Там сделайте поиск-замену.
Вадим Григорец: вполне возможно что все одиночные шаблоны (page.php, single.php) как и архивные (главная, поиск и тд) используют субшаблоны, включая их с помощью функции get_template_part(). Соответственно, ищите в папке темы файлы content.php, content-default.php и подобные. А еще лучше, поищите "поиском по файлам и папкам" во всей папке темы - будет найдено все, что надо.
Вставьте ссылку на тему, желательно GitHub репозиторий или SVN на WordPress.org. Это как самый-самый минимум - без кода никто не сможет ничем помочь. Если вы надеетесь, что кто-то будет тратить время на самостоятельный поиск вашей темы, потом поиск ее исходного кода и его изучение - вы сильно ошибаетесь.
sim3x: с точки зрения SEO наиболее оптимальным является:
- если контент полностью зеркален - domain.com/lang/
- если контент отличается, в том числе структурой - lang.domain.com
Есть вариант переключения языков через GET параметр и другие методы, не меняющие урл контента, но с точки зрения SEO это плохая практика, так как контент на разных языках будет иметь одинаковые урл, что = дубликаты. Такой вариант допустим только если в индекс отправлять основной язык (английский, например), а другие языки не индексировать вообще. Чаще всего применяется на сайтах UGC, когда, по сути, переводится только интерфейс сайта несколько стандартных страниц типа "о проекте", "политика безопасности", а весь остальной контент идет на разных языках вперемешку либо фильтрами. Примеры - facebook, kickstarter.
sim3x: маршрутизация отдельно, данные отдельно, но в урл должен быть отражен язык, если контент мультиязычный. домен.рф/версия языка/итд - как раз правильный подход.
И еще одно уточнение? Речь идет об кастомном дефолтном аватаре, вместо стандартного, о замене gravatar, или о своих, кастомных аватарках, которые юзеры загружают (через плагин или свой код)
Finom: таки нечитабельно. Представляю, если каждый будет свои теги придумывать - стандарт как таковой перестанет существовать. Бред. Кроме того, ваши утверждения по поводу моды на семантику и тд - в корне неверны.
trevoga_su: а с чего вы выводи делаете по поводу говносайтиков, старожил вы наш? :) До перехода в свое дело я был Head of Development на крупнейшем телеканале сраны, который входил в международную сетку из 16 каналов в странах Европы. Под моим руководством было 42 человека, из которых 16 работало из других офисов канала по всему городу, а 12 - из других стран. Плюс, ядра практически всех наших проектов разрабатывались и поддерживались общей командой из нескольких стран, например, движок новостных сайтов каналов (который включал интеграцию с новостной службой канала и энкодинг видео, лайв стриминг, свою реклламную прощадку и кучу других плюшек) разрабатывался силами 6 стран. И вся команда, естественно, работала дистанционно. А также у нас была на все 16 каналов команда из 80 кнопконажимателей в Бангалоре - они писали тесты, доки и все что попроще. Или, например, внутреннее приложение для канала, которое позволяло вести график озвучек, бронировки голосов (артистов), оплат, трекинга работ, занятости студий и прочее-прочее - основу сделала наша команда, после вывода на уровень сети проектом также занималась команда из 4х стран. И все это прекрасно работало удаленно/дистанционно. Завязка на другие подразделения канала очень плотная - и новостная служба (а там вообще отдельный мир и они себя богами считают), и маркетинг, и спутниковый канал, и техотдел, который за железо отвечал и тд. И это все разбросано по всему городу в разных офисах, да еще и со сложной бюрократией. Да, компания тратила заметные суммы на телефонные звонки и командировки - раз в месяц я и мои коллеги из других стран встречались в реале в каком-то из наших городов и 3-4 дня плотно работали и синхронизировались, каждый брал с собой 1 человека - либо проджетка, который сейчас актуален, либо senior developer'а, либо дизайнера и тд. Собирались все вместе в реале, обсуждали, стартовали работу и делали основной задел. Дальше разъезжались и нормально работали удаленно. Скайп конечно больше для локального общения в городе был, а для международных чаще использовались видеоконференция через Циску. И это все еще в далеком 2008 году.
Так что не надо яйцами тут бряцать, не вы один опыт имеете. Правильно вам уже сказали - если у вас не получается, это не означает что у других не может. Да, это может быть дороже, да, может медленнее, да, менее удобно чем подойти к соседу и дать подзатыльник. Но, тем не менее, такая схема есть и она работает.
Игорь Б: ниша не то чтобы специфическая, она просто только начинает формироваться, и все проекты пока - скорее эксперименты и proof of concept. Поэтому я и написал - что это будет СКОРО, а не есть уже сейчас. Просто, учитывая, что хорошую платную тему или плагин сделать - вопрос нескольких месяцев, все, кто в теме, начинают уже сейчас.
Игорь Б: Нет, это заказы были на типовые, стандартные на данный момент сайты. Секрет этой штуки в том, что скоро можно будет WP использовать чисто как фрейм + админка, но при этом на том же Ember например сделать и само веб-приложение, и свою админку (личный кабинет) на фронтенде. А самое главное - одну и ту же основу (WordPress + контент на нем) можно использовать для разных приложений одновременно - и для мобильных приложений, и для чистых запросов по АПИ, и для веб-приложений, и для сторонних сайтов и тд. В общем, полная свобода и отвязка от механизма стандартных тем WordPress. Как известно, одним из больших минусов WP для многих разрабов является отсутствие нормального привычного шаблонизатора и MVC. Так вот, с помощью этого АПИ можно использовать любой свой шаблонизатор, а контроллер будет просто получать данные по АПИ от WP. Ну и это только основные моменты, а возможных случаев применения - масса.
