У поста есть свойство content, когда ему присваивается значение например $post->content = 'текст моего поста';, то происходит очень многое, а именно: текст фильтруется - замена переводов строк и прочее, разбивается на анонс и основную часть, разбивается на страницы - если есть соответствующие теги. В результате в массиве $post->Data content равен фильтрованному полному тексту поста, rawcontent - оригинальный 1нефильтрованный текст, excertp - анонс, description - для соответствующего тега в секции head html, moretitle - текст ссылки далее, pages - если есть страницы, то это массив со страницами.

С другой стороны, в шаблонах используются эти свойства, например свойство content возвращает не то, что содержится в $post->Data['content'], а следующее: перед и после текста вызываются события TTemplate - BeforePostContent и AfterPostContent, и если есть страницы, то соответствующая страница. Конечно, если никто не обрабатывает события и нет страниц, то возвращается content.

Это я все к чему? Да к тому, что свойство content не соответствует значению в Data'content['], а иногда надо достучаться именно до массива - это можно делать напрямую, но это идеологически неправильно. Мной была придумана подпорка для этого - свойство outputcontent. Сейчас я задумался - такое разнообразие контентов даже самого меня иногда путает. А сейчас я начал продумывать структуру бд, и естественным образом всплыло поле content - а нужно ли вообще придерживаться этого? Думаю назвать это поле filtered и тоже самое сделать в Data, чтобы было однозначное разделение между свойством content и фильтрованным текстом. Для блоголёта сейчас это можно сделать в очередном апдейтере: загрузить все посты и сохранить их по с новым значением, то бишь переименовать content в filtered - разве что памяти это поест много, и может не отработать за один раз.

И еще до сих пор не решился переименовать часть переменных и полей в нижний регистр (взять тот же самый Data).