[TYPO3-ttnews] Ext:news – some content related questions

Georg Ringer typo3 at ringerge.org
Wed Jan 9 14:34:23 CET 2013


Hi,

I hope I can answer everything.

Am 09.01.2013 14:22, schrieb Thomas Skierlo:
> 1) Is there any disadvantage in not using the internal „Text“ input of
> news at all. I would prefer pure standard content, which might include
> own content elements, like sliders, tabs, accordions and so on. Tried it
> this way, and everything seems to be working properly. But maybe with
> some caveats?

no disadvantage. I prefer the bodytext because editors do too many
stupid things with content elements which can look ugly pretty fast.

If you need it, fine, use it.

> 2) If not, wouldn't it be a great idea to get rid of the element? It
> doubles the work needed to integrate things like lightboxes and
> galleries, and it encourages users to use rte images, which probably
> will never be able to be responsive. Relying on pure standard content
> would probably ease further development a lot.

you wanna remove the bodytext field? Do with with tsconfig, user rights,
TCA in custom extension but it will stay within ext:new.

> 3) I'm working with a Twitter Bootstrap grid to get responsive features.
> Therefore things like
> „plugin.tx_news.settings.detail.media.image.maxWidth“ must be
> „responsive“ too, depending on the placement of the plugin. „maxWidth“
> doesn't seem to offer stdWrap, so it is getting rather complicated to
> get it to behave dynamicly. Is there a way to achieve this, or to
> reference site wide settings, like „styles.content.imgtext.maxWInText“,
> „styles.content.imgtext.maxW“ or „styles.content.imgtext.linkWrap.width“
> instead of hard-coding identical values into the detail view?

I doubt that you can access styles. in fluid but this is not a problem
inside ext:news. What you of course could do would be to use a custom
image viewhelper and get the TS there without any problem

> Currently all this is possible with ext:news, only in a pretty complex
> way. Imagine you want one image to be placed as a teaser image above the
> teaser text (whole width of column), and you define the first one of the
> media-relations stack to be that image, you will need 4 nested if
> clauses in your template to isolate it from the rest. 

then you would use the checkbox "show in preview views" or you would use
{newsItem.firstImagePreview} or you would use a custom VH to get what
you need.

> To render the
> remaining media files underneath the article you will even need more if
> clauses, since you have to get rid of the banner image. 

custom VH or you would use {newsItem.nonMediaPreviews} to get those not
flagged with "show in preview views".

> Besides that you
> must define the first media object used to be of banner-type to get this
> working – which means, if you don't want to use a banner for an article,
> you have to insert an empty media image. Try to explain this to an
> average editor. Wouldn't it be much easier to add a distinct teaser
> media field which is independant of the current media field? It could
> offer own width and height settings and would ease the job for editors
> and administrators a lot.

and in all other uses cases there would be a field you don't need.

The extension will never cover all use cases. If you need more fields,
just add them and use those. I currently see no benefit for most of the
users.

> 5) Last question: If I remember it right the old tt_news allowed
> pagination in detail view too. Tried it once without big success. It was
> not very stable. I'm currently writing articles which are more that 20
> A4 pages long. Are there any plans to offer pagination for articles in
> future?

talking about git version of course: there is one:
<n:paginateBodytext />

> Besides all my questions. Thanks for this extension. Keep up the good
> work. I've learned a lot about Extbase from ext:news.

thanks!

Georg


More information about the TYPO3-project-tt-news mailing list