0 Пользователей и 1 Гость просматривают эту тему.
  • 15 Ответов
  • 4490 Просмотров
*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com
Борьба с двойными ссылками/содержимым.

(Проблема многократно обсуждалась, но хочется акцентировать внимание новичков, вроде меня, а также привлечь внимание профи от программирования (см. вторую часть поста)).

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

Что влечёт за собой такая неопределённость?
Лично для меня встала проблема организации меню с подсветкой пунктов, а также привязкой модулей к конкретной странице, связанной с пунктом меню.

Для примера, возьмём структуру меню, в котором все пункты - активные ссылки:

         Продукты
      Хлеб
      Рыба
      Мясо
   
Т.е., действуя по логике, хочется получать по клику на «Продуктах» блог (краткое содержимое) из статей «Хлеб», «Рыба», «Мясо».

Собственно, я так и сделал на своём сайте, и всё было хорошо и логично, пока не выяснилось, что ссылка из меню «Хлеб» на конечную страницу и ссылка «Подробнее из блога «Продукты» - это не одно и то же.

Заходя с меню мы получаем активный пункт меню «Хлеб» (если в таблице стилей прописано выделение активных пунктов, то он подсвечивается), а вот зайдя из блога получаем в меню ДУЛЮ. Максимум, чего можно добиться, это подсветки родительского пункта «Продукты».
Можно, в общем, жить и так, отключив подсветку конечных пунктов меню, если дело не касалось ещё и модулей. К примеру, если бы вам вздумалось к меню «Хлеб» привязать модуль с рекламой «Покупайте булки с изюмом!» то при заходе с меню вы бы его увидели, а при заходе с блога – нет. Что, согласитесь, потеря аудитории  >:(.

Покопав Интернет, обнаружил, что проблема системная.
И борются с ней, в основном, создавая из родительского пункта «Продукты» ссылку на статичную страницу, в которой создают фактическую копию блога содержимого раздела, только уже в виде обычного хтмл-а. Ну и уже с этой странички ведут ссылки на конкретные статьи (т.е фактически-обычные URL-ы).

Вроде бы проблема решена, не изящно, но хоть как-то.
Но при таком подходе мы
А) создаём дубли материалов
Б) теряем гибкость блогового отображения контента
Г) при выводе содержимого на главную (галочка «публиковать на главной») получаем те же грабли – ссылка «подробнее» выкинет нас на страницу, не связанную с конечным пунктом меню и соответствующими ему модулями.

Хорошо, можно и это обойти, забив в шаблон пару лишних позиций для модулей и вывести в них ХТМЛ-статику с конкретным url-ом на конечную страницу.
Но тогда встаёт логичный вопрос – зачем тогда гибкая система блогов и краткого содержимого материалов, если мы всё заменяем статикой?

Первое, что пришло в загруженную голову -  прикрутить mod_rewrite и тупо менять все ссылки с блогов на «правильные»-связанные с меню с помощью правил.
Те, кто в танке, наверно оценят «изящность решения»  ^-^
Собственно, я сам додумался, что это – путь в бездну.

Дальше пришла идея то же не самая изящная, но уже не связанная с серверным ковырянием – можно при выводе блога (настройка пункта меню «Продукты»-блог содержимого раздела) отключать показ ссылки «Подробнее».
Далее прописываем в превью каждой вложенной статьи (хлеб, рыба, мясо) свою ссылку «читать делее» (URL пишем тот, который выдаётся при щелчке на соответствующем пункте меню. ВАЖНО! В настройках пункта меню ставим галочку «Формировать уникальный itemId»).
Теперь, чтобы избежать появления нашей ссылки «читаем далее» в основном материале придётся отключить показ вводного текста в каждой статье.
Можно часть водного текста (или весь) дублировать в основном содержимом.
Разумеется, без ссылки «читаем делее».

Что в результате?
Контент всё равно приходится дублировать (имеется в виду перенос вводного текста, «запорченного» наше самодельной ссылкой), но уже в рамках ОДНОЙ страницы. Т.е. отпадает необходимость создавать статичное содержимое и лазить в него каждый раз при смене материала статьи (его заменяет генерируемый блог).

