Ссылочка на сайт

С выходом более менее рабочей версии PHP 5.3, чем грозит переход на версию 5.3+?

TYPO3 работоспособна в среде PHP 5.3, однако есть несколько неприятных моментов, которые разработчики TYPO3 пока не спешат исправлять в данной версии. TYPO3 версии до 4.3 использует функции ereg_* которые объявлены устаревшими в новой версии PHP. Так же введен новый режим оповещения об ошибках E_DEPRECATED, и теперь установка отчета об ошибках в E_ALL переводит безобидные предупреждения о использовании устаревших функций, в ранг ошибок. В результате этого Ваш лог ошибок распухает от огромного количества сообщений, а если вдруг стоит отображение ошибок, то и к неработоспособности сайта.

Установка error_reporting в php.ini не дает нужного эффекта, так как TYPO3 имеет свое мнение на счет этих установок. Причем установка значение error_reporting в TYPO3 не определено нигде отдельно, а раскидано по множеству файлов и даже расширений. Что бы не изменять множество файлов и избавиться все же от сообщений в логах, нужно сделать следующее:

Запретить переопределение error_reporting, отключив соответсвующую функцию в php.ini:

1

disable_functions = error_reporting

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

1

error_reporting  =  E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_WARNING

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

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

Для реализации счетчика потребуется переменная для хранения текущего значения. В TYPO3 для хранения значений на этапе вывода используются регистры (registers), в которые можно сохранять любые данные и использовать их при выводе информации на сайт.

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

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

1
2
3
4
5
6
7

10 = LOAD_REGISTER
10.counter {
  cObject = TEXT
  cObject.data = register:counter
  cObject.wrap = |+1
  prioriCalc = intval
}

Идея проста – на каждой итерации любого цикла, LOAD_REGISTER будет выбирать значение регистра “counter” и дописывать к нему “+1″. Далее это значение будет вычисляться и помещаться назад в регистр “counter”.
Данный код может быть размещен в любом месте где Вам необходимо что либо считать: элемент меню – для вывода порядкового номера, RenderObj – для вывода порядкового номера контент блока.

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

Подробный пост на хабре

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

Дело в том что конфигурация выбирается последовательным перебором и _DEFAULT будет срабатывать всегда, даже если следом идет верная конфигурации для текущего домена. Правильная конфигурация для мультисайтовой системы не должна содержать _DEFAULT вообще или добавлять его после всех настроек доменов.

Подробнее о настройке RealURL можно прочитать в блоге Дмитрия Дулепова. Отдельно спасибо Дмитрию за то что указал на эту ошибку в моем конфиге.

config.typolinkEnableLinksAcrossDomains = 1

в случае indexed_search не работают.

Для того что бы заработали корректно ссылки между доменами в поиске требуется установить собственный параметр indexed_search:

plugin.tx_indexedsearch.search.detect_sys_domain_records = 1

Данный параметр инициирует проверку пути к каждой странице в результатах поиска и поиск в пути записей о доменах. Потом в случае одно-доменного сайта или сайта с доменами-синонимами лучше держать параметр выключенным, так как кроме замедления работы (множество запросов к базе на каждый результат поиска) пользы от включения этой опции не будет. Для мультисайтовой же среды с кросс-доменным поиском это необходимо. Возможно в комбинации с crawler и индексированием всех сайтов как External можно избежать этих накладных расходов, так как ссылки будут полностью сохраняться в кэше indexed_search, без нужды их строить.

Поздравлю всех c этим событием. Надеюсь интерес разработчиков к этой замечательной CMS системе в России значительно вырастет.

PS.: Если у Вас есть ресурсы не включенные в список или Вы знаете о таких сайтах, потратьте 2 минуты – заполните форму на сайте CMS Magazine.

Анонс релиза

Проблема решена и сделан коммит в поддерживаемые ветки TYPO3. Исправлений можно ожидать в релизах 4.1.11, 4.2.7 и 4.3-beta1. К сожалению, пока не понятно когда будет очередное обновление.

Сейчас проблему можно исправить самостоятельно с помошью патчей:
4.2.x
4.1.x

На unix системах патч применяется из папки с исходными текстами TYPO3 (typo3_src-4.2.x) следующей командой:
patch -p0 < 0011009.patch

После применения патча не забудьте удалить кэш JS-файлов:
rm -f typo3temp/rtehtmlarea/*