Если же речь про сравнение Fenom в БД и файлах, то тут явно дело даже не в удобстве разработчика, а в возможности использования системы контроля версий.
Она заброшен уже несколько лет как, не нужно его использовать.
16 сентября 2017, 02:16
+2
Можно примерно так:
Если не понятно — это куча собственных файловых сниппетов, на все случаи жизни. MODX же у нас фреймворк, не так ли?
15 сентября 2017, 10:43
+2
Поправил, спасибо!
12 сентября 2017, 13:10
0
Прошу прощения за свою манеру общения — никак не могу побороть.
Просто обратите внимание, что:
— нигде нет информации о том, что ключ как-то может влиять или влияет на работу дополнения.
— в магазине используются ключи, которые что-то, по определению открывают, дают доступ. В нашем случае — это доступ к магазину
— слово «лицензия» не употребляется нигде, значит мы никак не ограничиваем работу «нелицензионных» дополнений.
Теперь, когда вы во всё разобрались, напишите пожалуйста, как мне лучше исправить наш раздел помощи. Вот прям дайте готовый текст — я его вставлю и всем всё будет понятно и таких вопросов больше не возникнет.
12 сентября 2017, 12:48
+1
Ключ даёт доступ к магазину и возможности скачивать и обновлять из него дополнения.
Привязка ключа к домену делается для того, чтобы скачивать и обновлять дополнения вы могли только с этого домена. Исключение — поддомены dev, для разработки.
Соответственно, если вам нужно скачивать и обновлять дополнения на рабочем домене — нужно ли привязывать к нему ключ? Естественно.
Домашняя работа: подумайте, почему у нас используются ключи для доступа к магазину, а не продажа лицензий на дополнения?
P.S. Кстати говоря, а напишите как лучше изменить формулировку в нашем help, чтобы было понятнее? У меня уже действительно профдеформация — мне всё кажется очевидным, потому что я это сделал.
Набросайте более доступный текст по логике работы привязки ключей и мы добавим его в help.
12 сентября 2017, 12:34
+1
1. Сделать dev домен.
2. Они и будут работать, но без обновлений и техподдержки.
3. Опять двадцать-пять. Ключ даёт доступ к магазину, на работу уже установленных дополнений он никак не влияет.
Откуда вы вообще взяли информацию, что привязка ключа как-то может повлиять на работоспособность дополнения? Вы это сами выдумали, а теперь «не понимаете».
Также мы поддерживаем работу дополнений на поддомене dev. Сбрасывать ключ для такого домена не нужно — дополнения просто работают сразу на обоих доменах: site.ru и dev.site.ru.
Это должно решить все вопросы разом.
12 сентября 2017, 11:40
2
+4
{var $ids = $_modx->getParentIds($_modx->resource.id)}
{if '11' in list $ids}
Фильтры для пылесосов
{else}
Фильтры для вытяжек
{/if}
Код не проверял, но логика примерно такая: получить массив с родителями текущего ресурса и проверить, если ли среди них нужный.
10 сентября 2017, 23:47
+4
Срочно пришлось отключить взломанный аккаунт.
Берегите себя, не пейте так много в день трезвости.
10 сентября 2017, 12:13
+2
Сейчас каждый может скопировать url картинки, убрать из пути small и получить доступ к оригиналу фотографии.
Только если хозяин сайта не запретит открывать эти файлы. Есть такая штука, которая отвечает на запросы пользователей, она называется «веб-сервер» — и её можно настраивать.
Я даже где-то здесь уже писал такие правила для Nginx, нужно только поискать.
04 сентября 2017, 11:10
+5
Тут бы не помешало отметить, через какой сниппет выводится этот ТВ.
pdoResources должен сам подставлять полный путь к ТВ, если включен &prepareTVs=`1` (а он включен по умолчанию).
А прислать он может что угодно, включая длиннющую строку со слепой SQL инъекцией.
При этом, наш сайт находится на самом слабом сервере хостинга — h1, и проблем никаких нет.
Наверное, не просто так эта настройка выключена по умолчанию.
Продолжай оскорблять пользователей сообщества и пройдёшь путь комментатора до конца.
Если же речь про сравнение Fenom в БД и файлах, то тут явно дело даже не в удобстве разработчика, а в возможности использования системы контроля версий.
Ну и можно попробовать еще прогнать твои тесты с кэшированием файлов.
А документация по miniShop2 была вся написана с нуля при разработке версии 2.4
Если не понятно — это куча собственных файловых сниппетов, на все случаи жизни. MODX же у нас фреймворк, не так ли?
Просто обратите внимание, что:
— нигде нет информации о том, что ключ как-то может влиять или влияет на работу дополнения.
— в магазине используются ключи, которые что-то, по определению открывают, дают доступ. В нашем случае — это доступ к магазину
— слово «лицензия» не употребляется нигде, значит мы никак не ограничиваем работу «нелицензионных» дополнений.
Теперь, когда вы во всё разобрались, напишите пожалуйста, как мне лучше исправить наш раздел помощи. Вот прям дайте готовый текст — я его вставлю и всем всё будет понятно и таких вопросов больше не возникнет.
Привязка ключа к домену делается для того, чтобы скачивать и обновлять дополнения вы могли только с этого домена. Исключение — поддомены dev, для разработки.
Соответственно, если вам нужно скачивать и обновлять дополнения на рабочем домене — нужно ли привязывать к нему ключ? Естественно.
Домашняя работа: подумайте, почему у нас используются ключи для доступа к магазину, а не продажа лицензий на дополнения?
P.S. Кстати говоря, а напишите как лучше изменить формулировку в нашем help, чтобы было понятнее? У меня уже действительно профдеформация — мне всё кажется очевидным, потому что я это сделал.
Набросайте более доступный текст по логике работы привязки ключей и мы добавим его в help.
2. Они и будут работать, но без обновлений и техподдержки.
3. Опять двадцать-пять. Ключ даёт доступ к магазину, на работу уже установленных дополнений он никак не влияет.
Откуда вы вообще взяли информацию, что привязка ключа как-то может повлиять на работоспособность дополнения? Вы это сами выдумали, а теперь «не понимаете».
Это должно решить все вопросы разом.
Берегите себя, не пейте так много в день трезвости.
Я даже где-то здесь уже писал такие правила для Nginx, нужно только поискать.
pdoResources должен сам подставлять полный путь к ТВ, если включен &prepareTVs=`1` (а он включен по умолчанию).