Теперь нам доступен полноценный блог и мы можем логично организовать двухуровневое меню. Плюс, отключив в выводе показ кнопки «подробнее» также и на главной, мы можем публиковать на ней наши статьи, которые корректно выведут нас на страницу с привязанным меню и модулями (отключаем через ‘Меню-mainmenu (главное меню, может назваться по-другому)’).

НО. Если вы выводите на главную ещё и НОВОСТЬ, то вас ждёт закономерный облом виде отсутствия кнопки «подробнее».
Что лично для меня уже не является критичным. Новости можно выводить через многочисленные модули (под новостью подразумевается любой материал, не привязанный к конкретному пункту меню). В таких модулях есть собственная настройка показа ссылки «подробнее»,  таким образом мы можем разграничить наши интересы.

Теперь внимание ПРОФЕССИОНАЛАМ от программирования.
Есть идея сделать процесс более изящным.
Хочется, чтобы местные гуру высказали своё мнение по теме автоматизации процесса.

Итак, вариант первый и малокровный:

Сделать то же самое с заменой кнопки меню, но уже с помощью мамбота.
Думаю, что-то типа http://ext.joom.ru/smartlink-premium.html подойдёт.
Можно модифицировать под себя.
Цель-обеспечить большую гибкость решению. Т.е. работу локальных ссылок без привязки к URL сайта. Плюс можно вообще «отключение» собственной кнопки по желанию, без стирание по всем статьям. Опять же, сохраняется возможность написать своё название ссылки на подробности, что приятно.

Вариант второй. Сложный (но жутко заманчивый)

Сделать мамбота для генерации ссылки «подробнее» в авторежиме.
Чтобы он определял, привязана ли статья к конкретному пункту меню и, если привязана, то генерировал связанную с пунктом ссылку. 

На сколько я понимаю (не бейте ногами php-дауна) это можно реализовать с помощью хака. Но это вариант не гибкий и чреватый глюками, т.к. ковыряние в ядре системы не есть гуд.

Думаю, можно пожертвовать частью производительности и реализовать именно мамбот.
Не совсем представляю механизм работы мамбота, но, думается, выловить ID материала и раздела для тех, кто в танке, не сложно. Так же можно найти и заменить URL стандартной ссылки «подробнее» на нужный, если есть привязка к меню.

Чтобы не перегружать сервер, в настройках мамбота завести поля для ограничения поиска и замены по ID разделов (к примеру, новости шерстить вовсе не нужно, можно проверять вводный текст только тех материалов, что относятся к определённым разделам. «Деятельность», к примеру).

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

Ладно, я всё сказал  ^-^
Курю бабмук и жду прихода профессионалов,  которые скажут что «тут всё не правильно!»
 ^-^

Антон Сумин aka effrit
*

smart

  • Администратор
  • 6485
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Во-первых проблему дубликатов решить можно установкой сторонних SEF-компонентов, типа Artio JoomSEF, OpenSEF, а во-вторых проблема несколько глубже, чем вам кажется. Разные ссылки получаются именно из-за того, что параметр Itemid соответствует именно АКТИВНОМУ пункту меню. Если на главной странице находится  10 новостей из разных разделов, то при переходе на эти новости с главной страницы, АКТИВНЫЙ пункт меню не изменяется, так как по меню никто не кликал, и соотвественно у этих ссылок, будет Itemid той страницы, откуда пришли. И никак не пункта меню раздела или категории этой новости.

Такая логика работы зашита разработчиками в код Joomla, и надо сказать довольно грубо зашита. При разработке Joostina, мы с boston'ом и еще несколькми разработчиками не один час провели в обсуждениях того, каким образом можно обойти эту логику, и вообще избавиться от этого, как мне кажется, лишнего параметра. Но пока, надеюсь что именно пока, красивого и корректного решения мы не нашли. Т.е. в принципе-то варианты есть, но есть и большие сомнения по поводу совместимости всего этого с остальными расширениями Joomla.

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

