Александр

Александр

С нами с 19 декабря 2015; Место в рейтинге пользователей: #20
Александр
05 апреля 2020, 01:39
0
Не понятно в чем проблема на хостинге. Ты бы хотя бы консоль разработчика chrome открыл и посмотрел какие запросы и ответы идут при запуске скрипта.
Александр
04 апреля 2020, 16:25
0
Жесть. Вообще беккап базы каждый день должен делаться.
Вы посмотрите от какого юзера modx работает в core/config/config.inc.php. Если там не root то все просто заходите под этим пользователем и востонавливаете root или беккап делаете.
А если root то непонятно почему работает. Но если работает наверно проще поставить modx.cc/documentation/additions/databackup/ и сниппет backup выполнить.
Александр
04 апреля 2020, 16:05
0
Вроде правильно скрипт написан… А что не получается?
Александр
28 марта 2020, 18:55
0
Вообще rename_it.php сперва переименовывает папку компонента. То есть ту папку в которой запускается.
D:\Server\OSPanel\domains\create-component попытался переименовать в D:\Server\OSPanel\domains\myFirstComponent. Но скорей всего не получилось, так как папка D:\Server\OSPanel\domains\create-component открыта в командной строке и винда не дала переименовать.
В rename_it.php в строке 31 @rename($start, $end); убери собаку, чтоб команда выводила ошибки.
rename($start, $end);
Ну или просто в cmd не переходи в эту папку.
D:\>php D:\Server\OSPanel\domains\create-component\rename_it.php myFirstComponent
Александр
23 марта 2020, 15:27
+1
Извиняюсь. Наверно не дожал заплатить. Их там куча вылазить. Сейчас отправил. Дошло?
Александр
23 марта 2020, 14:39
0
Кому стало полезно))): донатики
Сюда нажал. На яндекс перекинуло.

