3) Ресурсы не «активизируются» по дате и для этого поэтому нет событий. Все гораздо проще, одно из условий запроса к базе на получение ресурсов — это то, что дата и время на момент запроса больше, чем указанная для документа.
Мда, в общем дерзай. На последок только:
1) Используй JSON и нет проблем. В него кстати декодируется любой массив при сохранении в поле properties в таблице users.
2) Используй ->toArray() и нет проблем
3) if($resource->get('published')) { действия не для черновика }
Про отложенную публикацию забудь, тк нужен cron
4) Код уже написал, чтобы TV вытащить. Для картинок из media source вытащить base_url не сложно.
Хотя, наврал в последнем пункте немного. Нужно проверку типа тв на картинки и ссылки сделать. Ну и соответсвенно к ним добавить base_url источника и ссылку на сам сайт, если её в адресе нет.
1) в смысле в users сохранять бред? Ничего, что существует вероятность того, что в некоторых соц. сетях могут требоваться логин и пароль от аккаунта и если ложить в глоб. настройки, то остальные имеющие доступ к админке их увидят? Далее существует фишка публиковать в группы от чьего-либо имени. Как несколько авторов разделить?
3) Отложенного постинга говоришь? Разве под это дело event нет? Реализовать вообще тогда пара минут.
4) чего со временем должно быть, чтобы 4 строки не успеть написать?
Можно все, что угодно, но для случаев простых, т.к. иначе самому придется писать шаблоны для другого количества колонок, чем по умолчанию в нем предусмотрено.
Не помню только, нужно чтобы в настройках css bootstrap был или они в плагине были.
Молодец. Над модулями каких соц. сетей ты планируешь работать?
P.S. Глянул бегло код на github и сразу несколько вопросов возникло:
1) Почему ты решил в сохранять глобальные настройки доступ к соц. сетям, а не в таблицу users?
2) Почему указываются в ручную поля чанка для поста у репоста, а не через метод объектов ->toArray()? К примеру, ты бы получил у товара дополнения miniShop2 все поля из его доп. таблицы, вроде цены, артикула и т.п.
3) самое главное, где проверка на то, что страница опубликована, а не черновик? Или на то, что дата публикации меньше?
4) значениях для всех tv получить дело 15 минут:-) чего поленился:-) Как же без главного изображения репостить?
Нет, это ещё детский лепет. Я встречал случаи, где умудрялись для минишопа кодировать в JSON таблицы с параметрами размером 4x20, до сих пор страшно вспоминать код, которымв сниппетах это все дело обрабатывалось для вывода на страницы категорий… Повторюсь, что все это берётся у этих разработчиков в голове не случайно, а именно из-за той не правильной подачи информации в уроках про слайдеры и её извращении, в которое потом развивается понимание MIGX и области его применения у них в дальнейшем.
Николай, вы уж простите, но вспоминая Хабр и ваши комментарии на нем о том, как ужасен код у Василия Намкина в дополнениях pdoTools и miniShop, то мне становится просто смешно слышать от вас что-либо на тему краткости изложения мысли. Хотя нет, давайте лучше вспомним ваши первые презентации modxShop в которых вы просто блистали чудесами навыка сжато подать максимум информации. Но это ладно, лучше, если вас не затруднит, ответьте мне на вопрос, почему ваш ученик Илья Уткин в своих статьях о кастомных CMP ссылался не на вас, а на того же самого Василия? Почему свои вопросы он задавал у него в комментариях на сайте, а не у вас лично? И почему все таки мне кажется, что именно благодаря Василию он в итоге стал спецом? Хотя по логике вещей он должен был на чистом PDO писать и всячески избегать pdoTools, как большее из зол? Если я что-то путаю, то не держите зла на меня дурака.
Точно также как и вы. Разница в том, что у Ильи Уткина, Сергея Прохорова и пр. ваших учеников за спиной были всегда вы и вы имели возможность
научить их что такое JSON и как его правильно использовать
. Ключевое слово
как его правильно использовать
, а не как написать слайдер и точка. И поверьте, что у абсолютного большинства, источником обучения являетесь все таки не вы, а подобные статьи, в которых вообще не сказано ни одного слова о минусах формата, в котором сохраняет MIGX. Откуда им знать, что у MIGX на самом деле достаточно узкая по сравнению со всеми остальными область применения? Да и вообще, когда дело дойдет до баз, какие причины у многих столкнувшись со схемами и пр. первыми проблемами на все это дело не плюнуть и забыть, как о страшном сне, тем более есть простой и обладающий теми же возможностями аналог MIGX?
От части, да, согласен с тобой. Возможно, что знания о формате должно быть. Но тем не менее конечная цель любого обучения — это знания, навыки и главное УМЕНИЕ. В частом начале MIGX запросто способен создать иллюзию у НОВИЧКА всего этого. А действительно, как может быть иначе, когда на JSON легко можно закодировать структуры абсолютно любой вложенности, да и ещё работать с ней, когда нужно что-то найти элементарным strpos? И после этих мыслей начинается…
Не самую лучшую же ты ссылку дал новичку… Даже дело не в том, что он говорит про параметр сниппета, а ты ссылку на класс для генерации критерии… В конце концов, не забывай, что в параметрах для getResources и pdoResources надо параметры указывать в JSONе, да еще и с тучей тонкостей:-) Надо было эту тогда уж скидывать:
Используй лучше pdoTools. В этом наборе много разных сниппетов, помимо pdoResources. На самом деле этого набора тебе хватит для большинства задач. Вот тебе ссылка на руководство к нему:
Кстати для pdoResource ты сам там и сможешь найти в какой параметр и что именно нужно указывать для фильтрации ресурсов по значениям в TV :-) Если не поленишься, то еще найдешь там очень много крутых возможностей:-)
И таких тысячи. Если вы не верите, то могу очень быстро найти еще тысячи примеров, с которыми не раз сталкивался лично. Вместо того, чтобы продолжить обучение и постепенно подойти к теме доп. таблиц в базах и дальше начать пользоваться всеми прелестями ООП люди тратят значительно большее количество времени на изобретение безумных LIKE'ов в SQL запросах для фильтрации каталога интернет-магазина на shopkeeper'е, а потом еще и функций чтобы на PHP дофильтровать, что при помощи SQL не смогли придумать, как убрать. Да и на том же minishop'е порой плохо становится, когда смотришь, что на нем умудряются сделать, когда вдруг становится недостаточно предусмотренных в нем типов данных… К примеру, можно взять такой параметр для ИМ драгоценных украшений: камни в кольце. Их может быть на одном кольце сразу несколько видов и еще помимо названия камня, вроде «Алмаз», «Сапфир», «Изумруд» еще также может иметься разный цвет… А ну да и в каталоге все это должно быть в фильтрах…
В этом не виноват ни MIGX, как и многое другое. В этом виновато отсутствие определенной базы в голове в момент знакомства с JSON и последующее чувство о его все могуществе при разработке сайтов.
1) Используй JSON и нет проблем. В него кстати декодируется любой массив при сохранении в поле properties в таблице users.
2) Используй ->toArray() и нет проблем
3) if($resource->get('published')) { действия не для черновика }
Про отложенную публикацию забудь, тк нужен cron
4) Код уже написал, чтобы TV вытащить. Для картинок из media source вытащить base_url не сложно.
3) Отложенного постинга говоришь? Разве под это дело event нет? Реализовать вообще тогда пара минут.
4) чего со временем должно быть, чтобы 4 строки не успеть написать?
$tvs = $modx->resource->getMany('TemplateVarResources');
foreach($tvs as $tv) {
$page[$tv->get('key')] = $page->get('value');
}
Не помню только, нужно чтобы в настройках css bootstrap был или они в плагине были.
P.S. Глянул бегло код на github и сразу несколько вопросов возникло:
1) Почему ты решил в сохранять глобальные настройки доступ к соц. сетям, а не в таблицу users?
2) Почему указываются в ручную поля чанка для поста у репоста, а не через метод объектов ->toArray()? К примеру, ты бы получил у товара дополнения miniShop2 все поля из его доп. таблицы, вроде цены, артикула и т.п.
3) самое главное, где проверка на то, что страница опубликована, а не черновик? Или на то, что дата публикации меньше?
4) значениях для всех tv получить дело 15 минут:-) чего поленился:-) Как же без главного изображения репостить?
ты хотя бы третье исправь:-)
P.S. На фиг нужны TV под опт. прайс? Лучше две колонки вместо них добавить в таблицу минишопа:-)
К примеру. Срачей вокруг минишопа искать лень
rtfm.modx.com/extras/revo/getresources#getResources-SelectionProperties
modx.pro/solutions/7634-search-extended-in-russian-and-english/
Кстати для pdoResource ты сам там и сможешь найти в какой параметр и что именно нужно указывать для фильтрации ресурсов по значениям в TV :-) Если не поленишься, то еще найдешь там очень много крутых возможностей:-)
modx.pro/solutions/7634-search-extended-in-russian-and-english/
И таких тысячи. Если вы не верите, то могу очень быстро найти еще тысячи примеров, с которыми не раз сталкивался лично. Вместо того, чтобы продолжить обучение и постепенно подойти к теме доп. таблиц в базах и дальше начать пользоваться всеми прелестями ООП люди тратят значительно большее количество времени на изобретение безумных LIKE'ов в SQL запросах для фильтрации каталога интернет-магазина на shopkeeper'е, а потом еще и функций чтобы на PHP дофильтровать, что при помощи SQL не смогли придумать, как убрать. Да и на том же minishop'е порой плохо становится, когда смотришь, что на нем умудряются сделать, когда вдруг становится недостаточно предусмотренных в нем типов данных… К примеру, можно взять такой параметр для ИМ драгоценных украшений: камни в кольце. Их может быть на одном кольце сразу несколько видов и еще помимо названия камня, вроде «Алмаз», «Сапфир», «Изумруд» еще также может иметься разный цвет… А ну да и в каталоге все это должно быть в фильтрах…
В этом не виноват ни MIGX, как и многое другое. В этом виновато отсутствие определенной базы в голове в момент знакомства с JSON и последующее чувство о его все могуществе при разработке сайтов.
Как указать то, что запись избранная
modx.ws/blog/uroki-modx-revolution/urok-vyivod-kontenta-snippetom-getresources.html
Вывод
Как указать то, что запись избранная
modx.ws/blog/uroki-modx-revolution/urok-vyivod-kontenta-snippetom-getresources.html
Вывод