Плюс, в Joomla 1.0.13 и выше, есть 2 режима работы с параметром Itemid, один по новой логике, второй по старой (до 1.0.12), кто-то более привычен к старому, кому-то уже понравился и полюбился новый режим работы.
*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com
Про логику работы itemId я как раз понял.
И она мне не понравилась (что "11 и ниже", что "12 и выше" не дают мне желаемого результата).
Т.е. я не говорю, что её (логики) нет, но она идёт в разрез с моими (и, видимо, не только моими) представлениями о навигации и связанном содержании.
Как раз ситуации с переходом через главную страницу БЕЗ смены активного пункта меню я и хочу избежать :).
И именно поэтому мне кажется более логичными не односторонние связи меню-контент, а двусторонние, те + "контент-меню" (отсюда и желание мамботом определять, к какому меню соотвествует показанный вводный текст и делать ссылку исходя из этого).
Собственно, именно на это и был направлен сабж :)

Спасибо за быстрый ответ :)
Возможно, ещё кто-нибудь захочет высказаться по теме.

Пока пойду копать сторонние SEFы, возможно, ответ действительно там :)



*

smart

  • Администратор
  • 6485
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
И именно поэтому мне кажется более логичными не односторонние связи меню-контент, а двусторонние, те + "контент-меню" (отсюда и желание мамботом определять, к какому меню соотвествует показанный вводный текст и делать ссылку исходя из этого).
ну достаточно тогда просто переписать функцию определения Itemid, в более старых версиях, там делалось слишком много запросов к БД, чтобы найти, соотвествующий пункт меню, в последних версиях это дело упростили...

Проблема-то в том, что эта логика касается же не только компонента материалов, но и остальных компонентов на сайте. И исправление этой логики только для com_content не сильно поможет в остальных случаях. И самое главное, на одну и ту же категорию, может быть 2,3 и более ссылок, из разных меню... И какой из 3-х возможных Itemid вы предлагаете выбирать?
*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com

Проблема-то в том, что эта логика касается же не только компонента материалов, но и остальных компонентов на сайте. И исправление этой логики только для com_content не сильно поможет в остальных случаях. И самое главное, на одну и ту же категорию, может быть 2,3 и более ссылок, из разных меню... И какой из 3-х возможных Itemid вы предлагаете выбирать?
Я на сайте делаю стандартное древовидное меню. Меню - 2. "О нас" и "Деятельность". Пересечений из разных меню просто нет. Компоненты тоже-галерея да файловый архив-им вполне хватит "itemid 11 и ниже".
Так что проблема то как раз была упорядочить компонент материалов. Понятно, что это не системное решение, подходящее только для строгих меню, но имеено это и было заявлено в сабже :) остальные категории благополучно работали бы как раньше. Просто, думается, таких не сильно сложных по структуре сайтов очень много, и, возможно, мамбот бы нашел применение.
В общем, попробую Artio, может я про него и думал, когда тему постил :)
Хотя мамбот всё равно изящнее был бы. Не всем нужны отптимизации поисковые да лишние навески на движок.
*

smart

  • Администратор
  • 6485
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Хотя мамбот всё равно изящнее был бы. Не всем нужны отптимизации поисковые да лишние навески на движок.
представьте себе ситуацию, на странице 10 материалов, разных, и допустим по бокам еще 10 ссылок на материалы из модулей, итого 20 ссылок. Для каждой из них нужно определить Itemid по какому-то сложном алгоритму, каждый раз необходимо сделать запрос к базе, к чему приходим? К увеличению количества запросов к БД... и эта работа будет производиться постоянно, при каждом открытии страницы...

Одно из возможных решений, было бы в хранении для каждого из материалов ссылки на него. Т.е. чтобы при создании/редактировании материала отображалось, куда он будет привязан, и пользователь мог выбрать. А при необходимости получения ссылки на материал, в первую очередь смотрелось это значение, и только если оно не указано, формировалось по какому-либо алгоритму.
*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com

Одно из возможных решений, было бы в хранении для каждого из материалов ссылки на него. Т.е. чтобы при создании/редактировании материала отображалось, куда он будет привязан, и пользователь мог выбрать. А при необходимости получения ссылки на материал, в первую очередь смотрелось это значение, и только если оно не указано, формировалось по какому-либо алгоритму.
Кхм, в админке, по-моему, именно так и реализовано. Вкладка "Связь с меню".
Т.е. как раз по логике то и получается что материал может быть УЖЕ привязан, и связка хранится где-то. Но задействуется только линейно, от меню к материалу, но не наоборот.
*

smart

  • Администратор
  • 6485
  • 1318 / 15
  • Хочешь сделать хорошо — сделай!