Со своей сборкой почти все победил. Как собрать разобрался, пакеты добавил, добавил сразу настройку поставщика модсторе, ошибки пролечил. И тут оказалось что все шаблоны и чанки на php написаны :-(. А на это привыкать не надо. В pdoTools поддержку $modx и php я вырубил. Придется чанки и шаблоны с другого проекта брать или самому переписывать ;-(.
Александр
23 марта 2020, 00:41
0
Задонатил чуток :-). Но как собрать свою сборку на базе твоей не слишком понятно :-(. Сижу разбираюсь :-).
Александр
21 марта 2020, 14:58
0
{'!TicketLatest' | snippet : [
      'checkPermissions'=>'list',
]}

Тест лишнее. Не работает. Наверно основной класс запроса не Ticket, поэтому не срабатыват. Извиняюсь, лезть в код не стал и точно сказать не могу. Только проверил.
Александр
21 марта 2020, 05:33
0
Блин фиг пойми как заметку переписывать :-(. Сразу логические связки теряются :-). Ладно, надеюсь, комментарии читать будут.
Александр
21 марта 2020, 05:29
0
Мда… Как то не подумал что list прокатит. Думал надо заводить какие-то отдельные права :-(. Вообщем не сообразил.
Для getTickets тоже прокатило. А с TicketLatest уже не срабатывает.
Александр
20 марта 2020, 06:33
0
Я в старом modExtra делал. Там в build.config.php ресолверы подключаются
$BUILD_RESOLVERS = array(
    'tables',
    'chunks',
    'default_fields',
    //'setup',
    //'office',
);
Главное после tables его включить. В tables сами таблицы создаются.
В новом modExtra build.php
// Add resolvers into vehicle
		$resolvers = scandir($this->config['resolvers']);
		
		foreach ($resolvers as $resolver) {
			if (in_array($resolver[0], ['_', '.'])) {
				continue;
			}
			if ($vehicle->resolve('php', ['source' => $this->config['resolvers'] . $resolver])) {
				$this->modx->log(modX::LOG_LEVEL_INFO, 'Added resolver ' . preg_replace('#\.php$#', '', $resolver));
			}
		}
Ресолверы сами подключаются из папки. Наверно их стоит переименовать 1tables.php и т.д. Может сработает. Проверять надо.
А вы как данные в базу подключаете? Или еще не подключаете?
Александр
19 марта 2020, 13:52
1
+1
Я тупо в ресолвере через newObject добавляю. Если есть лучше вариант, то будет интересно узнать.
resolve.default_fields.php
/** @var xPDOTransport $transport */
/** @var array $options */
/** @var modX $modx */
if ($transport->xpdo) {
    $modx =& $transport->xpdo;
	/** @var array $options */
	switch ($options[xPDOTransport::PACKAGE_ACTION]) {
		case xPDOTransport::ACTION_INSTALL:
			$fields = [
				[
					'name'=>'res_id',
					'label'=>'Мероприятие',
					'dbtype'=>'int',
					'precision'=>10,
					'phptype'=>'integer',
					'xtype'=>'tevent-univers-combo',
					'sort'=>1,
					'validate'=>'required',
					'select_query'=>
'{
    "parents":"0",
    "template":"1"
}',
					'filter'=>true,
					'active'=>true,
				],
///еще поля
			];
			foreach($fields as $field){
				if(!$in_field = $modx->getObject('tEventField',['name'=>$field['name']])){
					if($in_field = $modx->newObject('tEventField')){
						$in_field->fromArray($field);
						if(!$in_field->save()) $modx->log(xPDO::LOG_LEVEL_ERROR, "[tEvent] field {$field['name']} not add!");
					}
				}
			}
			$modx->log(xPDO::LOG_LEVEL_INFO, '[tEvent] Successfully add Default fields!');
			break;

	}
}
Александр
05 марта 2020, 12:32
0
Читал год назад. (int) использую, а с санацией строки проблема вышла. В поле название города кавычки писались и его никто найти не мог. Так что, санация это работа надолго :-(.
Александр
05 марта 2020, 12:20
0
Актуальность в одну минут, вообще не принципиально)))
В смысле, крон настраивать запросы для этих таблиц писать. На 80 базовых таблиц — это офигенное кол-во временных. Сайт только висеть будет их генерировать.
Александр
05 марта 2020, 12:05
0
Если бы ты принял этот PR, пришлось бы pdoTools удалять.
Дыры много где есть. И никто вам не мешает взять и переписать PR или что-то еще без дыр, если они там есть. Вроде ничего такого не должно быть. Все стандартные дыры MODX только.
Александр
05 марта 2020, 11:50
0
Никогда не понимал зачем такие мега запросы писать. Бесполезных join-нов куча. Этаж сколько выборка этого всего идти будет. А потом еще сидеть постоянно разбирать что там написано.
Выборка достаточно быстро идет. Какие-то тормоза не заметны. И в каком таком случае не приходиться разбирать что написано? Что в сниппете что в запросе одинаково приятно.
Для таких запросов проще временную таблицу сделать куда будут данные сливаться на бэкенде, и потом уже готовые данные забирать на фронте.
И еще за актуальность временных таблиц следить. Причем разных нужных данных может быть много вариантов. Вроде кол-во перестановок пропорционально n! Если 2 таблицы по 5 колонок, то кол-во возможных выборок 10! = 3628800 вариантов :-).
Александр
05 марта 2020, 11:39
0
Ну если вы магистр напишите внятную инструкцию как делать санацию параметров.
$where['id'] = (int)$_POST['id'];
(int) это понятно. Для даты strftime можно использовать. А остальное? string, decimal, float. Хотя тоже все понятно. Только писать такие преобразования во все сниппеты долго. Плагин или что-то такое посмотрю. Ну здесь на интранет хакеров лет 10 не предвидеться. А если и предвидятся, то взлом внутреннего сайта это уже мелочь.
Александр
04 марта 2020, 23:49
+1
Известная проблема :-)
В файле faq.mysql.schema.xml
<field key="question" dbtype="text" length="1023" phptype="text" null="false" default=""/>
phptype=«text» нет такого. Когда-то работало, а сейчас надо phptype=«string». Замените phptype=«text» на phptype=«string» везде в схеме и перегенируйте классы XPDO. Я с помощью migx это делаю. Создание таблиц через MIGX
Александр
04 марта 2020, 22:44
0
Сколько будет выполнятся такой вопрос, если сверху на него навесить абстракцию в виде pdoTools? Сорок лет?
Преобразовать массив на 10-40 ключей в строку 100-600 символов? Явно миллисекунды :-).

