Using the latest snapshot of profiler and the profiler_example, there's no (obvious) way to define content types.
The original way was to created the content type in the install .profile file, but this seems counter to what profiler is meant to do.
My guess is to use a Feature. This brings up an interesting problem. Does every install profile using Profiler have to define it's own feature for Page and/or Story content types? I would hate for there to be ten different "Page" Features for ten different install profiles that just end up confusing folks. Can Profiler at least define the Features that replicate Page and Story from the default install profile? Can the default install profile be used as a "base" in the .info file?
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | profiler_api.patch | 841 bytes | redkilian |
Comments
Comment #1
redkilian commentedWell, I took a stab at it and added the functionality to add content types from the .info file. Attached is a patch(hopefully in the right format) against head. If this gets accepted, some additional documentation will need to be added.
Thanks
Comment #2
q0rban commentedHi there! Sorry for the delay in responding. Thanks for the patch! :)
You've hit it on the head though. Since Features already handles node type creation, we decided not to re-implement this functionality. I see your point though, so I'm going to leave this open to let others give their opinion. Thanks!
Comment #3
Grayside commentedProfiles need default types and not everyone is using Features.
In the specific case of Node Types, all Features is really doing is generating a hook_node_info() implementation for something created with node_type_save(). In fact, Features is looking for excuses to do that for any node type in the database that is not already defined in code. That means that node types defined by the profiler in this way will probably be exported as Features when someone builds a feature with close ties to one of these content types. Most of the time this does not matter, except to be aware of it. The remaining minority of the time, this can be fixed by altering the 'module' line in the hook_node_info() generated by features to read 'node'.
Setting to Needs Review since there is now a patch.
Comment #4
redkilian commentedAny chance this makes it in?
Comment #5
q0rban commentedNo, sorry, we need to get a patch that fixes it so that Features node types are available in time. :)
Comment #6
q0rban commentedWhoopsie, I think I got issues confused. I was thinking of the role creation issue, not the node type creation issue. I'm going to let yhahn weigh in on this issue.
Comment #7
likewhoa commentedsubscribing for now and setting as task.
Comment #8
Grayside commentedGiven that this is an issue with a patch, it's probably a feature request.
Comment #9
redkilian commentedGiven that yhahn hasn't looked at this, I am unassigning it from him, and would ask for others to apply and test.