Кхм, в админке, по-моему, именно так и реализовано. Вкладка "Связь с меню".
эта функция создает в меню пункт, ссылающийся на этот материал... физически создает пункт... при добавлении каждой новости генерировать пункт меню, мне кажется это несколько не разумно...

Но задействуется только линейно, от меню к материалу, но не наоборот.
это можно реализовать, но вопрос в нагрузке на базу...
*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com
эта функция создает в меню пункт, ссылающийся на этот материал... физически создает пункт... при добавлении каждой новости генерировать пункт меню, мне кажется это несколько не разумно...
это можно реализовать, но вопрос в нагрузке на базу...
ээээ нет, внимательно прочтите текст оригинального  сабжа!
речь то как раз идёт ТОЛЬКО о приязанных к меню материалах, а не не о бесхозных новостях, которым, понятно, пункты меню не нужны. Именно поэтому я и говорил о выборочной работе бота только по выбранным пользователям категориям, относящися к закреплённым материалам.
Новости же спокойно работают по стандартному алгоритму, подсвечивая родительский пункт "Новости" и никого не смущая, а вот ПРИВЯЗАННЫЕ к меню материалы и ДОЛЖНЫ работать в соотвествии со своей ПРИВЯЗКОЙ. Т.е. при вызове себя из любого места подсвечивать привязанный к ним пункт меню. Вот эта логика мне кажется правильной. Иначе материал в одном случае ведёт себя как ссылка с пункта меню, а в другом-как бесхозная же новость. Что и смущает, ведь именно к материалам хочется привязать набор модулей и контектную инфу.


*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com
Кажется, нашёл решение проблемы.
Всё довольно просто-отказываемся от использования в качестве промежуточных страниц/меню от статичного содержимого /и от стандартного блога (хотя для новостей можно оставить)/.
Вместо этого пользуем супер-пупер-модуль Display News by BK
Была маленькая проблема с отображением картинок, но вправил руками (к счастью, всего лишь однобуквенная опечатка в коде :) ).
Настоятельно рекоммендую всем попробовать эту штуку. Я в неё практически влюблён-главную страницу можно перекроить в два счёта по своему вкусу+модуль может резать интро (и даже основной текст), что даёт ещё одну степень свободы в битве за дизайн и единообразие блоков.
Ну и ссылки ведут куда надо, в итоге. Т.е. "подробнее" (можно менять надпись на любую другую) теперь ведёт на конкретную страницу, привязанную к меню. Что и требовалось показать :).
*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com
ссылка на скачку модуля "display news by BK": _http://joomlacode.org/gf/project/display_news/frs/
если не работают картинки в версии для 1.х.х, то берём отсюда:


[вложение удалено Администратором]
*

SolopoV

  • Давно я тут
  • 547
  • 15 / 0
  • зеленею...
Во-первых проблему дубликатов решить можно установкой сторонних SEF-компонентов, типа Artio JoomSEF

Ни одна из версий Artio JoomSEF данную проблему не решает. Разные настройки пробовали. В итоге  GSiteClawler нашёл от 3 до 6 адресов страниц одного содержимого.
*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com
эээ, друг, не так всё просто.
GSiteClawler - не знаю что такое, а с поисковиками можно разобраться.

ставим Артио, формируем массив html-страниц (автоматически, или причёсываем что слишком длинно/коряво), а всё что с index.php и index2.php гасится в robot.txt

в результате тот же яндекс страницы с дублями видит, но записывает их в ошибки/предупреждения блокирована файлом robot.txt""
*

SolopoV

  • Давно я тут
  • 547
  • 15 / 0
  • зеленею...
эээ, друг, не так всё просто.
GSiteClawler - не знаю что такое, а с поисковиками можно разобраться.

ставим Артио, формируем массив html-страниц (автоматически, или причёсываем что слишком длинно/коряво), а всё что с index.php и index2.php гасится в robot.txt

в результате тот же яндекс страницы с дублями видит, но записывает их в ошибки/предупреждения блокирована файлом robot.txt""


GSiteClawler - http://www.google.com/search?hl=ru&lr=&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=Gsitecrawler&spell=1

а как быть со сторонними компонентами, которые не прожёвывает Artio?
*

effrit

  • Легенда
  • 9899
  • 1095 / 13
  • effrit.com
