Іван Клімчук

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

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

Если сроки не сильно жмут и при этом важно качество, напишите мне. Контакты есть в профиле.

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

Нашел еще баг :) Системная настройка notification_mode, описано, что значения могут быть 1,2,3 и 4, но в админке тип boolean где только Да и Нет.

При обновлении такая беда вылезла:

Консоль запущена...
Пробуем установить пакет с подписью: onebooking-3.0.0-pl
Пакет найден... сейчас идёт подготовка к его установке.
xPDOZip: Error opening archive at /home/proweeke/public_html/onebook/core/packages/onebooking-3.0.0-pl.transport.zip
PHP warning: ZipArchive::extractTo() [ziparchive.extractto]: Invalid or unitialized Zip object
PHP warning: ZipArchive::close() [ziparchive.close]: Invalid or unitialized Zip object
Could not unpack package /home/proweeke/public_html/onebook/core/packages/onebooking-3.0.0-pl.transport.zip to /home/proweeke/public_html/onebook/core/packages/. SIG: onebooking-3.0.0-pl
Невозможно установить пакет с подписью: onebooking-3.0.0-pl

На Skype можно ссылку навесить для удобства

skype:nickname?add

или

skype:nickname?chat

Ответ тут :) github.com/modxcms/revolution/blob/092e698b81f65c11eab263d3a74c44ebd2521a2d/core/model/modx/modresponse.class.php#L261

Если в деталях, то он шлет редиректы только на коды 30x.

:-D О чем и писал в заметке. Для этого и делаю цикл, чтобы таких вопросов не было. Если по документации пока не понятно, то нужно ждать статей. В двух словах не получится рассказать, уже пробовал.

Вроде все правильно по коду, но есть подозрение, что выборка из БД отдает поле myrating как строку, а значит может работать не совсем правильно. Нужно приводить к типу integer в функции сравнения массива (cmp) перед сравнением.

А что именно не получается? Ошибка или просто не сортирует?

компонент BannerY. Только вместо изображений вставляется код от adsense

Я тоже готов поставить минус. Но с утра настроение еще не испортилось.
Хватит искать готового. Скоро вообще у всех мозги поотсыхают, никто делать ничего не хочет. Tickets из коробки (ничего там особо и настраивать не нужно) работает как новости +рубрики + комменты (на этом сайте примеры вокруг). Если вам лень почитать документацию и разобраться, как это работает, то это ваши проблемы, имхо. Волшебной кнопки «Сделать п***то» не бывает.

Человек только пришел в MODX, не ругайся. Я привел его сюда с toster.ru, будем учить :)

Tickets — это уже и есть готовое решение.

Перепробовал уже много вариантов. Пока что Gitify максимально приблизился к тому, что хотелось бы, но все равно не то. modx.today через него полностью деплоится, для примера. Есть исходники github.com/modmore/MODX.today

В остальном деплой MODX — БОЛЬ. Код в базе сподвигает на велосипеды и костыли. Я люблю MODX, но эта мелочь многое портит (ложка дегтя так сказать).

В идеале видится схема такая.
Рабочие копии (у программистов) разворачиваются через Gitify. Код туда-сюда гоняется легко, есть в последних версиях разрешение конфликтов ID (когда 2 разработчика создали разные чанки с одним id например) и умное удаление «мусора» (удалил файл и следом удалилась запись из БД на сайте). На stage тоже код попадает через gitify. Со stage код должен упаковываться в транспортный пакет и устанавливаться на продакшен. Тут поможет Teleport. Но в таком случае доступ на продакшен для всех через админку закрыт. Изменения должны вноситься заказчико на stage, а затем попадать на продакшен. Такой подход касательно Teleport одобрил Jason Coward, когда в общем чате в Slack это обсуждалось (Teleport его рук творение).
У подхода есть плюсы: продакшен изолирован от вмешательства человека, живет как отдельное приложение (данные, генерируемые пользователями не относятся к разработке и не нужны на dev-машинах, заменяются фикстурами).
И минусы: настраивать такое для рядовых проектов накладно, требует много ресурсов для поддержки, в свое очередь не выгодно для коротких или малых проектов.
Но если делается совсем большой проект, то стоит задуматься, а нужен ли MODX? Каким бы фанатом и евангелистом я не был, реальность сурова: MODX дорог в эксплуатации на очень крупных проектах, хотя и позволяет экономить на старте.

Документация по getOption rtfm.modx.com/xpdo/2.x/class-reference/xpdoobject/configuration-accessors/getoption

1 'outerTpl' — ключ параметра
2 $outerTpl — тут не правильно, второй параметр — это источник, откуда брать значение. Нужно $scriptProperties. Так как у сниппета могут быть заданы свои параметры (на вкладке с параметрами), то там может быть и задано значение по умолчанию. В таком случае не нужно будет писать третий параметр.
3 — '

[[+wrapper]]

' — значение по умолчанию. Если во 2 параметре значения с таким ключом (1) нет, то взять это значение.

$param = $modx->getOption('paramName', $scriptProperties, 'default_param_value');

setPlaceholder устанавливает значение для все страницы сразу, в итоге погоду для двух городов вы уже не выведете, так как последний вызов будет затирать предыдущие поля. Ну и в чанк ничего не передавалось, т.е. по сути был лишний бесполезный вызов. Метод использовался не правильно. Данный массив передается в метод $modx->getChunk($tpl, $data) — первый параметр имя чанка, второй — ассоциативный массив с данными, где ключ массива — плейсхолдер в чанке, значение — значение :).
В данном случае данные о температур приходят в виде числа, если отрицательное, то с минусов, если положительное, без плюса. Нулю плюс приписывать не нужно, поэтому для числе меньше либо равно 0 — оставляем как есть, если больше 0, ставим плюс. Не принципиально, но мне так легче в коде читать.

Не стоит ли проверять доступность только если нет кэша?

Да, стоит внести в условие. Исправил.

Вот, переписал.
gist.github.com/Alroniks/e6ba41e16dbaeb780cdc
В вашем сниппете много ошибок. Изучите мой код (он тоже не совершенен), если будет совсем непонятно, могу вам в частном порядке рассказать, что не так.

В обновленном варианте тоже не идеально, так как при каждом запросе будет запрашиваться сайт погоды, чтобы может быть медленно. Такие вещи как правило или запрашивают скриптом по расписанию (cron) или кешируют результат на определенное время. Часа хватит. Можно класть в кеш самого MODX через

$modx->cacheManager->set('testdata', 'My cached data.', 3600);

Механика проста:
1. Проверяем, если ли значение к кеше.
2. Если нет, делаем запрос на сервер и сохраняем полученное значение к кеш
3. Выводим значение из кеша