Переместите существующие страницы на вновь созданные страницы с помощью TYPO3 DataHandler - PullRequest
Новая
       33

Переместите существующие страницы на вновь созданные страницы с помощью TYPO3 DataHandler

0 голосов
/ 02 апреля 2020

Я использую DataHandler для создания и перемещения страниц, как в этом фрагменте. Хотя новые страницы создаются нормально, существующие подстраницы не перемещаются в их вновь созданных родителей.

Это создает новую страницу, но не перемещает существующую страницу 

$data = [
    'pages' => [ 
        'NEW_IT' => [
            'pid' => 1,
            'hidden' => false,
            'title' => 'IT',
        ],
        591 => [
            // this is not set
            'pid' => 'NEW_IT', 
            // but this is set
            'title' => 'I am a child of IT', 
        ],
    ]
];

Я пытался ['pages'][591]['move'] = 'NEW_IT' но тоже безрезультатно.

Я также пытался '591' вместо 591, dataHandler->reverseOrder = true и dataHandler->copyTree = true.

dataHandler->errorLog пусто.

Напротив, это работает ( новая страница на новую страницу) 

$data = [
    'pages' => [ 
        'NEW_IT' => [
            'pid' => 1,
            'hidden' => false,
            'title' => 'IT',
        ],
        'NEW_IT_SUB' => [
            'pid' => 'NEW_IT',
        ],
    ]
];

Также мне интересно, какие идентификаторы (NEW<any string> против NEW<base64> et c.) приемлемы, так как я ничего не нашел в документации и в примерах использования разные стили. «Должно быть уникальным» очевидно. Но я не понимаю, почему некоторые люди генерируют UUID там.

Ссылки

РЕДАКТИРОВАТЬ: I открыл кузнечный билет: https://forge.typo3.org/issues/90939

1 Ответ

1 голос
/ 02 апреля 2020

Я проверил код / ​​DataHandler в v8 / v9 и мастер. Соответствующая логика c в DataHandler для этого не изменилась.

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

Создание страницы => извлечение замененного идентификатора => с использованием его для других команд данных.

Обработчик данных просматривает каждую запись для таблицы в предоставленном массиве набора данных. 

foreach ($this->datamap[$table] as $id => $incomingFieldArray) { ... }

Сначала он готовит некоторые вещи и, вызывая зарегистрированные processDatamap_preProcessFieldArray перехватчики, проверяет заданный $ id 

// Is it a new record? (Then Id is a string)
if (!MathUtility::canBeInterpretedAsInteger($id)) { ... } else { ... }

Если идентификатор не является целочисленной или целочисленной строкой , он выполнил true-ветвь, иначе false-ветвь. Так долго, так хорошо.

TRUE-Branch обрабатывает создание новой записи (page, tt_content, ...), добавляя замену для предоставленного NEWxxx в качестве замены и т. Д.

Он также проверяет, есть ли в записи поле 'pid' и содержит ли оно NEW. Если это так, он заменяет NEWxxx на uid ранее созданной записи.

С другой стороны, если $ id не является целой или целочисленной строкой, предполагается, что это существующая запись. (ЛОЖЬ-Branch). В этой ветке нет проверки 'pid', если она содержит NEW и ищет замену.

Но .. почему нет ошибки? Если он не заменит его, он должен взломать sh или что-то в этом роде? - Да, это то, что мы предполагаем - по крайней мере, для этого.

'pid' всегда игнорируется при применении к записи (см. Метод fillInFieldArray()) 

switch ($field) {
    case 'uid':
    case 'pid':
         // Nothing happens, already set
         break;
  ...
}

и т. Д. .. до тех пор, пока вы не предоставите дополнительные поля / значения во втором массиве страниц (с целочисленным идентификатором и pid с NEW из начального), это не имеет никакого отношения. Ничего не делать - это не ошибка - и поэтому ничего не делать и даже ничего об этом не уведомлять.

Это ошибка? Не знаю, лично я бы сказал да. Но, возможно, это следует создать как проблему и в конечном итоге обсудить с основным разработчиком / другими участниками.

Может быть, были / есть причины, ПОЧЕМУ он делает только этот прогон

Либо следует изменить документацию, чтобы было ясно, что замена 'pid' работает только с идентификатором $ id => [], также является новым идентификатором / идентификатором пользователя / или вы должны сделать это за 2 раунда.

Или ... добавьте функцию отслеживания ошибок в качестве функции / ошибки, и давайте обсудим это. И, может быть, попытаться реализовать это в ветке ЛОЖЬ / существующая запись. Но давайте послушаем несколько других мнений об этом.

Если другие сделают это также для существующих записей в том же раунде, я бы взял время завтра / на выходных, чтобы предоставить патч для него / проблема. (Было бы весело бороться с обработчиком данных).

...