I would like this functionality so that I could allow users to create a child content type of my choosing from another content type, possibly through a simple link. As a field for cck, this could allow a person to quickly add this to all pages of a certain content type.
The action would not need any of the options for the user, just essentially send them to the content page with most fields completed.
So, I'm wondering, is such a thing possible, and how much of a security risk would there be?
Comments
Comment #1
alan d. commentedThe module will limit users to only access the content types that they are allowed to create. The first step does not save any content and the second step is the standard node form with the node prepopulated with the values.
The format is limited to what the user can access, so this can not be overridden. If no menu rights are set, the menu is set to whatever the administrator has set it to (if anything). This could be a considered a slight risk.
I was thinking about creating a block to embed the form, this would eliminate the first step, speeding things up a bit. On the link idea, the two forms are separate, you could create a link to the second form with custom parameters. This could be embedded in any page. Or automating the addition of a standard link (like "Add new comment") could be better to a CCK field.
Just some food for though, but the block feature is definitely next on the list!
Comment #2
Trunkhorn commentedThat sounds excellent. I'm excited to see where you'll take this.
Comment #3
alan d. commentedThe latest commit has the block form code added. I'll create a page with configuration details soon.
Comment #4
alan d. commentedSince creating a CCK field to present this info is quite restrictive with moderate overhead, I'm not going to implement this.
The format of the links that pre-populate the node are not restricted to a form submission, so custom links that use the following format can be used to mimic this.
?q=node/add/[CONTENT_TYPE]/crc/[RELATED_NODE_NID]?name=The+new+title&menu_parent=2
You can create these anywhere, but I'd avoid placing them where they are shown to users that do not have permission to create the content type. They will get a 404 otherwise.
node/add/[CONTENT_TYPE]is the standard Create content link - remember that underscores are replaced with hypens, so crc_test would have the linknode/add/crc-test.[RELATED_NODE_NID]must exist and be a node nid that the user has access to. If they don't have access to this node, they will also get a 404 response.The only query parameters that core module generates, are name and menu_parent. The name is the title and possibly the menu link title. The menu_parent is one of the following keys:
Marking closed, but the links and programmed CRC profiles are on my todo list for this module. See below.
Future enhancements
I am considering the following links, one per content type, all disabled by default:
"Add new %type"
These will be added to the links array, just like "Add new comment", etc.
The problem is with the menu title. This is only populated if the name parameter is set, according to the menu selector options. If the content type requires a menu link, then the option would really need to be set as "Custom" with a token menu link title set.
FYI, the programmed CRC profiles are going to be a way to define default content type profiles. The two that I'm going to build in are Development and Production. For example, for the body field, the Development profile would have "Lorem ipsum" enabled, the Production version would have the body field default set to empty. To keep things light-weight, this will only be able to extend it by custom coding, with a simple API.
Comment #5
Trunkhorn commentedI'm beginning to realize why this hasn't been implemented the way I imagined it before. It is a real shame the node id can't be abstracted for a more universal link. I think using the functionality as a link in a block can work for me if only I could use a token for the node ID when the block is displayed, but I don't know if that is possible for blocks. I guess I should look more closely and see if you added token access for that new block form you committed.
I really like seeing this forward vision, and thank you for sharing it.
The only other thing I could possibly suggest at this point is to have a custom body field. Sometimes I might have a specific definition list with a structure that could carry over to many pages, where I'd only want to change minor distinctions for that node. I haven't fully tested your latest version yet, so don't know if you've already added such a thing.
Comment #6
Trunkhorn commentedWould you have any suggestion regarding my problem outlined here:
http://drupal.org/node/429466
Basically, I'm trying to use the cutom links module to use nid tokens in that link for crc but it's messing with the
?q=part of the link by encoding it incorrectly.Comment #7
Trunkhorn commentedI should also mention that the custom links module code would be a good complement to the two versions of crc you're considering creating. By putting those links in blocks with the token ability of the custom links module, the only thing that would be left for me to do is make a php block visibility argument that would onl show a link to a user if they are the author of the page they're looking at.
Comment #8
Trunkhorn commentedI thought it might have been the transliteration module, but when I disabled it, custom links still seems to have done it itself.
So, Since I'm using auto nodetitles, and have dumped menus in favor of taxonomy, I redid the link for use in the custom links modules so it wouldn't have those characters giving me problems.
node/add/content-type/crc/[nid]I believe that will do well for my current purposes.
Comment #9
IgD commentedSubscribed
Comment #10
superbuller commentedsubscribed