Проблема с RTE и таблицами

[Valery Romanchev]

Настраиваю вставку таблиц из Word в RTE
Все было бы хорошо, если бы не преобразование тегов o с помощью htmlspecialchar при отображениии в FE.
Как я понял, бороться с этим можно в двух местах:
1) либо настроить сохранение RTE - DB
2) либо настроить отображение DB - FE
Ни то ни другое не получилось!
Что делал:
1) в TS Config:
### RTE Configuration CONSTANTS ###
RTE.default {
proc.preserveTables = 1
#denyTags=<o>,</o>
}
RTE.proc.entryHTMLparser_db = 1
RTE.proc.entryHTMLparser_db{
denyTags=o
}

2)Все варианты: (в setup шаблона)
page.HTMLparser.htmlSpecialChars=0
config.HTMLparser.htmlSpecialChars=0

tt_content.text.20.HTMLparser.htmlSpecialChars=0
tt_content.text.20.HTMLparser.htmlSpecialChars=0


об этом есть в списке рассылке:
http://typo3.org/1422+M556c339aaf8.0.html?&tx_maillisttofaq_pi1[answered_only]=0&tx_maillisttofaq_pi1[sword]=%3Co%3Ap%3E

[Valery Romanchev]

Наши победили!!!
решает проблему: dontProtectUnknownTags_rte=1

У меня TS config примерно такой:

### RTE Configuration CONSTANTS ###
RTE.default.proc.preserveTables = 1
RTE.default.proc.dontProtectUnknownTags_rte=1
RTE.default.proc.entryHTMLparser_db = 1
RTE.default.proc.entryHTMLparser_db{
denyTags=o
allowTags=table,tr,td,p,div,img,hr,b,i,u,a,br,pre, strong,em,li,ul,ol,span,h1,h2,h3,h4,h5,h6
noAttrib = h1,h2,h3,h4,h5,h6
}

Если кто сможет что-нибудь посоветовать по поводу методики массового добавления вордовских и Quark - документов на сайт с Typo3, буду благдарен.

[Andreas Schwarzkopf]

Да, много накопал :-)

General Office Displayer -
это расширение импортирует автоматически Word (Office) 2003 и OpenOffice документы.
Правда первая моя попытка прошла неудачно - что-то с кодировкой, одни вопросы отображаются.

[Valery Romanchev]

Это интересно.
Обязательно попробую.
А у тебя стоит Typo3.6 или 3.5 ?
Там в доке написано, что-то UTF-8:
*********************
MS Office 2003
The \".xml\" format of MS Office 2003 is a plain XML document in UTF-8 encoding. All binary data is also contained in the XML document by simply base64 encoding the data (and thus it fits nicely into a markup document).
*********************

[Perignator Temporis]

Да, у меня тоже возникало желание дать возможность заказчику \"отдавать\" системе .doc - файл, чтобы он сам импортровался.. Тоже смотрел это расширение, пришел к выводу, что заставлять заказчика, который понятия не имеет что такое UTF8 и XML так документы сохранять - себе дороже

[Perignator Temporis]

У меня, кстати, написанный выше код так и не разрешил вставку таблиц отчего-то

[Valery Romanchev]

В продолжение этой темы, добавляю свой текст с форума typo3.net.ru (итого нескольких часов работы :-).
Извините, что повторяюсь... но очень хочется чтобы кто-то ответил :-))

********************
Сейчас занимась поиском оптимального варианта работы по добавлению материалов из Word в RTE (при условии, что работает специалист-верстальщик).

Пробуя разные советы и постепенно разбираясь в теме, склоняюсь к выводу, что должно быть какое-то предельно простое решение (несколько строк TS кода... добавить это в FAQ и все верстальщики будут счастливы)

Поправьте, если ошибаюсь:
Что может быть проще:
1)по умолчанию при RTE->DB происходит ТОЛЬКО чистка тегов (с этим более-менее понятно). Остается только включить таблицы и настроить эту самую чистку.
Никакие лишние теги не добавляются, только очищаем. Для эстетов можно добавить замену STRONG на BR (или наоборот)

2)при выводе в FE тоже ничего лишнего в отношении стандарных тегов не добавляем (обрабатывает только ссылки, картинки и прочие специфичные для typo3 вещи).
Стандартные теги управляются через внешний css-файл (верстальщику легко объяснить, где он лежит).
В итоге получаем предсказуемое поведение движка (без вставки тегов p, котрые всё норовят испортить списки, хитроформатировнных списков и прочих вещей, которые сильно затрудняют \"быстрый старт\")
Для специалиста-верстальщика важнее не широта функциональности, а полная управляемость и предсказуемость системы.

Как я понял, пунты 1) и 2) не сделали по умолчанию из стремления обеспечить читаемость кода в RTE и, может быть, из желания угодить неквалифицированным пользователям. Ну еще, чтобы обеспечить работой консультанов по TYPO3
*****************************
Тема интересная...
Похоже нужно сначала внимательно читать всю документацию
У меня пошли проблемы, описанные в
http://typo3.org/1422+M51663f96ae2.0.html?&tx_maillisttofaq_pi1[answered_only]=0&tx_maillisttofaq_pi1[sword]=wrapNonWrappedLines

Как я понял, в базу по умолчанию кладется текст без \"лишних\" тегов p и div (если при них не стоит выравнивания и класса, то вместо них добавляется перевод строки).
При создании страницы эти p вставляются снова.
Какие-то объяснения по этому поводу есть в доке по RTE
http://typo3.org/doc.0.html?&tx_extrepmgm_pi1[extUid]=214&tx_extrepmgm_pi1[tocEl]=472&cHash=38a8ce6a13