ну я не бог весть какой спец по джумле- сделал ровно 1 сайт пока что :)
что знал сам- сказал.
дальше уже начинаются индивидуальные "плавания".
кстати, помимо артио есть и другие компоненты. наверно, имеет смысл пробить на счёт поддержки вашего набора компонентов по отношению к другим оптимизаторам.
принцип то всё равно один и тот же.
*

SolopoV

  • Давно я тут
  • 547
  • 15 / 0
  • зеленею...
ну я не бог весть какой спец по джумле- сделал ровно 1 сайт пока что :)

Ну в целом, данную траблу не решить на данном движке насколько я понял.
Я тут пивка взял, и попробую рассказать о таблетках.. точнее, о том что не нужно делать на Joomla или Joostina или... что там у кого получается свое.

Вот. Начнём.

Делаем одно меню, причем каждый пункт с уникальными Itemid. Для этого подойдёт mainmenu... вдаваться дальше не буду..
Для сторонних компонентов уникальных нет.

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

Что то Питером запахло.... Будто я Египтянин... и царапет небо когтями....
Это отступление...

Если кому то надо ещё меню, копируем тупо адреса и первого меню и вставляем урлами в последующие меню.

Тут (в форуме) много говорят о сторонних компонентах SEF и о встроенном.
Поверьте, если Вы их задействуете - месяц, а то и два - насмарку.
Не стоит напрягать ни поисковики, ни базу. Пусть адреса формируются как есть.

Потом, очень тяжело сделать реальную карту сайта и отдать её поисковикам.

Иногда приходится и ручками.

Как делал я: запустил GSiteClawler, отдаю ему все с учетом robots.txt
потом выкидываю (проверяя адреса "регистрация", "забыли пароль" и т.п.) ненужные страницы. Не знаю как на последних версиях движков, но раньше, выдавался & (амперсанд) в адресах, меняем и его на &

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

Соответственно, если они "просочились" смотрим откуда и выкидываем.

Юзаем все страницы по карте (тут хитрость, браузер возьмет только &, &amp- не возьмет. Нужно две карты).

Прогнали сайт локально, выкинули дубли. Выложили сайт, отдали карту с &amp поисковикам.

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

Даем джазу Гуглу и Яндекс. Приходим через неделю и видим:

Google проидексировал карту и прокричал пару ошибок, правим
приходим через 2 недели - Яндекса -0 нет.
Является на третью.
В конце месяца видим ошибки. Правим.
Вот и все.

К чему этот пассаж?
Да блин, кривое зеркало :) наверное.
Хотя.... вывод 11 сайтов за 2 года на первые места ("первые" - читать как: 1, 2, 3) - сделан.
И в послесловие: не ставьте модули и компоненты, которые вы не знаете и не проверены временем, либо отслеживайте, что они выдают поисковым системам.

Что помогает определить правильность вывода заголовков и названий: тут вообще истерика иногда получается:

попробуйте загнать пару страниц по типу http://ваш_адрес.*** и http://ваш_адрес.***/index.php вот сюда: http://www.seocentro.com/tools/search-engines/metatag-analyzer.html

абсолютная разница.

Я думаю, что разговор продолжится..
Чтобы оставить сообщение,
Вам необходимо Войти или Зарегистрироваться
 

Как прописать "canonical" для всех страниц с поддомена на домен?

Автор misteri27

Ответов: 11
Просмотров: 3203
Последний ответ 12.09.2020, 10:41:07
от webzepa
Как подменить адреса страниц, чтобы они в поиске по другому запросу вылетали?

Автор WOOHer

Ответов: 19
Просмотров: 950
Последний ответ 31.07.2020, 23:13:17
от kiev
Дубли страниц: сравнение плагинов “sef Wizard for Joomla” и “JL No Doubles”

Автор shop-user

Ответов: 2
Просмотров: 805
Последний ответ 08.01.2019, 14:36:18
от zikkuratvk
Решение проблемы с дублями страниц в Joomla 1.5

Автор TwistedAndy

Ответов: 360
Просмотров: 132875
Последний ответ 11.05.2017, 19:24:24
от sherza
Переадресация SEF со страниц, начинающихся с цифр

Автор maximus07

Ответов: 2
Просмотров: 866
Последний ответ 14.01.2017, 21:10:32
от Paha_web