dmitriy

.htaccess используется?

это тот случай когда adapter db не использует psr logger interface и не использует SOLID

$route['(:num)'] = 'main/view/$1';
$route['(:any)'] = 'pages/view/$1';

должны быть в самом начале

Самый верный способ залезть в код библиотеки

Разработал интернет магазин на CI 2-3, 7 лет на нем работал без проблем да и в принципе проработал если не одно но, некоторые вещи на нем не очень хорошо реализованы, и избавиться/заменить их проблематично, в итоге пришлось отказаться в пользу composer и свободного набора компонентов: ORM Propel2, League Conteiner, FastRoute, Symfony Console, Twig, Monolog и пр

Могу посоветовать сделать так чтобы функционал разработанный сейчас на CI легко можно было заменить на другой фрейм. (DDD, SOLID)

Можно все директории application, system вынести на уровень выше document root, думаю это подойдёт как альтернатива этому

да

С стороны 1 с подключаться
По фтп к сайту и выгружать файл для экспорта в 1с, после выгрузки дергать url на сайте для загрузки данных в db сайта, загрузка в 1с ещё проще просто дергаешь urlp с данными csv

$config['cookie_domain']
не такой ведь должен быть

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

что бесит в CI:
1. $this->loader->library("lib_name");
- подключение зависимостей происходит через лоадер, любая библиотека, является singliton объектом,это порождает некоторые проблемы в тех местах где нужны новые экземляры, а нужны синглитоны в 2% случаях
- автоподстоновка в IDE не работает
- отсутствие многослойности, мы можем get_instance()->loader->library("lib_name"); сделать в любом месте даже в классе ядра, что позволяет разрабатывать сильно связанный монолитный код
как нужно:
class Controller function __construct(LibName $lib_name){} - все

2. Класс к бд простой query builder, как ни крути в результате много дублирующего кода, - работа с массивами зло, когда строишь приложение и пишешь CRUD справочники например для админки, то придется писать прослойки - CRUD классы, а это тот же Repository, иногда нужно одни и те же модели отделять от слоя хранения а это уже datamapper, и вообще удобно использовать коллекции а не массивы данных получаемых из бд, если все вместе взять то тут и приходит необходимость использовать ORM который имеет под капотом все необходимое.

3. Логгер, ну не psr он, нельзя отказаться от хранилища в файлах и логировать в бд, или выводить на экран в консоль. После использования monolog, логгер CI выглядет убого

4. Миграции, если честно пробовал запускать, работают из браузера, а должны из консоли, можно создать консольные контроллеры с накаткой миграций, но тем не менее приходится много править в миграциях и коде когда меняется структура таблиц, например простейшая задача сменили название колонки, прошлись по коду сменили все использования этой колонки, создали миграцию, изменили модели, если проект большой сделать это не просто. В Propel2 ORM это делается в одном месте в xml конфиге и модели, миграции, перестраиваются одной командой.

5. тесты под капотом они убоги, просто так unit тесты не запустить нужно долго плясать с бубном.
6. Exception просто отсутствуют, работа с исключениями ведется через собственный механизм
7. PSR не используется
8. Работа с конфигами, они разделяются по папкам окружения, не кошерно, особенно когда все добро с доступом к бд комитят в гит, используйте .env

п.с. в новой версии знаю уже многие вещи будут исправлены но тем не менее проще собрать приложения на каркасе https://github.com/mmeyer724/Frameworkless

$route['(:any)'] = "startup/index";

//class Controller
function index(){
$segments = $this->uri->segment_array();
}

два модуля один формирует страницу и позволяет редактировать html, второй отвечает за формирования блока по id и также редактируется как html, определяем правило использования блоков в странице например по шаблону

{CONTENTPART|text1}<br/> {CONTENTPART|text2}<br/> {CONTENTPART|text3}

модуль отображающий страницу анализируя контент, находя снипеты, подключает модуль блока с нужным id и заменяет содержимое его ответом

1. если у вас импорт происходит по крону то о каком ajax идет речь?
2. в самом начале скрипта:

@set_time_limit(0);
		@ini_set("max_execution_time", 0);
		@ini_set("max_input_time", "3600");
		ignore_user_abort(true);

Сейчас в тренде не только скорость разработки сайтов но и качество, а качество это прежде всего тестируемость кода, его поддержка, масштабируемость. Когда сталкнётесь с этим тогда упретесь в такие штуки как SOLID, GRASP. Так вот CI как раз весь погряз в противоположенных STUPID практиках.
Если проект не сложный подойдет CI, если по сложнее то можно и CI но кучу всего придется подтягивать через composer, а потом поймете что можно взять тот же Laravel где все есть из коробки.

править файл .ini который будет переопределять настройки при старте системы

3 мало чем отличается от 2 версии

давно использую composer в Codeiniter3
схема настройки следующая:
1. подтянуть codeigniter через composer

"require": {
	"codeigniter/framework": "3.0.*"
    },

2. в стартовом файле public_html/index.php

$system_path = '../vendor/codeigniter/framework/system';

3. Ну и самое приложение public_html/application

и все, никаких проблем при обновлении нет

у меня так вывод идет:

$filename='invoice.xlsx'; 
		header('Content-Type: application/vnd.openxmlformats-officedocument.excelprocessingml.document'); 
		header('Content-Disposition: attachment;filename="'.$filename.'"'); 
		header('Cache-Control: max-age=0'); //no cache
		$objWriter = PHPExcel_IOFactory::createWriter($objPHPExcel, 'Excel2007');

		$objWriter->save('php://output');	
		
		die();