1. Приветствуем Вас на неофициальном форуме технической поддержки XenForo на русском языке. XenForo - коммерческий форумный движок от бывших создателей vBulletin, написанный на PHP.

1 форум много доменов.

Тема в разделе "Вопросы и ответы по XenForo Framework", создана пользователем AfterWork, 13.10.2016.

Загрузка
  1. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    На просторах интернета накопано следующее:

    Как делать зеркала форума

    проходим по адресу вашсайт.ру/admin.php?options/list/basicBoard и из поля URL форума и роутинг главной страницы вырезаем всё, чтоб ничего не осталось.
    Вуаля, теперь когда вы заходите по ссылкам с другого домена, Вас не перекидывает никуда, т.к. из-за отсутствия домена в настройках, Ваш браузер теперь подставляет домен вместо сервера.

    И для того, чтоб ссылки разных доменов в сообщениях не перебрасывали ваших пользователей с домена на домен пользуемся этим:
    Решение проблемы с "перепрыгиванием" пользователей с домена на домен принадлежащий 1 форуму
    Эта модификация позволит при наличии двух доменов для одного домена изменять ссылки так, чтоб ваших пользователей не перебрасывало с домена на домен.


    Порядок действий:
    1. Изменяем в коде домен1.ру на ваш главный домен, домен2.ру изменяем на второй домен

    2. вставляем получившееся в шаблон header.
    3. Сохраняем.
    4. Радуемся.

    Опубликовал всё это господин HellFire с форума ксенфоро.инфо

    Собственно вопросы:
    На сколько правильным является такой подход к вопросу?

    Придумал, пока чисто умозрительно, другой вариант решения этой проблемы. Выглядит он так:
    Пишем плагин который меняет в ссылках перед отображением страницы домен с того который есть, на тот с которого зашел пользователь. Меняем только при отображении, в базу не лезем.
    То есть в базе есть ссылки 111.ру/блаблабла1/, 222.ру/блаблабла2/, 333.ру/блаблабла3/, но пользователю зашедшему с домена 111.ру они отображаются все как 111.ру/блаблабла1/, 111.ру/блаблабла2/, 111.ру/блаблабла3/, а с домена 222.ру соответственно 222.ру/блаблабла1/, 222.ру/блаблабла2/, 222.ру/блаблабла3/ и так далее.

    Собственно как подойти к написанию этого плагина? С какой стороны начинать копать? Какие подводные камни на ваш взгляд могут быть?
    Хотелось бы решить задачу не отходя от идеологии ксены.
     
  2. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    То что пока надумалось:
    Процесс замены урлов полагаю надо встраивать куда-то на уровень responseView('XenForo_ViewPublic_... Потому что как я понимаю именно это отвечает глобально за формирование конечного html. Я в верном направлении мыслю?
    Есть еще проблема получения имени домена с которого зашел пользователь. А вот где это искать я вообще пока не понял. Ведь пользователь может быть и гостем...
     
  3. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 941
    Симпатии:
    3 521
    Версия XF:
    1.5.9
    С этим как раз вообще проблем нет. Посмотрите XenForo_Link::convertUriToAbsoluteUri. Там есть следующая строка:
    Код:
    $paths = XenForo_Application::get('requestPaths');
    Ну а оттуда уже забираете имя домена, по которому обратились: $paths['host'].
    А вообще по теме я думаю так. Может быть поручить замену ссылок яваскрипту будет практичнее, чем пытаться писать такой плагин. Пусть браузер пользователя ссылки переделывает. Зато сервер не будет напрягаться. Да и учесть, где могут быть прямые ссылки, достаточно сложно. Ведь функционал форума может быть расширен и другими плагинами. То есть, если Вы будете только сообщения парсить и там менять ссылки, то контекст, формируемый другими плагинами, Вы не проконтролируете. Да и даже в случае штатного функционала есть переписки, есть сообщения в темах, есть сообщения в профиле. И везде потребуется внесение изменений в вывод. Ну или (крайне непроизводительно!) уже готовый вывод страницы обрабатывать - это можно сделать через тот же хук шаблона.

    И еще по теме, если уж так сильно хочется, то самый простой вариант добраться до выходных данных, то расширяйте соответствующие модели, а не вьювер, в котором будет уже много лишнего. Например, XenForo_Model_Post. Там в методах типа getPostById после вызова родительского можно изменить выходные данные.
     
    Mirovinger нравится это.
  4. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Спасибо. Посмотрю.

    Насчет явы думал. Но тут есть проблема. Не все разрешают исполнение явы у себя на машине.

    Я потому и стал смотреть в направлении обработки той информации что готова к отправлению в браузер. Это фактически уже голый html и переделать его на лету не особо сложно. Я понимаю что несколько дикость расширять базовые классы, но разве есть другой выход? Я мыслю в целом верно или несу ахинею?
    Да и еще про хук шаблона можно чуть поподробнее.
    Вот тут я не совсем понял. Почему именно модель? На сколько я понимаю в модели придется работать совсем не с html. Это разве не будет сложнее?
     
  5. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 941
    Симпатии:
    3 521
    Версия XF:
    1.5.9
    А Вы попробуйте поработать с форумом без скриптов. Теоретически это возможно, но практически никто скрипты на форуме отключать не будет.
    Производительность сильно упадет. Поэтому и не рекомендую.
    Расширять базовые классы - это суть любого плагина, меняющего или слегка добавляющего функционал (не сущности). Поэтому это нормально.
    В главном шаблоне форума PAGE_CONTAINER есть такая строка:
    Код:
    <xen:hook name="page_container_head">
    и такая:
    Код:
    <xen:hook name="body">
    То есть Вы можете в своем плагине, использующем хуки "page_container_head" и "body" получить уже готовое содержимое header и body, которые изменяются на Ваш вкус. Использование хуков есть в видеоуроках How To Use Template Hooks. Но учтите, что в будущих версиях XenForo хуки уберут.
    Нет, это не будет сложнее. И это будет более производительно, так как позволит изменить контент еще до обработки различными форматировщиками и хелперами. Также там будет только контент, а не весь HTML-код страницы. Но нужно менять все модели, которые возвращают контент. А это может быть довольно много. Ведь есть и официальные плагины типа менеджера ресурсов, так и неофициальные типа блогов и новостей. Поэтому-то проще действительно доверить всю работу с содержимым страницы скрипту на этой странице. Пусть клиент обрабатывает - ему это не сложно. Обрабатывать все на сервере - просядет производительность, хотя и возможно.
     
  6. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Вы не поверите как много людей отключают скрипты. И я в их числе. У меня ява и флэш вырезаны с компа с мясом.
    Остально пока читаю.
    --- добавлено : Oct 15, 2016 10:58 PM ---
    Главный вопрос на сколько сильно? Ради отказа от выполняемых на клиенте скриптов некоторая потеря производительности вполне обоснованна.
    Я не совсем верно выразился. Под базовыми классами я подразумевал те которые базовые для самой ксенфоро. Как-то так. В общем сам пока не совсем понимаю что именно я имел ввиду. :)
    Спасибо еще раз. Буду изучать.
    Вот это в основном и смущает. Не хочется провозиться кучу времени и сделать то что перестанет работать через месяц.
    Ясно. Хотя пока и не понятно.
    Вот-вот-вот. Именно этого хотелось бы избежать. Иначе процесс разработки будет вечным. :)
    То что просядет это факт. Вопрос на сколько сильно просядет. Если в 2-3 раза то это один разговор, а если в 20-30 то совсем другой.
     
    Последнее редактирование модератором: 23.10.2016
  7. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 941
    Симпатии:
    3 521
    Версия XF:
    1.5.9
    Простая замена навряд ли на порядок ухудшит производительность, но вдвое снизить, наверное, сможет. Но опять таки, это скажется на конкретном участке выполнения кода, а не на всем движке, что в результате снизит суммарно уже не на 50%, а меньше. Вас это должно радовать :)
     
  8. Kolya groza morey

    Kolya groza morey Местный

    Регистрация:
    14.06.13
    Сообщения:
    367
    Симпатии:
    118
    Версия XF:
    1.5.9
    Ява или яваскрипт? Если яваскрипт тогда у вас половина функций форума не работает (уведомления, цытирования, лайки, ВВ-коды итп)
     
    Mirovinger нравится это.
  9. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Радует. Хотя и не ясно пока как вообще всё это делать. :D
    --- добавлено : 16 окт 2016 в 16:56 ---
    Видимо только ява...
     
    Последнее редактирование модератором: 24.10.2016
  10. Kolya groza morey

    Kolya groza morey Местный

    Регистрация:
    14.06.13
    Сообщения:
    367
    Симпатии:
    118
    Версия XF:
    1.5.9
    Тогда Вы ошибаетесь что
     
  11. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Нет, не ошибаюсь. У меня есть основания так говорить.
    А вот Вы насчет того что половина форума не работает действительно ошибаетесь. Пробовал отключить. Ксена вполне нормально отрабатывает и без скриптов. То что перестает работать можно назвать небольшими неудобствами но не более.

    Так что вариант с яваскриптом хоть и имеет право на жизнь и даже, признаю, гораздо более удобен в осуществлении, но не тот случай который подходит мне. Для моего случая дешевле купить более производительный сервер чем использовать даже ява скрипт.
     
  12. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 941
    Симпатии:
    3 521
    Версия XF:
    1.5.9
    Ну знаете ли, редактор не работает, загрузка файлов не работает, оповещения не работают. Вы уверены, что все скрипты выключили на странице?
    Я пробовал через uBlock. Все скрипты. При нажатии кнопки "Ответить" пытается загрузиться страница с редактором ответа. Окно редактора при этом не загружается. В результате невозможно даже ответ запостить. Загрузка файла также работать не будет.
     
    Mirovinger и Kolya groza morey нравится это.
  13. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Ответить то как раз можно. Просто неудобно. Но если ставишь такой уровень неработы со скриптами то говорить о неудобствах как-то мягко говоря неуместно. :)

    Я понимаю что спор о удобствах может быть бесконечным. Но суть в том что есть 2 пути решения задачи. И мне бы хотелось решить её именно второым способом.
     
  14. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 941
    Симпатии:
    3 521
    Версия XF:
    1.5.9
    Информацию я для этого Вам предоставил. Реализация довольно проста. Действуйте! :)
     
    Kolya groza morey нравится это.
  15. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Действую. :)
    Как только будет надо что-то еще буду спрашивать. :)
     
  16. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Я всё-таки решил смотреть именно на responseView.
    Лезть в модели, это как минимум модифицировать массу разных моделей. А на сколько я понял responseView проходят любые данные которые идут в браузер. И фактически решение будет просто модификация функции responseView. Я верно мыслю?
    То есть добавляем прямо в responseView приватную функцию которая перед возвратом модифицирует возвращаемые данные через текстовый поиск по маскам заданным в настройках и замену на маску которая будет получена из $paths = XenForo_Application::get('requestPaths'); $paths['host']
    Такой вариант будет работоспособен? Или чего-то не учел?

    И еще вопрос.
    Я верно понимаю, данные из модели передаются в контроллер, на выходе контроллера идет уже готовый html (его то и формирует responseView ), а дальше этот документ передается вебсерверу который его обжимает гзипом (если указано) и отправляет в браузер? Есть еще какие-то этапы обработки которые я не учел?
     
  17. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 941
    Симпатии:
    3 521
    Версия XF:
    1.5.9
    А что Вам мешает в режиме отладки посмотреть, что и как происходит?
     
  18. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Для начала отсутствие инструментов. К сожалению пишу просто в текстовом редакторе. Как-то пробовал запустить среду разработки в основном ради отладчика. Провозился неделю без результатов и плюнул. Отладчик категорически отказался работать, а среда ради среды как бы и не очень нужна.
     
  19. infis

    infis Местный

    Регистрация:
    27.06.11
    Сообщения:
    5 941
    Симпатии:
    3 521
    Версия XF:
    1.5.9
    Очень советую все же научиться работать в современной IDE с отладчиком. Множество вопросов сами собой отпадут. К слову, отладчик - это ведь не самая главная фишка IDE. Важно и то, что она умеет автоматическое дополнение команд и конструкций и подсказку параметров. В противном случае уже совсем не просто будет разобраться во всех классах, интерфейсах, методах.

    В общем написать качественный плагин просто в текстовом редакторе даже для профессионала сложно. Могут быть банальные опечатки и т.д. Да и в голове держать все методы и параметры всех классов - то, как минимум, сложно.
     
  20. AfterWork

    AfterWork Активный пользователь

    Регистрация:
    14.04.15
    Сообщения:
    49
    Симпатии:
    0
    Версия XF:
    1.5.10
    Я как то привык использовать IDE только как отладчик и справочник. Да и программирование скорее хобби чем серьезная работа.

    Сложно но можно.
     

Поделиться этой страницей