Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This is an oldie that I remember really bugging the crap out of me before I got used to the way things work... thanks to merlinofchaos for bringing it up again. ;)
On a typical site, it's feasible that you want to make certain node type settings the default for all content types unless otherwise specified: for example, disabling upload.module on all but "file" nodes, or not publishing anything to the front page other than "blog" nodes. Because the node type form always takes its defaults from the arbitrary pre-defined defaults in whatever module, it's impossible to do this, so you invariably end up missing a couple here and there and having to back-track. Annoying.
So let's provide the ability to set those node type options in one place globally (I'm thinking admin/content/type/settings), and have the other node type forms use that unless otherwise specified.
Comments
Comment #1
webchickThe only way I can think of to do this is to re-introduce something like hook_nodeapi op settings... and use one of the params as a $type op which indicates whether we're addressing the 'global' settings or the 'per-type' settings, so that it knows where to pull the default values from/where to save the value.
This op was done away with in 4.7 in favour of hook_form_alter. Which mostly makes sense; it's just a form after all. However, node_type_form does one very distinct thing, which is to actually create/edit a node type. All these node type options coming from other modules just get slapped onto the end of the form; there's no separation between "this is stuff we need to actually build the node type" and "these are options we want to happen to all nodes of this type."
Any other thoughts here are welcome.
Comment #2
webchickActually, better would be adding the settings op to hook_node_type. However, this feels dirty, because it's introducing yet another way/place to alter forms. Hmmm....
Comment #3
mlncn CreditAttribution: mlncn commentedUpdating version. Worth looking at again after Remove $op from hook_node_type lands.
Comment #4
sun.core CreditAttribution: sun.core commentedComment #5
webchickNot sure why that was assigned to me. :)
Comment #6
peterx CreditAttribution: peterx commentedThere is a need to create default settings for modules that create several types. There is a need and several issues requesting the change from a default of published to unpublished. I was about to contribute code to the published/unpublished issues and thought this issue could be a better starting point for many content type definition issues.
The defaults for a module could be set in the module.info file. I created a module to do this many years ago and finally published the D7 version: http://petermoulding.com/content_type. The same code could be used for the site wide defaults.
The old code has default settings for the module, something that could be moved to the D7 version. D8 could have a site wide .info file to be read during the installation to set the defaults site wide. There would then be a consistency. site.info then module.info then content_type.info. Whatever is not set is inherited.
The D7 version can handle everything except site.info. The D8 version could handle site.info. While the code would not be backward compatible, the content type definition files could be backward compatible.
The text files would be very easy to edit and to version control. They are read only when you switch on a module. Theme developers are already familiar with the format of .info files. If we remove the need for a module.module file in a module, a content type module could be a single .info file and the file could be created by someone who has never written PHP code.
My code allows for content types stored in separate files with any name. If you want to keep .info clean, the only addition needed is content_type[] = file_name.
Comment #18
quietone CreditAttribution: quietone at PreviousNext commentedThis can now be done with the configuration management system. I am closing as outdated.