Алексей Карташов

Ой, да ладно. Столько говна за деньги продают.
Только вчера слёзно умоляли починить и-магазин на 4м неткате, у которого обнаружился залитый шелл с exploit-db и 3 тысячи страниц сгенерированного поискового спама, вписанные в дизайн сайта, на который шёл траффик и на которых стояло 2 блока google.adwords размером с всю страницу (mfa на 3 тысячи страниц). Т.е. уязвимость известная, на автомате детектируется софтом и эксплуатируется нехорошими личностями, которые на автомате на этом зарабатывают. А обновления системы платные.
А владельцу магазина, который продаёт детские товары, ещё и начали звонить посетители этих левых страниц, желающие купить автозапчасти, стиральные машины и прочие товары, которые были сгенерированы.

но умеют они очень многое здесь и сразу

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

Видел я как на неткате сайты делают. Даже я, казалось бы нуб-нубом, а сходу несколько sql-инъекций нашёл. XSS там вообще на каждом шагу. После этого в код глянул — так вообще ужаснулся.
И так со многими «коробками».

Хоть раз на русскоязычных modx-форумах были подобные темы? Если и были, то оооочень мало. В этом и есть преимущество. Так что тема нужная и стоящая. И своего покупателя всегда найдёт.

p.s. а владелец магазина вчера решил этот самый магазин продавать нафиг, ибо намучались они с ним за 2 года. А уж сколько денег они вложили в его разработку и поддержку за это время — тут уж и вы ужаснётесь.
А там сейчас даже админка не работает. Такие дела.

Лучше miniMaxiShop2 или maxiMiniShop2 =)

upd. И да, по поводу остатков — действительно нужно. Тогда минишоп будет уже не «мини», а действительно конкурентной e-commerce платформой, гибкостью которой не смогут похвастаться очень многие коробочные продукты.

Так что желаю успехов в разработке!

Ну ты хоть покажи — что и как добавил. Я ж не гадалка

rid ты никуда не передаёшь. Сохранил её в переменную, а в аякс-запрос не засунул.

Добавь перед $.ajax(...) вот это:

data = $.extend({}, data, {rid: rid});

Или вот так:

data.rid = rid;

Вась, извини, но вот это:

Бла-бла-бла

— это пиздец какой-то.

Я и расписывал вот это вот всё только для того, чтобы подобных ответов не было. Ан нет. Не ожидал.

Циклические ссылки индексации сайта не мешают и никак на неё не влияют. Это раз.
Индексация сайта зависит от других параметров. Это два.
Индексация сайта влияет на видимость в поиске, но не на позиции по конкретным ключевым фразам. Это три.
Циклические ссылки мешают нормальному распределению статического веса в рамках страницы, на которой она находится. А это основа основ оптимизации сайта как таковой. Это четыре.
Ты сейчас олицетворил подход — «не понимаю, но осуждаю». Это пять.
И да, я вполне осознаю, что помогать мне, после только что написанного, ты будешь гораздо меньше. Если вообще будешь. Это шесть.

Мат.часть здесь. Не смотря на «срок годности» этой статьи, актуальности она не потеряла, ибо это основа основ. Ну и для тех, кто не знает, что это за автор такой, Садовский, вот линк.

Не всегда подход

прямые руки + голова + уникальный контент

даёт нужные результаты.
Ты смотришь с позиции 2х сайтов (modx.pro и bezumkin.ru), которые дефакто являются сообществами, у которых, по большому счёту, нет конкурентов.
Поэтому modx.pro (а до этого bezumkin.ru)

стал самым посещаемым сообществом по MODX в СНГ.

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

прямые руки + голова + уникальный контент

, то всё становится гораздо, гораздо сложнее.
И это не ситуация в вакууме, а вполне себе рабочая обстановка для опытного оптимизатора.

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

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

Т.е. смысл в том, что у поисковых систем есть сотни параметров, по которым они оценивают сайты (думаю все это знают).
И когда твой сайт по, допустим, 25 параметрам, обходит конкурентов на голову, то этого достаточно. Смысла напрягаться действительно нет.
А если конкуренты по 65 параметрам выше тебя на голову, то тут уже надо работать и над этими 65, чтобы их догнать, и ещё над десятком, чтобы их обогнать.
Всё это утрировано, конечно, но от сути не далеко.
Т.е. тяжелую артиллерию нужно включать тогда, когда она действительно нужна. Нет смысла стрелять из пушки по воробьям.

Просто люди подменяют понятия, по незнанию. Люди думают, что seo — это накрутка и это нечестно.
Но seo бывает разным — бывает накрутка (закупка ссылок, сетки сателлитов), а бывают вполне себе честные методы, которые (внимание!) являются рекомендациями самих поисковиков — гугла и яндекса. И вот это уже лично я называю не seo, а оптимизацией. И это не шаманство, вычитанное на блогах 5летней давности. Здесь и рекомендации самих поисковиков, и математические обоснования и формулы, и эксперименты, и личный опыт. И это исключительно работа над сайтом и его структурой, которая приносит вполне ощутимые плоды.

