Но мне не ясно, зачем тебе создавать ресурсы, если работодатель заполняет форму? Не лучше ли сохранять эти данные в отдельную таблицу, по которой можно будет организовать поиск?
Если так — то самый простой вариант, это сделать малюсенький компонент при помощи modExtra, а данные в таблицу закидывать через хук FormIt — заодно и валидация будет, и email уведомления о новой записи.
Если же надо прям создавать ресурсы — крайне советую использовать Tickets, ибо он фильтрует разные XSS, теги MODX и прочие угрозы, которые юные хакеры могут засунуть в новый ресурс. Также, он форматирует и типографирует текст, и тебе самому это делать не придётся.
Tickets работает только с авторизованными юзерами, что решается легко и просто при помощи HybridAuth.
Но мне не ясно, зачем тебе создавать ресурсы, если работодатель заполняет форму? Не лучше ли сохранять эти данные в отдельную таблицу, по которой можно будет организовать поиск?
Если так — то самый простой вариант, это сделать малюсенький компонент при помощи modExtra, а данные в таблицу закидывать через хук FormIt — заодно и валидация будет, и email уведомления о новой записи.
Если же надо прям создавать ресурсы — крайне советую использовать Tickets, ибо он фильтрует разные XSS, теги MODX и прочие угрозы, которые юные хакеры могут засунуть в новый ресурс. Также, он форматирует и типографирует текст, и тебе самому это делать не придётся.
Tickets работает только с авторизованными юзерами, что решается легко и просто при помощи HybridAuth.
О проблемах с 20к документами в Рево не слышал. Учитывая, что разработчики говорят о ресурсах как view to data — не обязательно раздувать сайт до такого кол-ва ресурсов. данные можно держать в отдельных таблицах, и выводить на ресурсах своими сниппетами.
Зависит от задачи, в общем. Пример большого сайта — сам modx.com и complex.com — тут чуть подробнее.
Теперь, если что, они сохраняются в #anchor=имяякоря. Если при загрузке есть такое значение в хэше — то оно перекрывает остальные и хэш меняется на якорь.
Пытался подружить это дело с scrollTo.js, чтобы перекручивало на якорь и срабатывали остальные параметры — но глюки не смог одолеть. Поэтому теперь так: реальный якорь важнее остального.
Проверяем — bezumkin.ru/sections/components/516/#anchor=cut/tab=tickets
Подумаю на досуге, как разделить хэш для собственных нужд и настоящие якоря.
Причем тут индексация?
Вообще, это правильное поведение, но вам надо навести красоту. Сделать это просто.
— вызываем вес в чанке вот так:
— и пишем сниппет round:
Проверил на демо сайте.
В версии 1.9.4 вроде всё поправлено.
Ничего не знаешь, но считаешь, что я тебе что-то должен.
Я мог бы просто удалить тему и все твои комментарии. Но я — добрый. Поэтому, предлагаю просто уйти отсюда и больше не приходить.
Предлагаю больше не мучаться и найти нормальный компонент для поиска, а не эту криворукую поделку.
А при индексации тебе надо было указать &limit=`110`. Вообще, вдумчиво почитать документация может быть полезно.
Лично я не знаю более элегантного решения объединить 3 таблицы в одной выборке, чем join.
Кстати, можно немного упростить, выбирая поля псевдонимами:
У меня кончились идеи, видимо — не судьба.
Может, просто адрес неверный указан в системной настройке emailsender?
То есть, это была натуральная дырка.
Сейчас для привязки дополнительных учеток юзер должен авторизоваться на сайте людбым способом. Иначе да, будет 2 юзера.
Тогда нужно провести диагностику сниппетом QuickEmail.
А почта там настроена, Sendmail установлен? Пробовал почту из консоли отправлять?