Я перепроверю.

Странно: здесь вроде не начинал ничего писать. И из топика про оптимизацию сюда не переходил.

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

Супер! Утопал свои 35 на 100 исправлять))) По возможности))

Всем привет! Заметка не особо большая, но для любителей SEO важная. Предыстория Для многих давно уже не секрет, что поисковики довольно неплохо воспринимают Javascript-сайты, в том числе и те, которые не в полной мере поддерживают SSR (Server-Side Rendering). То есть, если раньше поисковики запрашивали код страницы сайта по ее адресу, получали в ответ HTML-код и делали его разбор как есть, без учета javascript, то сейчас они не просто загружают код страницы, а непосредственно ее выполняют в виртуальной машине, учитывая подгрузку сторонних стилей и скриптов, скорость рендеринга страницы и т.п. По этой причине в настоящий момент как бы и не о чем беспокоиться, когда стоит вопрос "стоит ли делать сайт на JS, ведь может пострадать SEO?". Типа, страницы теперь отлично парсятся и можно смело делать сайты на JS. Но на самом деле далеко не все так просто. Помните, что сейчас все чаще и чаще на всех углах слышится "Не думайте только о SEO, больше думайте о поведенческих факторах, юзабилити и т.п."? То есть, если пользователи дольше сидят на вашем сайте, больше выполняют всяких действий (в том числе и переходы по внутренним страницам), то считается, что они более вовлечены на вашем сайте, и ваш сайт более интересен и его надо показывать больше другим пользователям. Но что получается с JS-сайтами, у которых переходы по страницам работают не классическим способом (когда каждый переход на другую страницу - это полная перезагрузка страницы), а по принципу SPA (Single Page Application)? На таких сайтах, когда пользователь кликает внутреннюю ссылку, чтобы перейти на другую страницу, у него не происходит реального перехода, а просто подгружаются нужные данные (или берутся из кеша, не суть) и страница или часть ее перерисовывается. Другими словами для сервиса аналитики это как бы и не переход (точнее совсем не переход). Когда метрика или аналитика смотрит на "поведение" таких пользователей, они примерно видят "Пользователь зашел на сайт, пользователь сидит, что-то кликает, все еще сидит на этой странице, сидит... долго сидит... Наверно просто оставил страницу открытой". А в это время пользователь может прочитал с десяток статей (на разных страницах, естественно), написал N комментариев и т.п. Решение Чтобы на таких сайтах сервисы аналитики получали актуальную информацию о переходах, в их программных решениях предусмотрены методы "ручной" отправки такой информации. У гугл.аналитики это gtag('event', 'page_view', data); У яндекс.метрики это yaCounter.clickmap().hit(location.pathname). Кстати, этот метод устарел, надо будет найти более актуальное решение. В @prisma-cms/front я добавил код, реализующий эту логику. Сайтам, работающим на @prisma-cms, достаточно просто обновить у себя этот модуль и пересобрать скрипты, ничего более прописывать не надо дополнительно (будут использованы установленные на странице счетчики, лучше всего прописывать их в public/index.html). Вот теперь в гугл.метрике видно, что такие переходы учитываются. Profit. P.S. Кстати, еще немного относительно поисковиков и JS-сайтов. Гугл обновил свой сервис PageSpeed Insights. Наиболее заметные изменения: 1. Он стал более правильно рендерить на своей стороне JS-сайты. Еще недавно (не боле чем месяц назад) я проверял свои сайты на @prisma-cms, со всеми была одна картина: ошибок не было и сайты нормально индексировались, на PageSpeed выдавал белый снимок, то есть страница как будто пустая. Я знал, что это просто применяются устаревшие методики и рано или поздно гугл обновится и все заработает ОК, и вот теперь это как раз работает ОК, гугл видит теперь страницу нормально. Кстати, modxclub.ru для десктопа показывает 99/100, но для мобильников есть еще к чему стремиться, пока что 62/100. pivkarta.ru 97/100, для мобильников еще хуже (35/100). 2. Вкладка "Для мобильных" передвинулась влево, перед вкладкой "Для компьютеров". Видимо, гугл как бы намекает "Показатели для мобильников будут теперь учитываться выше, чем для десктопов". Думаю, стоит учесть. 3. Отчеты в целом стали более подробные и наглядные.

Таки гит в том числе для такого и придуман. Если ты делаешь на моем примере, то надо было: 1. Сделать себе клон моего проекта. Проще всего это делать прям на гитхабе, кликнув кнопку Fork. 2. Сливаешь клон себе на локал, выполняешь свои работы, коммитишь и выливаешь изменения в свой проект. Profit. В таком случае я смогу легко посмотреть что именно ты там сделал, слить к себе и запустить, посмотреть как это работает, и тогда уже дать комментарии по существу.

Не вылил. А думаешь стоит на git вываливать? Всё-таки упражнение.

Дима, а ты свои изменения куда-то вылил? Где можно увидеть твой вариант полностью?

В рамках изучения @prisma-cms и шире (React, GrahQL, Apollo client и прочее) выполняю небольшие задачки. Что-то получается (но возможно можно сделать как-то лучше), что-то не очень. Думаю, что обсуждение таких задачек будет полезно не только мне. Задача: подготовить модуль для вывода пользователей сайта modxclub.ru с открытыми кошельками и текущего баланса. Данные пользователей: имя и аватар. Базовый модуль: https://github.com/Fi1osof/test-prisma-users. Здесь уже сформирован gql запрос и вывод id пользователей. Подключение к API отсюда: https://modxclub.ru/topics/razvorachivaem-u-sebya-kopiyu-modx-kluba.html Внесены изменения в вывод данных: Есть подозрение, что вместо второй обработки массива есть более правильный вариант. С аватаркой возник вопрос. https://modxclub.ru/images/resized/thumb/9c2bd2946018db2f057ec646aac3f04f.jpeg Данных не хватает, нужно добыть название файла. Для этого добавил в gql запрос и в переменные поле image, что дало возможность сформировать ссыль на картинку. Хорошо бы добавить еще проверку на наличие картинки и вывод картинки-заглушки при отсутствии картинки.

А это закомментировали? Вообще, бесконечный редирект срабатывает из-за того, что постоянно выполняется условие редиректа. Но уверены, что редирект именно на уровне .htaccess? Может еще на уровне MODX в чем экспериментировали? 1. Закомментируйте все правила редиректа в .htaccess и убедитесь, что ошибка редиректа пропала (пусть даже и вообще перестанет работать редирект). 2. Если все дело именно на уровне .haccess, то тогда скорее всего %{SERVER_PORT} не равняется 443. Это вопрос уже настройки хостинга. То есть если эта переменная отсутствует, то она в любом случае не будет равна 443 и поэтому всегда будет выполняться редирект. По этому вопросу лучше обратиться в саппорт хостинга.