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.Hello there! I have a few feature requests which could end up in paid jobs proposals for a production site.
I need to know from you Nedjo, author and maintainer of the module, whther you accept such developments (and which ones under which conditions) or if you'd accept/prefer the development of a new module based on yours.
And by the way, if you do some coding, how much would you ask for for each of those following feature requests? If you're not interested or we cannot afford it, I'll post an offer in the paid jobs forum, considering yours wills as the author.
1- A term display CCK hook
I already posted this feature request in two places:
- http://drupal.org/node/210814 Don't hesitate to ask if too confused.
- Useful and sufficient abstracts (rewritten from #210814)
I've been looking for a feature displaying taxonomy terms as CCK fields for a while. Now I get the point that the great yet underdevelopment term_display.module could make it.
This new feature would indeed allow much more flexibility, granularity, and great user-friendly advanced design options. Such as precise weighting and display options of taxonomy terms anywhere within the content (node, views, panels and more). Think about the ability to weight your terms in the "display fields" tab of your node-type edit page, along with your CCK fields in one single place!
Just managing content right there admin/content/types/nodetype/display instead of switching from there to the different vocabularies (and other content type) edit pages: admin/content/taxonomy/edit/vocabulary/vid
By the way, gathering the content types (CCK, taxonomy, etc) display settings into a kind of drupal core page for each node type could be a great new feature for drupal. If not yet implemented in d6, why not suggesting this for drupal 7?
(...) tons of related modules could benefit of this term_display.module new design feature... that is to say extended to any of the CCK, views, panels and any other content_management.module... and of their related's! Total control!
I guess that this feature would consist in the implementation of a hook for CCK and therefore in a quasi-complete rewriting of the code. Isn't it?
It might lead as well to overrule the taxonomy.module in a way for having per-nodetype weighting capabilities for vocabularies, but it doesn't seem to me as a major issue, as term_display already makes it.
2- A few more theming options
2.1- Display term without link:
- useful to lighten database and worktasks by entering terms once for all into vocabularies and avoiding redondant tables and data acquisition such as with the content_taxonomy.module (yet great for what it does!)
- auto-populated CCK-fields-like terms!
2.2- Display terms from different vocabularies inline
- 2.2.1- user selected vocabularies
- 2.2.2- with or without label (themable?)
- 2.2.3- Is it possible without a new CCK rendering theme/development? cf.: Label display in the edit/nodetype "display field" tab
2.3- Display term with default theme for CCK
- Removing the space-line
- Optional if commited as a node type "display field" option in admin/content/types/nodetype/display
- Optional if 2.4 Advanced theming implemented
2.4- Advanced theming with style sheets
- If no CCK hook: CSS file for advanced theming.
- In case of CCK hook: Kind of smart downgrade feature for sites not using CCK module
Comments
Comment #1
doc2@drupalfr.org CreditAttribution: doc2@drupalfr.org commentedErratum: For 2.2.3 I meant:
Comment #2
doc2@drupalfr.org CreditAttribution: doc2@drupalfr.org commentedComment #3
nedjoHave you evaluated http://drupal.org/project/cck_taxonomy? If so, what is missing? Would your requests fit better as feature requests on that module?
Comment #4
doc2@drupalfr.org CreditAttribution: doc2@drupalfr.org commentedThat was my first choice. CCK_taxonomy is a great tool. But in some cases I need the linking features.
My problem is that a node "tagged" with a CCK_taxonomy term doesn't benefit from this taxonomy features (and some others that don't clearly come to my mind but at least one in relation to the use of views and arguments, and one about redirections PLEASE SEE NEXT COMMENT)...
...Unless we enable the corresponding vocabulary for the content type. But then sometimes both the CCK_tanomony and the taxonomy modules are enabled at the same time for the same content type. As such, choosing one term from one module doesn't autoselect the term for the other. And that could turn out as a data acquisition security issue for my site. A problem firstly because of the great number of data to enter in my nodes and the distance between those related "fields" in the node add/edit page. And secondly because database efficiency, I would have favourished the use of existing tables...
About 1- A term display CCK hook or related features requests:
... But I guess you're probably right, I could make it with Taxonomy and CCK_taxonomy. I've already reorganised my nodetypes and therefore a better combinaison of the two modules should allow me to get my features. I'll have a deeper look into those features issue.
Moreover, considering:
- your point up here,
- your answer there http://drupal.org/node/210807#comment-722625 about drupal 7 core features, to my questions over the eventuality of 1- A term display CCK hook or a dreamed new taxonomy.module API, and
- what follows down here about design,
... I switched this issue (while not sure if all completely correct):
- from "Code" to "User Interface"
- from "Active" to "By design"
About 2- A few more theming options remaining:
The only point for me then remains the theme/design issue. In fact, I've just come to the point that most features of the request 2- A few more theming options might be easily handled thanks to a CCS class assigned to the term_display terms. Isn't it?
Also, I keep this issue to "Normal" though, as I think that the ability to theme easily a new feature is a normal demand for most users, and that it might be (I hope) only a few bits of code to change.
The paid drupal service offer http://drupal.org/node/219367 is reviewed considering this update.
Comment #5
doc2@drupalfr.org CreditAttribution: doc2@drupalfr.org commentedLimitations 3- About the CCK_taxonomy.module compared to the Taxonomy.module :
All those lacks (except for depth) are critical to me, but each one of them can be critical too many, which can make lots of drupalers altogether.
By the way, the CCK_taxonomy.module developper has a clear idea of what he wants for his module (eg. "Philosophy" of his project page and answers to feature requests). As I've already experienced, he doesn't seem to wish changes to it. It's aiming at leveraging "taxonomy.module's list and hierarchy building interface", and thus not at reproducing it. I'll have some other tries! But I doubt that he will agree to reproduce parts of the features the taxonomy.module is made for!
Don't you think a per-nodetype weighting feature could be valuable, in plus of a (2-) term_display class for CSS theming? I imagine that it wouldn't be to hard to do, but I'm far from sure...
Comment #6
doc2@drupalfr.org CreditAttribution: doc2@drupalfr.org commented"by design" isn't correct. See the Status levels of Issues bookpage.