Добавлено 15 часов спустя:

#41899 Yusupov:

Есть же хуки page.add.add.import и page.edit.update.import.

Вопрос решен, спасибо.

С чем мы можем дополнительно столкнуться в данном варианте:

1. Доп.поля не стандартных типов. Решение: используем приведенные Булатом хуки, с помощью которых можно дополнительно провести выборочную обработку полей после импорта. Тоже самое для вывода, используя `pagetags.main`.
2. Если мы не хотим «светить» наши экстаполя в интерфейсе Админки. Решение: удалить их из списка вывода используя хук `admin.extrafields.loop`.

1. Хочу услышать подробней про сценарий использования, что будет вызываться по хуку (имею в виду алгоритм той части что будет вызвана в конкретно вашем случае). 

Задача была следующая:

Написать плагин, который после установки создает N количество дополнительных ячеек в таблице cot_pages, на данный момент их 4, потом будет больше 10. Содержимое должно заполняться в добавлении, правиться в редактировании, выводиться на страницах модуля page. В приоритете использовать по максимуму возможности движка, а дописывать по минимуму. Плагин будет расширяться по мере развития. С содержимым потом будут работать функции, например слаживать результат вывода 2 полей и выводить готовый параметр и тд. 

Добавление проблем не вызвало, в setup папке файлы install и uninstall своё дело сделали, в Hooks=page.add.tags  создались теги.

Редактирование тоже проблем не вызвало Hooks=page.edit.tags.

Вывод на страницу тоже проблем не вызывает Hooks=page.tags.

Для того чтобы всё вышеперечисленное работало, осталось параметры скидывать в нужном направлении. Просмотрел весь код файла page.functions.php, код аналогичных модулей / плагинов, и пришел к выводу что во многих функциях есть хуки, а в этой нет. Так как в функцию нужно передать идентичные данные , например:

$rpage['page_myone'] = (int)cot_import('rpage_page_myone', $source, 'INT');

$rpage['page_mytwo'] = (int)cot_import('rpage_page_mytwo', $source, 'INT');

Попробовал вариант с добавлением хука, и всё стало работать как часики. Если есть более продвинутые варианты решения подобной задачи, с удовольствием почерпну опыт, пригодится не один раз еще, и другим будет полезно почитать.

#41898 Macik:   Мое мнение таково, что расширение функций хуками не очень хорошая практика (не смотря на то, что много где используется в нашем движке). 

Если есть более оптимальный способ решения подобных задач, то можно конечно и без этого хука обойтись, просто я исходил из того, что в других подобных функциях он есть.

1. Хочу услышать подробней про сценарий использования, что будет вызываться по хуку (имею в виду алгоритм той части что будет вызвана в конкретно вашем случае). Потому, как изменять импортированные данные или добавлять дополнительные в `$rpage` можно и во вне функции.
2. Слово `query ` здесь в названии хука лишнее, и используется в случаях когда хук призван изменять значения строк составляющих будущий SQL запрос. Логичнее назвать его `page.import.main` по аналогии с другими частями. Или если четко следовать букве правил именования, то `page.functions.import.main`
3. Мое мнение таково, что расширение функций хуками не очень хорошая практика (не смотря на то, что много где используется в нашем движке). Поясню — функция как программный блок и часть API  должна быть максимально понятной, атомарной, детерминированной. Если мы внедряем внутрь хук мы теряем эти свойства. Плюс несколько усложняем отладку.

При разработке плагина расширяющего возможности pages, столкнулся с необходимостью работы с функцией cot_page_import. Заметил что в некоторых функциях хуки есть, а в некоторых нет.

Как насчет того чтобы добавить хук  page.import.query в функцию cot_page_import перед   $parser_list = cot_get_parsers();  чтобы можно было коннектиться сторонними плагинами.

   	/* === Hook === */
	foreach (cot_getextplugins('page.import.query') as $pl)
	{
		include $pl;
	}
	/* ===== */