$build_mode = ($page) ? 'full' : 'teaser';
        $node->build_mode = $build_mode;

Full node is not necessarily $page, more than likely it's !teaser; when I set a view to 'full node' I really wouldn't expect it to display asomething labeled 'teaser'. Is this by design, and if so, should this really be by design?

Also, I personally dislike it changing build modes by default here, seems like it should check if the build modes are enabled for the content type in DS if I understand this correctly

Also, the implementation of hook_content_build_modes doesn't declare new build modes. Build modes as
overall
build modes
build mode

for example, to get them to display under row display node, I needed to add on to the nd_content_build_modes 

  $build_modes = array(
    'full' => array(
      'title' => t('Full node'),
      'weight' => -1,
    ),
    'teaser' => array(
      'title' => t('Teaser'),
      'weight' => 1,
    ),
    'sticky' => array(
      'title' => t('Sticky'),
      'weight' => 2,
    ),
    NODE_BUILD_RSS => array(
      'title' => t('RSS'),
      'weight' => 3,
    ),
  );
  foreach($build_modes as $mode => $info ){
    $build_modes[$key]['build modes']['nd_'.$mode] = array(
      'title'=> $info['title'] . ' (nd)',
      'views style' => true,
    );
  }
CommentFileSizeAuthor
#2 655894_nd_cck_bringback_managefields.patch4.92 KBhefox
#2 655894_nd_cck_displayfields_return.patch2.71 KBhefox
#2 655894_nd_buildmodes_exclude.patch4.08 KBhefox

Comments

hefox’s picture

hefox commented
Title: Build node troubles » Playing well with others, build modes

To see where I'm coming from first, Let me describe the module I wanted when I stumbled on display suite. Simply enough, I wanted a module where through a ui and otherwise could dynamically create build modes and assign formatters/exclude, etc. to those. Seemed like display nodes was what I was looking for. Frankly, it's not been the funniest with that whole fieldgroup issue and now this; it seems powerful, but just not playing with others as I thought it would! (I'm guessing I tend to use different stuff, ie fieldgroups and views node row displays?).

The issues that have bugged me:

1) use of content_display_modes; ds doesn't implement that hook which I suspect it should, and as mention, nd is not using it correctly I believe (won't even show up anywhere in the array content_build_modes function creates.
I'd be willing to make a patch, but I suspect the issue is not easily fixed; for example, the storage of the formatters for cck fields for display suites, is it doing the cck way or the ds way (idealy I'd hope for either both or cck)?
2) Doing too much, like remove 'Display fields' pages in nd_cck (instead of something a bit more explanative like redirect or some text), taking over manage fields, taking over all node build modes even if disabled for content type, etc.
use of 'full', 'teaser';this build modes already exist (node_content_build_modes) and are producing conflicts (ie why I added nd above in my nd_content_build_modes altering).

I'd be willing to try making patches, but after discussing these a bit to define if what, if anything, would be desiring a change. I'm quite interested in the module

hefox’s picture

hefox commented
StatusFileSize
new 655894_nd_buildmodes_exclude.patch4.08 KB
new 655894_nd_cck_displayfields_return.patch2.71 KB
new 655894_nd_cck_bringback_managefields.patch4.92 KB

Hello again,

After thinking about it again, and talking it to some others, I'm really interested in getting this module to work for me and others, while keeping it's current features ... but making it work a bit more with other modules/ways of doing things?

Here are three patches I made so far.

The first is to bring back the manage fields draggable; I could never figure out why that was overriden as it was, since it made it quite hard to manage the node forms and wasn't adding any functionality. (against nd_contrib)

The second patch is to bring back display fields and add in redirect to the equivalent display suite page only if the context is enabled for that content type. (against nd_contrib).

The third patch is
1) to add a new context/build mode, "Node page"; right now the module is treating ANY node not as $page as a teaser, which is not correct n that full nodes can be in listings and displayed elsewhere. However since the title is now a field, it brings in the need for the third display, node page.

2) declare build modes like seen in other implementation of hook_content_build_modes with the two levels for 'tabs' and 'flat'.

3) Change the build modes/contexts to start with nd_ to prevent name collision with node_content_build_modes

4) tweek the logic in node_api to not run when build mode is excluded from running on the content type or build mode. For build mode normal, the logic checks for page, full, or teaser, and changes if respected build mode is enabled. I understand that exclude is still suppose to change the build mode, however there are likely modules checking for the build mode so there should likely be a ways to completely exclude ds from effecting nodes.

Patches were done along with patch in #582618: Incompatible with fieldgroups, don't think they'll effect it other than line numbers.

Some patches/changes that I also would like:

1) Custom added build modes via the ui appear as content_build_modes if they don't already, but being that I could not find a ds_content_build_modes I think they don't.

2) A way to completely disable nd's supplied build modes, so doesn't appear anywhere but a config form for some content types would be nice; no reason to see sticky, rss, full, etc. if not using those.

3) Removing some of the view code may be possible; use of 'build modes' in the hook allows for the build modes to display under build modes when configuring node display.

