Андрей Бережной: Alex: в первую очередь, у qTranslate и WPML (или близкого к нему бесплатного Polylang) совершенно другая схема работы. qTranslate - один объект, каждое значение содержит все переводы, разделенные спецразметкой. WPML/Polylang - каждый перевод это отдельный самостоятельный объект, переводы - это отдельные объекты, связанные между собой таксономией "язык". Какой подход лучше - зависит от задач. Скажем так, у каждого из них есть как плюсы, так и минусы. В зависимости от задач будет перевес в ту или иную сторону. Но недостатки останутся, и у того, и у другого решения. А зачастую именно недостатки становятся камнем преткновения в реальных проектах.
Михаил Снэ Бьёрн Палагин: я вам только 2 примера привел, а их вообще решений много, в том числе на PHP, например. Есть Open Source, есть коммерческие. По поводу заработка - брать комиссию с транзакций или ввыплаты автору, это основной источник. Иначе - гроши на рекламе, или дополнительный доход за счет оффлайн-активности, использующей бренд (конференции, тренинги и тд)
Андрей Хохлов: ну, в вашем случае реализация вполне рабочая, изначально я подозревал более упрощенную процедуру. Так что можно не заморачиваться - работает, и хорошо.
По коду в гисте - да, все именно так. Удобнее ведь, правда?
Андрей Хохлов: 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, или о своих, кастомных аватарках, которые юзеры загружают (через плагин или свой код)
