Павел Гвоздь

У нас есть переменная $data, которую мы можем использовать, как душе угодно:

'defaultBalloonContent' => '{$data | print}',

Она содержит данные карты данного ресурса, а точнее такого типа информацию:

Array(
    parent => (int)
    class => (string)
    list => (string)
)

При помощи Fenom мы можем вытащить любое поле ресурса, относящегося к данному объекту карты.

Если кто-то не догнал, ибо минусуют:
Я не вижу смысла использовать не свой код, когда я могу написать свой, правильнее и изящнее, на мой взгляд. Без лишних сниппетов, которые совершенно ни к чему, даже в решении Александра, ибо можно обойтись Феномом.

Я благодарен Александру за этот пост, было интересно почитать, что требуется людям и как они это решают. Отсюда и было принято решение добавить возможность кастомизации в компонент:

1.1.0-beta (16.11.2018)
==============
- Добавлено событие плагина ymOnLoadObjects с параметрами: array $data, array $objects, array $snippetProperties

В документации уже есть инфа об этом.

Принижать вашей работы и вложенных сил я не собирался, если так кто подумал! Однако и «вспоминать и писать ответ» я ведь тоже не просил. Тем более такую простыню в комментарий, в то время, когда есть возможность отредактировать пост. Для меня, перфекциониста, это, как ночной кошмар. :)

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

А я не использовал ваш код, поэтому эта дикая простыня мне ни к чему)

Более не актуально.

Нужно на карте выводить подпись и балун общие для всех точек

1.1.0-beta (16.11.2018)
==============
- Добавлены параметры defaultIconContent, defaultIconCaption и defaultBalloonContent в сниппет YandexMaps2

и

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

1.1.2-beta (18.11.2018)
==============
- Добавлен новый метод работы с mFilter2, поддерживающий вывод результатов в текстовом виде

Важно! Работает иначе. Как настроить, читайте в доке (отправил PR Василию, думаю скоро примет изменения в документацию).

Ну тогда Tickets + Office (extended поля для различных данных организации/исполнителя). При регистрации добавлять юзера в группу «Исполнитель» или «Работодатель». Не думаю, что что-то ещё понадобится.

Хотя, я бы только Office использовал и без extended полей. А вакансии и отклики хранил бы в своих таблицах. Потому что, если предусматривать масштабируемость, то вариант с Tickets не очень подходит. Слишком много ресурсов в будущем. Скорость работы сайта будет не очень.

Ты бы хоть описал, что требуется тебе на сайте. А то:

Я хочу создать поисковую систему, такую как Яндекс, но не такую как Яндекс, попроще. Ну думаю всем понятно.

Вы все сообщения будете писать на мыло, а через минуту дублировать сюда?

Нет.

условие where перестает работать.

Ещё бы!

'where'=>'{"id:!=":"[[*id]]"}'

Что это за колдунство?) Запишите нормально, по-человечески, массивом!
Вот тоже самое:

'where' => [
    'id:!=' => $_modx->resource['id'],
],

Благодарю! Да, дебажил и забыл раскоментить…
Обновляйтесь до 1.3.0-beta2:

1.3.0-beta2 (05.11.2018)
==============
- Поправлено формирование имени ТВ поля

???

Не знаю, надо дебажить. Опишите, как это воспроизвести.

Можешь отослать PR. Добавлю в следующую версию.

На самом деле стоит благодарить тебя за твои статьи! Если бы не они, я б и не подумал тратить столько времени на этот функционал! Но видя, как людям нравится MIGX, решил, что пора! Так что, Баха красавец! =)

Добавил поддержку MIGX.
modx.pro/components/16719

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

Ну а откуда брать время? Сервера? Если так, то что делать с юзерами, у которых +-5 часов разницы? А если брать время JSом с компа юзера, то что делать с хитрыми юзерами, которые поменяют часовой пояс на компе?

Что значит «конкретны часы»?

При этом никаких задержек при оформлении заказа.

А как же задержки при отсылке писем менеджерам и юзеру о новом заказе?)