Default settings options per content type

I'll definitely second this feature request but in addition to defaults, I'd like to be able to limit the number of choices available on the node creation/edit form.

Content authors understand the concept of child/sibling but they often simply do not know which setting to choose.

In case anyone needs this feature for Drupal 7.x.
I patched against 7.x-1.0.

The patch adds a configuration page under the "content authoring" section of the administration page.
You can provide default title, display and weight settings for either submenus or siblingmenus.

I've also thrown in a bit of help text at the top of the page.

I'm new to module development/git/patching, so let me know if there are any problems.

There's still a lot of old code and Drupal 5.x/6.x terms used throughout the module, so I've attached an updated patch.

Patch changes:

Coder review of entire module - fixed formatting and naming issues
Removed old Drupal 5.x upgrade code
Renamed old terms and updated paths to meet D7 standards (primary links -> main menu, nodes -> content, etc)
Rewrote readme.txt to better explain the module and document some features (new default configuration options, what is extended main menu links, etc)
Removed changelog file as it was outdated and changes can now be viewed using the "view commits" feature on Drupal.org

I can split these updates into separate issues and patches if necessary.

Hi,

Sorry. Submenu tree is in maintenance mode and I don't really have the free time to add new features.

Now that #1297928: Create a configuration form to hold future settings is in, this is back under development.

And a patch that adds the missing options to the configuration form and makes Submenu Tree use the default settings options if no other options have already been set.

Committed to 7.x-2.x-dev.

Hmm, I appreciate this - but unfortunately this is just as annoying as having no default configuration because if I select the defaults now, I would still need to unset the submenutree for content types that don't require it :(

Would it be possible to move the configuration to the edit form of the content type - that's where this really should be, next to the configs of all other content type settings.

Cheers

Thank you for your input.

Attached is a patch against 7.x-2.x-dev that implements default submenu tree options per content type.
Can you test the patch and provide feedback?

Committed to 7.x-2.x-dev.

Sorry I didn't have time to test before - but this doesn't really work.

The settings I set for my content type seem to be transfered to the nodes of that type, but only seemingly. There are two issues that I can spot:
1. The subcontent is not actually displayed, even if enabled
2. When I go to edit the _node_, no matter what I settings I select for subcontent there, these don't appear to be save - if I save and then go back to edit again, the default content type settings seem to be restored again, at least in the form.

Cheers

There is a problem with the patch that I posted above, which I corrected in another commit (after committing the above patch).

Can you test again with the latest development release?
I did have the problems that you mentioned but I haven't been able to duplicate any of the problems when using the latest release.

already using that I'm afraid.

I notice that there is an update function in the .install file now, though when going to update.php Drupal said there was nothing to update - are you sure it's defined correctly according to D7 syntax?

Okay, I finally reproduced this and tracked down the cause of the problem.

When editing a node, a check would be made to see if the node had sub/sibling content enabled/disabled. If the node had no sub/sibling information then it could be assumed that a new node was being created and should use the defaults provide by the node's content type's submenu tree default settings.

This should have worked, except that submenu tree is set to delete all sub/sibling information if a node did not have any sub/sibling content enabled, instead of simply marking that the node had sub/sibling content disabled.

Long story short: content that had sub/sibling content disabled was appearing to be brand new content.

The attached patch should fix the issue.

will this also fix the issue of new nodes created for a subcontent-enabled content type not actually displaying it? (if you were able to reproduce that)

Okay, committed to 7.x-2.x-dev.

I'm going to mark this issue as fixed. If default options per content type are working but you are having another issue, please create a separate issue outlining the problem(s).

Thanks again for the problem reports.

Feel free to reopen the issue if default settings still aren't working correctly.

nice, seems to fix both bugs.