No input file specifed это когда файл из SCRIPT_FILENAME не найден
тогда можно попробовать:
fastcgi_param SCRIPT_NAME index.php;
И перебрать все варианты от
fastcgi_param SCRIPT_FILENAME index.php;
fastcgi_param SCRIPT_FILENAME /index.php;
fastcgi_param SCRIPT_FILENAME www/index.php;
fastcgi_param SCRIPT_FILENAME /www/index.php;
на основании результата подумать, что не так.
@karpyuk7 Битрикс хреновый по многим параметрам, но зато он лучше всех вяжется с 1С т.к. продукты одной компании, на этом его технические плюсы заканчиваются.
Но экономических у него полно:
1) Конечно они готовы платить, когда они гуглят Joomla они находят комьюнити где обсуждают проблемы, когда гуглят битрикс они находят успешные кейсы.
2) Куча сертифицированных компаний - что для непонимающего клиента является весомым аргументом
3) Удобно съежать с притензий высказанных о платформе постфактоум, т.е. наежать почему вы впарили MODx могут, а с битриксом этот диалог заканчивается на раз два три.
4) Клиент оплачивает движёк, у него устойчивая связь в голове: если что то не может битрикс - то это то за что он заплатил. Если вы поставили друпал и он что то не может то это ваши проблемы а не друпала.
5) Если вы берёте много денег то должен быть битрикс - очень частая позиция клиентов на входе, при ценике от 300-500 тыс руб, на меньших цениках не знаю, скорее всего так же.
6) Клиенты проведё предворительный ресёрч часто знают что нужен битрикс и ищут тех кто с ним работает, вы им уже не продадите, что то ещё
7) У битрикса есть свой рынок, у опенсорс движков своего рынка нет, есть комюнити. Вам не надо ломать голову, вы можете брать все эти маркетинговые тексты про битрикс и брать оттуда аргументы для переговоров, для коммерческий предложений и т.д. Для других CMS вы будете это всё сами придумывать.
8) У меня нет цен под рукой, но если версия битрикса стоит 10 000, то со временем битрикс будет продовать её вам за 5 000 а вы клиенту за 10 000.
9) И т.д...
Я сам не работаю с битриксом, т.к. не знимаюсь поточным производством. Но если вы хотите делать на этом деньги и начинаете с нуля, то надо брать битрикс т.к. на нём намного проще заработать.
Я к сожалению не знаю вашей полной задачи.
У вас не может появиться задача отобразить количество комментариев у каждой новости в списке новостей?
Идея парсинга шаблона в вашем варианте мне не нравиться потому что:
1) бэктрейс и отладка будут очень своеобразными
2) шаблон управляет тем что будет вызванно, т.е. оттягивает на себя роль контроллера
3) что вы будете делать что бы пометить уже прочитанные пользователем комментарии? связать контролерры (comments + users ) через парсинг шаблонов уже не получиться.
Вы парсите шаблон на предмет наличия в нём блоков? Это плохая затея, представьте что у вас верстальщик работает. Для него такое будет постаянным молшебством, а для вас постаянным дёрганьем по его проблемам.
Блиц был адекватным 5 лет назад, думаю таким и остался, там же есть? что то типа fetch/rendContent/getBlock для того, что бы отрендерить блоки оберните это дело в класс
Добейтесь того что бы у вас вместо страницы var_dump показал все данные этой страницы, и там уже прикрутите Blitz
Вам скорее всего в любом случаее нужен контроллер страницы, что бы контролировать её, как бы банально это не звучало. Большинство MVC фрейворков по умолчанию используют адреса stite/controller_name/methood_name - это они не просто так.
Для вашего примера, как раз и нужно делать это в контролере.
Новость скрыли от просмотра/удалили, а при переходе на страницу комментарии остались? или вы сделаете контролер новости более главным чем контролер комментариев, так что бы он запрещал выполнение других контролеров? Если делать это где то ещё вы обростёте костылями.
Вам в любом случаее вам придётся связывать сущьность новости с сущьностью комментарии. Т.е. модель коментариев должена получить хотя бы id новости. И самый нормальный вариант это сделать в контроллере страницы "новости".
Вы посмотрите чуть дальше:
- Автор новости может удалять коментарии к своим новостям.
- В списке новостей нужно показать колличество комментариев.
- При добавлении комментария нужно отправить уведомление на почту автору этой новости
- и т.д.
Комментарии вообще без хозяина мёртвая сущность им по сути нужны только модель и вьюха, а контроллер в там не нужен.
Есть частный случай когда у контролер новости и контроллер комментария будут самостоятельными сущностями - это API, или ajax-сайт построенный поверх такого API.