Меня всегда умиляли люди, которые говорят фразы типа «seo головного мозга». Понятное дело, что человек совершенно не разбирается в вопросе. Я вот финансовые рынки не знаю (хотя очень хочу), но это же не значит, что на профильных и смежных форумах в обсуждениях надо писать «аналитик головного мозга», правильно?
Те, кто говорит фразы «seo головного мозга», — статистически просто работяги (как сейчас модно говорить — «слесари от IT»). А те, кто воспринимает seo как инструмент маркетинга, — зарабатывают деньги, а часто и не малые. Вот и вся разница.

p.s. прошу простить, если задел чьи-то чувства. Цель моя проста — чтобы люди смотрели на вещи объективно. Вот и всё.

Я не про варианты решения, я про идеологию подхода — и вообще зачем всё это нужно.
Верным вариантом у вас является №3. Это единственно верное решение.

Ох, вот долго думал — вступать в дискуссию и разубедить ли мне каждого из присутствующих, что тема имеет место быть. В т.ч., что rel=«nofollow» — это хрень на постном масле.
Только вот автором топика она подана не под тем соусом. Т.е. обосновал он всё это некорректно.
Есть 2 обоснования данной темы: математическое и «юзабилистическое».

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

p.s. Вась, твой пример с modx.pro в данном случае совершенно не корректен :-)

Немного неверно в конце написал, не проснулся ещё)
Читать так:

ибо отсчёт идёт относительно папки, в которой находится текущий документ либо от урла, который прописан в теге

<base href="..." />

, если такой тег существует.

:-)

Здесь правила такие же, как и при написании обычных ссылок:
1. Если хочется писать домен в урле, то начинать надо с http(s)://
2. Если урл начинается со слэша, то это абсолютный, а не относительный урл, ибо отсчёт идёт от корня сайта.
3. Если урл без первичного слэша, то это относительный урл, ибо отсчёт идёт относительно папки, в которой находится текущий документ. В этом случае в head'е д.б. правильно настроенный тэг

<base href="..." />

Хм, что-то мне кажется, что коллизии очень даже возможны, ибо есть вероятность появления коллизий при полной md5-строке, а уж при обрезанной и подавно.
Этот момент как-то обрабатывается? (я код не смотрел)

Если нет, то имеет смысл добавить проверку при генерации — существует ли такой идентификатор у другого документа и, если существует, перехешировать, добавив какой-то дополнительный параметр, уникальный для этого ресурса.
И так в цикле, пока не получим уникальный сокращённый идентификатор.
Может быть ещё имеет смысл хранить в базе те поля, которые использовались для генерации короткого урла, в том же порядке, чтобы потом иметь возможность восстановить этот код, а то мало ли.

Раньше, чтобы засунуть результат сниппета в плейсхолдер, без вывода результатов в месте вызова сниппета, приходилось писать вот так:

[[!snippet:toPlaceholder=`placeholder`:notempty=``]]
<div class="some-html">...</div>
[[+placeholder]]
<div class="some-html">...</div>
[[+placeholder]]

, т.е. надо было добавлять :notempty=``. Результат:

<!-- здесь выведено ничего не будет -->
<div class="some-html">...</div>
result
<div class="some-html">...</div>
result

Такое иногда бывает нужно. Так что на версиях 2.2.* имейте в виду такой способ :-)

А по теме — Илья, спасибо! Буду знать на будущее — когда всё-таки решусь на обновление)
Ибо пока 2.2.15 стабильна, смысла переходить на 2.3 мало — постоянно появляются новые топики, что где-то что-то отваливается и работает не так, как задумано.

Не за что!
Тут как бы и гуглить нечего, на самом деле. Потому что здесь нужны элементарные знания js. Были бы такие знания — не было бы этой ошибки :-)

Конечно нормально.
Я тут долго расписывал суть того как работает javascript и почему отваливались слайдеры. Но да пошло оно это нафиг. Времени нет. При желании сам загуглишь (чего настоятельно советую сделать).

Чтобы без особой крови избавиться от текущей ошибки, в самом конце файла /assets/templates/realia/content/HTML/assets/js/realia.js вот эти строки:

function InitMap() {
    if ($('#map').length !== 0) {
	    google.maps.event.addDomListener(window, 'load', LoadMap);
    }

    if ($('#property-map').length !== 0) {
        google.maps.event.addDomListener(window, 'load', LoadMapProperty);
    }
}

Замени вот этими:

function InitMap() {
    if (typeof window.google === 'undefined') return false;
    if ($('#map').length !== 0) {
	    google.maps.event.addDomListener(window, 'load', LoadMap);
    }

    if ($('#property-map').length !== 0) {
        google.maps.event.addDomListener(window, 'load', LoadMapProperty);
    }
}

И ошибок не будет и остальное ничего не отвалится.