Похоже, сделано настолько сложно, что предлагаемый выше простой способ работы всех этих трансформаций потребует больших усилий.
*************************
Как я понял, в трансформациях RTE->DB которые описаны в доке по RТE жестко прошито вырезание \"лишних\" тегов p и div (т.е. тех, у которых нет выравнивания или класса).
И отключить это через TS нельзя.
Поэтому люди изобретают хитрые способы не вставлять потом эти теги при отображении DB->RTE
типа

# вставлено из http://typo3.org/1422+M5b53f7e01e0.0.html?&tx_maillisttofaq_pi1[answered_only]=0&tx_maillisttofaq_pi1[sword]=RTE############################################## #
#remove css attributes for p- and pre-tags
tt_content.text.20.parseFunc.nonTypoTagStdWrap.enc apsLines.addAttributes {
P.style=
PRE.style=;
}
###############################################

###############################################
#no wrapping of RTE lines
tt_content.text.20.parseFunc {
nonTypoTagStdWrap.encapsLines.nonWrappedTag >
nonTypoTagStdWrap.encapsLines.wrapNonWrappedLines = <p>|</p>
}
###############################################

###############################################
# settings for RTE-bullet lists
tt_content.text.20.parseFunc.tags.typolist.default .wrap = <ul> | </ul>
tt_content.text.20.parseFunc.tags.typolist.default .split.1.wrap =
tt_content.text.20.parseFunc.tags.typolist.1.fontT ag = <ol> | </ol>
tt_content.text.20.parseFunc.tags.typolist.1.split .1.wrap =
###############################################


или еще вариант (тоже из FAQ)
#########################
#rte bullet list conf
tt_content.text.20.parseFunc {
externalBlocks = ol, ul
nonTypoTagStdWrap.encapsLines.nonWrappedTag >
nonTypoTagStdWrap.encapsLines.wrapNonWrappedLines = <p> | </p>
}
#########################

Способы эти работают плохо (ссылки в списках не отображаются...)
В общем куча проблем. И все из-за того, чтобы сделать userfriendly
html-код, если юзеру вздумается отключить визуальный редактор.
Как-то это все странно... Или я пока не разобрался?

[Valery Romanchev]

Помоему, правильный путь такой:
1) в TSConfig
### RTE Configuration CONSTANTS ###
RTE.default {
proc.overruleMode = ts_css
proc.dontConvBRtoParagraph=1
}

#это наверняка не нужно
RTE.default.proc.dontProtectUnknownTags_rte=1

#а это наверняка нужно
RTE.default.proc.dontProtectUnknownTags_db=1

#а вот это не работает, поэтому придется патчить
#файл class.t3lib_parsehtml_proc.php
RTE.default.proc.entryHTMLparser_rte = 0
RTE.proc.entryHTMLparser_rte = 0

#это вроде как работает
RTE.default.proc.entryHTMLparser_db = 1
RTE.default.proc.entryHTMLparser_db{
denyTags=
allowTags=table,tr,td,p,font,div,img,hr,b,i,u,a,br ,pre,strong,em,li,ul,ol,span,h1,h2,h3,h4,h5,h6
noAttrib = table,tr,td,h1,h2,h3,h4,h5,h6
tags {
#это позволяет не резать p при добавлениии в DB
p.rmTagIfNoAttrib=1
}
}


2) Что патчить: class.t3lib_parsehtml_proc.php
см. http://typo3api.ueckermann.de/classt3lib__parsehtml__proc.htm
Пока не могу проверить на своем сайте, как проверю, напишу.
по-моему нужно закоментировать вот это (можно ориетироваться по номерам строк):


01190
// Wrapping the line in <$dT> is not already wrapped:
01191 $testStr = strtolower(trim($parts[$k]));
01192 if (substr($testStr,0,4)!='<div' || substr($testStr,-6)!='</div>') {
01193 if (substr($testStr,0,2)!='<p' || substr($testStr,-4)!='</p>') {
01194 // Only set p-tags if there is not already div or p tags:
01195 $parts[$k]='<'.$dT.'>'.$parts[$k].'</'.$dT.'>';
01196

Вопросы все равно остаются: почему сделано именно так, и ведь, главное, не сделали конфигурируемость!!!
Может я не вижу каких-то подводный камней?

[Perignator Temporis]

Сдается мне, UserFriendly HTML тут вообще ни при чем ибо:
1) RTE использует ИЕ для отображения форматирования.
2) При переключении в HTML View просто берется InnerHTML этого ИЕ-куска и показывается как код в текстбоксе. То есть, все, что делает галка - смета visible между текстбоксом и компанентой ИЕ с передачей туда-обратно InnerHTML.

Что касается форматирования ворда...
Вроде бы я решил эту проблему, написав PHP-функцию по документированным специфическим тегам офиса.. В смысле, функцию, для их вырезания (показывать, наверное, не стану - стыдно, все ж я с ПХП очень слабо дружу, C# больше, смеяться станете ).
Оформил эту функцию в отдельный файл, ну и далее в конфигурации:

page.includeLibs.removeword = fileadmin/scripts/removeword.php

subparts.CONTENT < styles.content.get
subparts.CONTENT.stdWrap.preUserFunc = user_removeword

То есть, понятно, что в базу все идет как есть, зато на этапе формирования HTML-страницы контент чистится и пользователь не видит всякой гадости типа XML namespaces, etc.

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

[Valery Romanchev]

Да, насчет переключения в решим Source Code в RTE все правильно.
UserFriendly HTML касается другого:
если включить чекбокс Disable Rich Text Editor, то мы не увидим этих лишних, по мнению Каспера тегов p, div (которые без параметров)