Можно запускать из консоли (из-под крона тоже) php файл.
$ php script.php
Тогда не требуется затачивать алгоритм под shell, все работает привычным образом.
24 декабря 2015, 17:28
+3
Полностью поддерживаю.
По такому запросу даже хороший низкооплачиваемый специалист (встречаются хорошие специалисты, сильно занижающие стоимость, хоть и очень редко) возьмет не менее 50 000 руб. Все, что ниже — поделки начинающих фрилансеров без гарантии результата.
24 декабря 2015, 15:57
+4
Жадным — нельзя.но понятие жадности у всех свое :)
От 90 без учета дизайна :)
24 декабря 2015, 12:42
+1
Добавленные через CilentConfig записи почти ничем не отличаются от обычных системных настроек.
В шаблонах и чанках вызываются так: [[+key]]
В php вызывается так: $modx->getOption('key');
23 декабря 2015, 19:52
+1
Один раз самостоятельно можно изменить хост, к которому привязана покупка.
23 декабря 2015, 14:50
+1
Изучить работу компонента Login и/или HybridAuth.
23 декабря 2015, 00:22
0
Все верно.
22 декабря 2015, 23:15
+2
Задайте 2 и 3 параметр пустыми строками, 4-й параметр — нужная Вам схема.
22 декабря 2015, 21:57
0
Это оптимальный вариант. Тем более, через транспортник можно сделать все, что угодно.
22 декабря 2015, 14:22
0
Ответил в поддержке.
21 декабря 2015, 17:56
0
Тоже очень хороший вариант.
Что касается идеального варианта, единственный способ сделать универсально — задать какие-то минимальные рамки, соблюдения которых требовать от всех разработчиков, которые выберут твой инструмент для работы. А дальше решение уже за ними — если соблюдают, то все хорошо и корректно переносится. Если нарушают требования, то иногда получают непредсказуемый вариант.
При этом, синхронизатор должен иметь несколько режимов работы. Как минимум:
1) Управление копиями через мастер-сервер
2) Выгрузка обновлений с тестового сервера на рабочий (-е).
Если же мы говорим о работе и изменениях непосредственно на рабочем, например, как в твоем случае, то здесь вообще синхронизатор не нужен. Достаточно простого протоколирования изменений.
21 декабря 2015, 17:01
0
Верно, это далеко не единственная частность.
Таких подводных камней бесчисленное множество. По этой причине, создавая инструмент переноса данных, необходимо сразу определиться с некоторыми условностями. Например, запретить изменение username пользователям, не переименовывать TV после отправки по другим сайтам и тд.
Ресурсы можно тоже легко и успешно переносить между сайтами, изменять их содержимое, здесь вариантов 2:
1) В самом ресурсе определить поле, которое не изменяется ни при каких условиях
2) Создать отдельную таблицу, в которой будет сохраняться соответствие ресурса и дополнительного служебного кода этого ресурса. Кстати, мой синхронизатор стоит дополнить вторым механизмом, получится более красивая и удобная вещь.
21 декабря 2015, 16:27
0
Этот момент тоже стоит проверить и осветить, если Gitify корректно сумеет поддерживать в актуальном состоянии несколько рабочих копий. В теории сложностей не должно быть, это факт. Как на практике — вопрос :)
21 декабря 2015, 15:20
0
На прошедшей конференции я рассказывал о синхронизации множества установленных копий. Как Иван правильно отмечает, с ID ситуация не слишком однозначная. К тому же, когда появляется второй (и не только) разработчик, становится сложнее управлять всеми изменениями.
Идея хорошая, но в процессе выплывает очень много подводных камней. По этой причине советую прислушаться к Ивану и заранее продумать вопросы, связанные с ID и несколькими разработчиками.
Сюда же, кстати, можно отнести и вариант попутной разработки отдельных компонентов, которые нужны для проекта, но предполагаются для дальнейшего массового распространения. Необходимо сразу предусмотреть вариант разделения проекта на отдельные составляющие.
Заодно уж: Иван, расскажи, пжл, насколько Gitify подходит для поддержки одновременно нескольких рабочих серверов?
18 декабря 2015, 12:19
0
Да.
15 декабря 2015, 14:58
0
Приезжаю в Минск в пятницу в 07:00, уезжаю после мероприятия в ночь с сб на вс в 01:00.
Что делать в пятницу, пока не очень понятно, на экскурсию запишусь, если только не по музеям )))
Афтер-пати — что-то тихое, как правильно выше подметили. Какая кухня и прочее, значения не имеет. Пиво не пью, равно как и все прочее алкогольное :)
13 декабря 2015, 21:17
+2
Поддержу. Есть необходимость в компоненте, который будет показывать текущее состояние сайтов. В том числе, версии установленных пакетов. В идеале, такой компонент должен расширяться плагинами, каждый из которых занимается отслеживанием собственных сущностей.
11 декабря 2015, 22:42
0
$resource->content;
Или
$resource->__get('content');
11 декабря 2015, 12:00
0
Отличное обновление!
Фильтр в mSearch2 прекрасный, но принцип поиска всегда отталкивал. Теперь то, что нужно!
$ php script.php
Тогда не требуется затачивать алгоритм под shell, все работает привычным образом.
По такому запросу даже хороший низкооплачиваемый специалист (встречаются хорошие специалисты, сильно занижающие стоимость, хоть и очень редко) возьмет не менее 50 000 руб. Все, что ниже — поделки начинающих фрилансеров без гарантии результата.
От 90 без учета дизайна :)
В шаблонах и чанках вызываются так: [[+key]]
В php вызывается так: $modx->getOption('key');
Что касается идеального варианта, единственный способ сделать универсально — задать какие-то минимальные рамки, соблюдения которых требовать от всех разработчиков, которые выберут твой инструмент для работы. А дальше решение уже за ними — если соблюдают, то все хорошо и корректно переносится. Если нарушают требования, то иногда получают непредсказуемый вариант.
При этом, синхронизатор должен иметь несколько режимов работы. Как минимум:
1) Управление копиями через мастер-сервер
2) Выгрузка обновлений с тестового сервера на рабочий (-е).
Если же мы говорим о работе и изменениях непосредственно на рабочем, например, как в твоем случае, то здесь вообще синхронизатор не нужен. Достаточно простого протоколирования изменений.
Таких подводных камней бесчисленное множество. По этой причине, создавая инструмент переноса данных, необходимо сразу определиться с некоторыми условностями. Например, запретить изменение username пользователям, не переименовывать TV после отправки по другим сайтам и тд.
Ресурсы можно тоже легко и успешно переносить между сайтами, изменять их содержимое, здесь вариантов 2:
1) В самом ресурсе определить поле, которое не изменяется ни при каких условиях
2) Создать отдельную таблицу, в которой будет сохраняться соответствие ресурса и дополнительного служебного кода этого ресурса. Кстати, мой синхронизатор стоит дополнить вторым механизмом, получится более красивая и удобная вещь.
Идея хорошая, но в процессе выплывает очень много подводных камней. По этой причине советую прислушаться к Ивану и заранее продумать вопросы, связанные с ID и несколькими разработчиками.
Сюда же, кстати, можно отнести и вариант попутной разработки отдельных компонентов, которые нужны для проекта, но предполагаются для дальнейшего массового распространения. Необходимо сразу предусмотреть вариант разделения проекта на отдельные составляющие.
Заодно уж: Иван, расскажи, пжл, насколько Gitify подходит для поддержки одновременно нескольких рабочих серверов?
Что делать в пятницу, пока не очень понятно, на экскурсию запишусь, если только не по музеям )))
Афтер-пати — что-то тихое, как правильно выше подметили. Какая кухня и прочее, значения не имеет. Пиво не пью, равно как и все прочее алкогольное :)
Фильтр в mSearch2 прекрасный, но принцип поиска всегда отталкивал. Теперь то, что нужно!
В нем используется сервис, предложенный Петром.