Я знаю что тебе поможет!
Хотя нет, бред…
Или поможет?
Ну ладно, не буду томить.

Чтобы решить твою проблему, нужен… код! Да-да, он самый! Который плагин. Прямо здесь. Прямо обрамлённый тэгом code. Вероятность решения проблемы как минимум увеличится! :-)

p.s. сорри за стиль, но привести код — это первое что нужно сделать, чтобы тебе попытались помочь. Это же очевидно.

Сайты baltgaz.ru и baltgaz.ru/shop/ хоть и разные, но домены одинаковые и используют одно имя для сессионной куки — PHPSESSIONID. Не знаю влияет ли это, но я бы на одном из сайтов указал другое имя. Имя можно указать в настройке MODX session_name

Кстати, есть ненулевая вероятность, что должно помочь. Хороший совет!

Мой совет — вынести магазин на поддомен shop.sitename.ru
Помню тоже были проблемы с сайтом внутри сайта, связанные с сессиями. Деталей сейчас не помню. Гуглил и разбирался долго, но единственно верным решением был перенос на поддомен.
Когда сайт — это папка внутри другого сайта, то это проблема. Всегда найдётся юзер, у которого куки для папок будут не правильно работать.

А если основной сайт на revo, то просто в нём и сделать магазин.

Понимаю, что проблема историческая, либо в упёртости заказчика, но реально — лучше новый поддомен или доработка основного сайта.

Ваша задача — убедить в этом заказчика)

Спасибо за совет!
Как всегда :-)

На самом деле сделать такое — дело-то не хитрое.

Здесь надо решить всего 2 задачи:
1. По какой логике «вытаскивать» нужные для перелинковки слова из контента ресурса?
Есть несколько нюансов. Но единственное решение, которое позволит линковать нужные словосочетания с учётом падежей — это регулярки для каждого из словосочетаний.
Т.е. словарь терминов — это какой-то набор ресурсов, либо просто строчки в базе данных (тогда нужен отдельный интерфейс под это дело).
Каждый «термин» создаётся вручную. И для каждого такого термина нужно написать свою регулярку.
К примеру, термин — «Конституционный суд». Регулярка — "/\bконституцион.+?\b суд.*?\b/i".
Другого варианта, чтобы выдирать термины из текста с учётом падежей — просто нет. Можно в интерфейсе заложить возможность прикрепления нескольких регулярок, для нахождения вариаций термина в тексте.
Как понимаете — это совсем не userfriendly. Уж не знаю каков уровень владения языками программирования и регулярками в том числе у вашей жены, но что-то мне подсказывает, что сама она с такой задачей справиться не сможет.

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

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

<a href="/qweqwe"><a href="/qweqwe"><a href="/qweqwe">Это наш термин</a></a></a>

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

Ну а в целом — вопрос решаемый. Если всё-таки запилите — дайте знать, очень полезный продукт будет (как seo-шник говорю :-)).

А права доступа перезагружал?
Не знаю где это находится в 2.3.*, а в 2.2.*:

"Безопасность" -> "Перезагрузить права доступа".

Ибо после любого изменения политик доступа, чтобы они вступили в силу, нужно эти права перезагружать.
Если права тестируются в контексте web (с фронта), то лучше вообще открыть сам сайт в режиме «Инкогнито» браузера. Ибо, если юзер залогинен в админке, не залогинен на фронте и у него есть sudo, то с фронтэнда у него тоже будет sudo. А если, будучи залогиненным в админке, залогиниться и на фронтэнде (через HybridAuth или Login), то права уже будут применяться к залогиненному юзеру, а не как к админу с sudo. Эх, надеюсь более-менее понятно объясниил)

В общем главные правила при настройке прав:
1. Перезагружать права доступа на каждое изменение этих самых прав.
2. Тестировать права в режиме «Инкогнито». Либо через другой браузер (чтобы сессии и куки не «смешивались»).
3. Если что-то должно работать, но после перезагрузки прав не работает — разлогиниться, почистить куки и залогиниться заново.

Разбираться с твоей проблемой по скриншотам действительно сложно. Поэтому создавай тестовый сайт (http://test.modx.com, благо поднять тестовый сайт и сделать первичную настройку — дело 5 минут), там всё настраивай и тестируй, а потом на своём сайте воспроизводи «слово в слово».

Политики (в мануалах это называется ACL) действительно сложная и непонятная штука, когда берёшься за неё в первый раз. То, что ты разбираешься с ними всего один день — это ещё нормально. Многие (и я в том числе) вообще в них далеко не с первого раза въезжают (я до сих пор не до самого конца понимаю суть, чисто на интуиции настраиваю).
Так что не отчаивайся! Это нормальный процесс =)
Просто пробуй, экспериментируй, но матчасть всё-таки изучи) Методом тыка реально сложно.
И ещё раз повторю, главное — не отчаиваться! Я тоже много волос на себе вырвал, пока во всё это въезжал)