4) Dealing with items in content that have been added in by other modules but don't have a corresponding field. From what I can tell, the solution was on the theme level to allow for themes to not call the preprocess for node. ...I don't want to have to do that to get my advpolls, views attach, etc. working so I don't see others doing it without reluctance either. Perhaps the better solution is to acknowledge them; only remove parts of the node->content that one is using like have nd_cck fields remove cck fields, etc., and make the actually display suite content part of the node content, with a weight, etc. instead of gathered in preprocess. This is a major blocker for me since it prevents easy integration with many modules.

5) (bug) No default tab causing empty link/tab on display suits list of build mode display settings.

I've opened a patch in CCK about the lack of configurable labels for non-basic build modes #658474: Configurable Label per build mode type instead of just basic, if thee agrees that it is a nice feature request, it'd be nice to have support (neglected issues afterall tend to remain neglected, I believe) assuming it's not flat out rejected for some reason :>.

cpelham’s picture

cpelham commented
Title: Playing well with others, build modes » fieldgroups

What would be the most flexible and therefore desirable functionality IMHO would be to allow separate and different grouping and display of fields on node edit and node display. To accomplish this, I would think you could reinstate the drag and drop on the manage fields screen (as I believe the first patch above attempts), while still allowing the separate organizing of fields for display on the display fields screen using the added functionality ND module provides.

Otherwise, we achieve somewhat greater control (and ease of control) of node displays at the expenses of having more ugly and less controllable node edit forms, which no one wants.

hefox’s picture

hefox commented
Title: fieldgroups » Playing well with others

Looks like I'm not the only one that got confused when manage fields got undraggedable. I still haven't figured out why manage fields was made undraggable since it is needed to manage the form (didn't see any relavent comments).

Changing the title again cause 'fieldgroups' isn't what most of the topic has been about, though it is part of it. What I've been trying to address is that in general while this module is interesting and powerful, it is over-doing some things making it very not fun to play with, which is what my patch have been about.

Having a grouping functionality other than regions, that has a label and configuration, should probably be a separate feature request for nd_contrib; however having just general support for cck fieldgroups, which it does not other than perhaps making a custom field, could perhaps be addressed in issue about fieldgroups, #582618: Incompatible with fieldgroups.

swentel’s picture

swentel commented

655894_nd_cck_bringback_managefields.patch has been committed, I'll review the other patches later!

hefox’s picture

hefox commented

(Cool :>.

After playing around with ds/nd, I made a module based on what I found that I desired as generalized functionality, specifically changing build modes based on some conditions, (which nd currently does but without much configuration). the module is here http://github.com/hefox/buildmodes with the specific module being buildmodesswitch, which uses hooks and/or ui+variables to determine whether to switch a node to a different build mode (or at least it should, haven't tested it much; and the ui is extremly basic) Mentioning it as an example of what could be done instead of the current nd_nodeapi switching).

swentel’s picture

swentel commented

BTW, as for why the manage fields screen initially was taken over (at least by nd_cck) was because of this module: http://drupal.org/project/nodeformcols . We fell so hard in love with it at work that we thought it was usefull to remove the drag handling on the manage fields screen. However, not everyone uses that module of course - and can't handle fieldgroups either at the moment. Anyway, that issue is out of the way in both branches :)

The buildmodes module from #6 looks cool, although it looks like a bit overhead to me right now - but that happens always when I take a first glance at some code, I'll review it more later tomorrow and the next couple of days to think about the whole 'build modes' problem which has indeed some annoying problems (although the $page / $teaser problem can be easily resolved in one line and keeping the current code)

I also reviewed the 655894_nd_cck_displayfields_return.patch. I like the approach, however it brings up 2 problems so far:

  • clicking on a display for a content type with no fields also triggers the 'There are no fields configured for this content type. You can add new fields on the Manage fields page.' message. This might confuse users imo because on the display screen they'll see a lot of fields there.
  • There are a lot of build modes for cck now (you can see that nicely with admin menu) and not all of them redirect to the right spot on the display suite display fields form.

so how about this: lets keep one display tab per content type which simply gives a message a la 'The display of fields for this content type is handled by Display Suite' and a link to it ? The logic for excluding build modes can be handled by DS then and not here - you can do that already at admin/ds/nd/buildmodes in the matrix form and it's probably more interesting to not show them either as a tab, but that's for the build modes discussion :)

All right, it's late, need sleep, more later!

swentel’s picture

swentel commented

Will finish this issue this week - adding reminder to myself to add build modes also to exports and features

swentel’s picture

swentel commented
Status: Active » Fixed

Marking as fixed.

- If you completely disable ds for a content type, the display fields from cck is back.
- If ds takes control over a content type, the display fields is back but will redirect with a friendly message.
- nd (and all other implementations of ds) now implement hook_content_build_modes like cck wants it.
- label support is also in (from another issue)

We're pretty pleased with what we have now, a release will be out pretty soon!

Note: all this is committed in ND 6--2 branch, we're leaving the first branch completely.

People who want fieldgroup support, take a look at either our roadmap (for release 1.1!) or #582618: Incompatible with fieldgroups

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.