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.
The is no compelling reason I can see for restricting the handled node type to 'g2_entry'.
define('G2NODETYPE', 'g2_entry');
If we proceed to use this module to handle our highly customised Definition node type, which contains a LOT of data already, we currently have these choices:
- Mimic our Definition type into G2 Entry, and then use Node Type to convert them all (which I might be able to automate a bit).
- Intervene in the G2 Glossary module code and set it to use our 'definition' type, which works like a charm, you are welcome to view it running at: http://ppi.webel.com.au/g2/initial/c (development site, temporary only)
Obviously for now I'm taking the last one :)
Comments
Comment #1
fgmAs you noticed, there is no real technical reason in 6.x for maintaining this restriction : this is just an heritage from the 4.x versions of this module, at a time when CCK did not exist and there were many more node modules like this one than there are now. The specific fields added to by the module can easily be replicated with CCK fields.
I plan on making G2 node-type agnostic for D7 thanks to fields now being in core, but not do it on D5/D6 myself unless there is customer (i.e. paid) demand for that port, which I doubt.
HOWEVER... if you already did that port yourself, as you seem to imply, I have no objection to creating an experimental 6.2 branch with your code for this feature. Would you maintain it ?
Comment #2
webel CreditAttribution: webel commented> Would you maintain it ?
I'll think about it.
Comment #3
fgmOf course, this would mean a number of changes, but off the top of my head, I think the most significant one would be switching from the base node hook implementation to their hook_nodeapi equivalents.
Comment #4
webel CreditAttribution: webel commentedread.
Comment #5
fgm@webel: any news since february ?
Comment #6
fgmNo answer in almost two months, assuming negative. Bumping to next version: this is definitely something I will consider for 7.x.
Comment #7
fgmBumping to 7.x now that the branch is opened. Details about this issue at http://wiki.audean.com/g2/choosing
Comment #8
fgm8.x-1.x is now the active branch. Bumping.
Comment #9
fgmThis is the first new feature planned after the actual port from D6/D7 releases.
Comment #10
fgmProgress note: in the D9/D10 8.x-1.0-alpha1 version, the node type is now a constant wherever it appears (or it should be: if not open an issue to fix it).
This will make it easier to support other bundles as a replacement for
g2_entry
. At that point the main hassle will be the configuration, which has to be aware of the bundle to create fields on it, meaning whenever/if this is introduced, all relevant config will have to be generated by code instead of a simple config import.As to supporting other entity types, there is really no point and a lot of the logic depends on the
NodeInterface
property, so that one will be a won't fix AFAICS.