I would like to suggest some improvements on field display options itself, if it is ok, swentel. The display suite module is a huge attractor for d7 and thanks for this big contribution! But let me say, dispite of the option to use custom code fields, there are some deeply needed things which are still not available by even none of the modules handling field values and its output by default. A theme developer still can't get "deep" enough in modifying the semantic markup of a field without using custom fields or template functions. If that bothers already on views and on semantic fields, some of the limitations can be easely pulled off by some small changes in the standart body field display options, links field display options and an addtional choice, cutting more off than "reset". Let me go deeper here: ...
One problem seems to be the <p> tag on the body field, which seems to be bugging sticky, even by resetting all the hell out of the field with any of the mentioned modules above. My hope lies in Display suite now. But even your field display option "reset" seems not to be a complete reset. It seems to clean up all extra surrounding divs, which is great but sometimes not enough. Maybe there should be another preset, called "value only"? Just asking. It is all possible by custom fields with tokens anyway, but ...
Maybe another small and much faster work-around for that would be: adding a css class option to the "reset" display, so that resetted link (a-) and p- fields can get a individual class on the <a> tag and the body text on the p-Tag. That would solve many many problems with one hit. For marking up a clean and lean teaser with having author, date and read more inline with body text without extra div's should be a major need of a theme developer of serious sites. But for that I need to reset all fields and its tons of divs. But resetting all the fields would leave no css class for margins, paddings and floats inline of the text, containing content of more than one field. I am not sure if I explain well. But you can see the tryouts on our testing page http://d7trail.maroqqo.com
Another point is "even/odd" field options for multiple value fields or lists like in the module "semantic fields".
Finally let me say: ds is the best solution for styling content pages and content lists or single node pages. And it implemtents better with the existing drupal logic of your site than by trying the same with views, for example. Views becomes now more useful for other specific cases. With views you start from scratch to design the db queries and its ouput, which is not needed if you just want to design the output of existing values. The regions options of display suite is a BIG BIG improvement of possibilities and very very drupalish! Congrats to that! And views doesn't really has a straight solution for filtered content by terms with clean path management. Than it becomes really complicated. thanks for ds!
Comments
The <p> tag comes from the
The <p> tag comes from the text format on that field. You can configure text formats to not output those tags for instance, that's not something that DS aims to do: it renders the fields in different positions (and with other wrappers if needed), but it won't touch the actual value itself.
Sorry for missleading on this
Sorry for pointing to the wrong spot to change
<p>, Swentel. My brain seems to become exhausted when I work too much all thru' the nights. :) You're right of course. The paragraph is a prevered surrounding html element for text in most cases and should not be touched anways. And of course it is already in the #markup value given to ds. I was totally off the road this night. The problem that brought me on the missleading street of disaster was the behaviour of p tags if you try to get a dynamic box from a field placed somewhere in the middle of body area. It has driven me nuts until I came back to the basic facts about the when and the why of "p" tags being here. head on table OF COURSE IN THE #MARKUP VALUE.Thats why I came back. I wanted to correct my topic, but than I saw your kindly explanation. I think you are entitled to laugh at me now. :)
Ok, let me be more constructive and positively helpful. I thought about a "Display Suite" - like solution on this mentioned idea above and came to the following: (Just to show the basic structure of what it should make ... )
<?php$occurance = $setnumber; // token number from choosen settings
$arr = explode ("</p>", $content, $occurance);
$arr[2] = $incontent . $arr[2]; // a new region in the middle of our long text field
$content = implode("</p>", $arr);
?>
I know this is basic php and could also possibly be put in a preprocess_function in template.php. It is just an idea. And if you ask me, it is more modular if it sits in ds than in theme functions. The parameters for that could be limited occuring if field is a long text field under Field display "expert", with an additional option, which
<p>tag should be used and an error-handling if the numbered p tag which was choosen, does not exist in the value. Splitting it, would create another region to place a field in. Not sure how do to this in ds. I should definitely look deeper in your code to be more specific and helpful on this. But maybe somebody else could point me to the right place in code?I would provide a patch of course ...
http://maroqqo.com
So you want inside the node
So you want inside the node body a new extra region, am I correct ?
... in a sort ... yes
But I am still not sure if the way how I think of going makes really sense. It all comes from the problem, that it is still impossible to have cross browser compatible inline-blocks and floating boxes inside text areas made with css allone. Another option maybe is using body field with unlimited values to finally get in between paragraphs somehow.
Maybe here is a better point to start from? Let's think of a magazine crew of editors and the problem that every article should have a small infobox floating around in the middle of the article text.
There are 2 problems coming up.
1. First: the editor does not know much about html/css and float left/right to put text in the body meant to be the infobox, and editing only the infobox can mess up the whole article accidently later.
2. And second: The infobox cannot be hidden for certain views, or can not be listed allone. In other words: the strength of custom fields cannot be used here.
The possibility to mark the - let's say - third bodytext value/instance as "infobox" or whatever you want (maybe a css class tagging checkbox like in ds Field display?), would make it possible to stay in the flow of typing an article and infobox in a good overview just with two clicks and still with the same field. Dave Reid has a very promising module called field injector going nearly this route. But it isn't compatible witn ds in points of render $content. So it shows up twice on the end. One time on the wished postinion injecting after a given number of paragraphs and sadly another time on the position it sits in the display fields dialog.
Any other idea for getting it done? This could may be a good addition to your new Display Suite node forms project? (which is awesome by the way!)
http://maroqqo.com