[Spolzer] Sticky Post 1.0.0

[Lugunika]

Lugunika добавил(а) новый ресурс:

[Spolzer] Sticky Post - Закрепляет любой один пост в теме и всегда показывает его первым на каждой странице обсуждения.

В отличие от обычных решений, аддон учитывает SEO: закреплённое сообщение игнорируется при формировании <meta name="description", поэтому поисковикам и социальным сетям отдаётся описание из первого обычного поста под закреплённым.

Это позволяет использовать закрепление без классического ляпа, когда на всех страницах темы мета-описание застревает на одном и том же sticky-сообщении.

---

Возможности​

• Закрепление любого...

Узнать больше об этом ресурсе...

 

[Sadorimatsu]

Главный вопрос, а как закрепляются? Я почему-то не найду ни кнопку, ни выбора в изменении сообщения...
Не исключаю, что слепой, но в очевидном месте нет, права групп выданы полные. Как бы у меня какой плагин не перекрывал его.

 

[Lugunika]

Главный вопрос, а как закрепляются? Я почему-то не найду ни кнопку, ни выбора в изменении сообщения...
Не исключаю, что слепой, но в очевидном месте нет, права групп выданы полные.

 

[Sadorimatsu]

Посмотреть вложение 161586

Понятно в чём дело. У вас плагин конфликтует с плагином [Berg] Telegram Post 2.2.2. Он использует ту же область.

Пример

Можно конечно насильно через модификатор это исправить, но всё же. Неудачно место выбрали.

 

[25517]

Что это за дичь вообще ? В XF уже есть механизм для предотвращения конфликтов.
Городить эту проверку вообще не имеет смысла, от слова совсем.
Но даже так, у SchemaManager есть метод columnExists.

---

Для чего здесь instanceof - загадка.
Достаточно простой проверки. Но ладно. Допустим.

---

Для чего здесь эта проверка - вообще неясно. Работы с узлом никакой нет.

---

1. Зачем тут эта дичь вообще нужна ? Есть метод fastUpdate у сущности.
Он будет в разы проще в любом случае.

2. Этот запрос вообще лишний.
Обновление данных происходит уже после postSave и postDelete.
И следовательно реляция всё ещё жива и нет смысла создавать лишний запрос.

По сути всё сводится к банальной проверке isChanged для thread_id и message_state.
А для удаления просто сделать fastUpdate предварительно проверив isFirstPost

---

В отличие от обычных решений, аддон учитывает SEO: закреплённое сообщение игнорируется при формировании <meta name="description", поэтому поисковикам и социальным сетям отдаётся описание из первого обычного поста под закреплённым.

А тут вообще придумал проблему и героически её решил.
Достаточно взглянуть только на \XF\ThreadViewData::getFirstPost

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

Дальше по коду мне уже даже впадлу комментировать.
3 цикла подряд + один вообще лишний запрос.

 

[Lugunika]

Что это за дичь вообще ? В XF уже есть механизм для предотвращения конфликтов.
Городить эту проверку вообще не имеет смысла, от слова совсем.
Но даже так, у SchemaManager есть метод columnExists.

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

Для чего здесь instanceof - загадка.
Достаточно простой проверки. Но ладно. Допустим.

instanceof здесь ставился как защитная проверка на фактический тип связанной сущности, чтобы логика не завязывалась только на наличие relation.

Для чего здесь эта проверка - вообще неясно. Работы с узлом никакой нет.

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

1. Зачем тут эта дичь вообще нужна ? Есть метод fastUpdate у сущности.
Он будет в разы проще в любом случае.

2. Этот запрос вообще лишний.
Обновление данных происходит уже после postSave и postDelete.
И следовательно реляция всё ещё жива и нет смысла создавать лишний запрос.

По сути всё сводится к банальной проверке isChanged для thread_id и message_state.
А для удаления просто сделать fastUpdate предварительно проверив isFirstPost

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

А тут вообще придумал проблему и героически её решил.
Достаточно взглянуть только на \XF\ThreadViewData::getFirstPost

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

Там задача была не придумать отдельную проблему, а исключить закреплённый пост из источника meta description после изменения порядка вывода сообщений. То есть упор был именно на результат в шаблонной выдаче страницы.
По \XF\ThreadViewData::getFirstPost() и по разным типам тем принял, это как раз то место, которое стоило учитывать

 

[25517]

чтобы установка и удаление не упирались в повторный запуск шагов

Оно физически не сможет упереться в это. Оно вызывает только один раз при установке/удалении.
Они уже по определению идемподентны. Чтобы сломать это - надо быть криворуким дебилом.
Потому смысла делать эту проверку нет, от слова совсем.

instanceof здесь ставился как защитная проверка на фактический тип связанной сущности, чтобы логика не завязывалась только на наличие relation.

В этом также нет никакого смысла. Реляция всегда возвращает, либо сущность/коллекцию, либо null.
Других вариантов там попросту нет. Потому проверка типа не имеет смысла.
Это просто избыточно.

Если реляция не была загружена - под капотом просто сделается запрос и сделает hydrate в сущность.
В случае если передано было в with - то точно также будет сделан hydrate в сущность.
Там даже в теории не может быть сырых не типизированных данных.

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

Это ответственность темы, а не постов в ней.
Посты работают с узлом только в случае - если надо проверить опции в самом узле, по типу count_messages.

В остальных случаях наличие узла даже не оспаривается.
Потому что если тема не имеет узла - это проблема уровня темы, а не постов.

Так что имхо, но эта проверка лишняя.

Там задача была не придумать отдельную проблему, а исключить закреплённый пост из источника meta description после изменения порядка вывода сообщений.

Повторюсь. Там проблемы не было. От слова совсем.
Для типа темы discussion первый пост - это первый пост на конкретной странице.
И в шаблоне для meta description используется как раз первый пост с конкретной страницы.
Там хоть задом наперёд порядок будет - в мету попадёт именно первый пост с конкретной страницы.




Другое дело, если тип темы question - там всегда будет попадать первый пост всей темы.
Но думается мне, что разрабы специально так сделали, чтобы всегда были корректные данные.