После последней правки, подзапрос добавил плюс 7 мс к общему выполнению запроса. getChunk операция затратная. Целых 5 мс :-).
Александр
04 марта 2020, 22:16
-2
А если серьёзно, то ты пишешь очень сложный запрос, который не понадобится 99% пользователей pdoTools, а может и вообще MODX
Если 1% понадобится, то уже неплохо. 99% не понадобиться — это не слишком хороший критерий. Взлетит не взлетит 100% не угадаешь. То есть, это критерий на способности предсказывать будущие. А оно не слишком предсказуемо.
Он не станет менее сложным, если засунуть его в массив Fenom, никто ничего от этого не выиграет.
А, кстати, тогда зачем вообще запросы описывать массивом феном? Можно же вообще писать чисто SQL.
XPDO это типа ORM. В нем получил объект и сразу можно что-то записать в базу. В pdoTools только чисто вывод.
Мне просто удобнее сам синтаксис pdoTools писать. И, так как запрос массив, есть возможность на лету его поменять. Приготовил массив запроса, а потом where добавляешь или удаляешь когда надо. На чисто sql менять where жуть. Код 5 лет назад :-). Ни pdoTools ни strftime еще не знал.
if(isset($_GET['date1'])){
    $modx->setPlaceholder('date1',$_GET['date1']);
    if(isset($_GET['date2'])){
        $modx->setPlaceholder('date2',$_GET['date2']);
    }
    if($_GET['date1']!='' and $_GET['date2']==''){
       $where = "where o.makedate >='".$_GET['date1']." 00:00:00' and l.status_id=1"; 
    }elseif($_GET['date2']!=''){
        $where = "where o.makedate >='".$_GET['date1']." 00:00:00' and o.makedate <='".$_GET['date2']." 23:59:59' and l.status_id=1";
    }
}else{
    $where = "where l.status_id=1";
}
Тоже для XPDO и pdoTools
$where = [ 'l.status_id'=>1];
if($_GET['date1']){
    $modx->setPlaceholder('date1',$_GET['date1']);
    $where['o.makedate:>='] = '".$_GET['date1']." 00:00:00'";
}
if($_GET['date2']){
    $modx->setPlaceholder('date2',$_GET['date2']);
    $where['o.makedate:<='] = '".$_GET['date2']." 23:59:59'";
}
Явно проще. Особенно когда фильтр больше на параметров 6.
А вот пример уже с феном.
{set $where = [
        'Detail.flanec:NOT IN'=>[1,3],
        'Detail.sech'=>'pryam',
        ]}
    {if $.get.sk_order_id}{set $where['Detail.sk_order_id']=$.get.sk_order_id}{/if}
    {if $.get.smena_id}{set $where['tSkladDetNSLink.smena_id']=$.get.smena_id}{/if}
    {if $.get.type_job_id}{set $where['DetailClass.type_job_id']=$.get.type_job_id}{/if}
Так что запрос в массиве штука полезная.
А вот подзапросов в массиве у меня не было. Поиграюсь, посмотрю, что можно с ними сделать. Хотя, конечно, их на каждом шагу внедрять не стоит.
Усилия по добавлению этого функционала не просто ничего не стоят, они отрицательные не длинной дистанции, потому что нужно будет отвечать на вопросы по конвертации этих твоих вложенных массивов в SQL.
Это аргумент. Отвечать на вопросы кучи начинающих прогеров не самая приятная перспектива. Но тормозить из-за этого компоненты или проекты?? Это раз. И два. Отвечать имеет смысл, если развивать свою команду. С которой можно делать очень большие проекты. Такие как linux, например. Думаю сеньор не предел развития программиста. Можно как-бы основать свою школу и стать что-то вроде академика.
Периодически будут находиться люди, пытающиеся наворотить какую-нибудь фигню в этими параметрами. Как сейчас это делают с долбаным tvFilters.
Будут явно. Люди пытаются решить свои задачи. Изучаем их задачи и пишем код, чтобы у них был инструмент для их задач :-). Прикалываюсь, если что :-). Но в каждой шутке доля шутки…

Резюме.
Я этот PR не приму, удачи в развитии своих дополнений.

Ну как хотите. Я то надеялся, что вот крутая фишка пользуйтесь. Но, возможно, это и не так круто как мне кажется. Подзапросы, когда они мне понадобятся буду писать в своей версии синтаксиса pdoTools. Просто потому, что мне так удобнее. Сейчас, практические преимущества этой версии не понятны :-(.

PS. Сюда $fields массивом иногда приходят.
$fields = 'SQL_CALC_FOUND_ROWS ' . $fields;
В итоге запрос выглядит так:
SELECT SQL_CALC_FOUND_ROWSArray FROM
Где $fields массивом становиться не нашел. Просто implode сделал. Может разберетесь?