Taxonomy based theming
arnabdotorg - November 15, 2004 - 21:04
| Project: | Sections |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | duplicate |
Jump to:
Description
Say I have a taxonomy: {Moods:"Happy", "Sad", "Morose", "Manic"}, I should be able to theme my pages according to that.
[conflicts between multiple terms per node will need to be resolved.]
#1
#2
This is *exactly* what the Sections module needs to solve the issues already opened here regarding paths. Instead of worrying about the URL and complex regular expression matching, why not base this whole concept on taxonomy? Great suggestion, I'll work on a patch.
#3
Unless you will relocate this to blocks, I will mark this as wontfix. Sections module should have the exact same interface as blocks. So if you wnat this feature to be implemented, you shoudl try to do so in the blocks, sections will then follow that example.
#4
Why should the Sections module have exactly the same interface as blocks?
#5
Beacuse of:
1) comaptibility,
2) consistancy
3) interopability
4) useability
and possibly some other -ilities.
But the best reason is: why not? It saves us documents, code, work and most of all it saves users having to learn YAI (yet another interface).
For me, as maintainer having it use the exact same interface is a requirement. If someone wants Sectiosn to do other things than blocks, feel free tom implement it. Just bear in mind that it will not be committed in the official release.
#6
How is using taxonomy forms implementing YAI? They're the basis for categorization in Drupal. I'm talking about the select fields visible on node creation forms to indicate categorization. Maybe I wasn't clear before: I thought it would be a useful addition to the module if, when creating a section, one could not only use regular expression matching for paths (like for the admin area of a site "admin/*"), but could optionally select taxonomy terms whose nodes would match that section. This solves the issue of having say, your forum page use a unique theme, but having it revert back to the default when a forum topic was opened (because it would be a node path at that point, and not "forum/*"). I think this module could benefit from implementing both scenarios, and I'm willing to implement the taxonomy-based idea.
#7
I agree with your that it is a valid feature.
but, please, read what I wrote: I will **not** implement any features that will make sections inconsistent with blocks.
If you want taxonomy-based paths features, that is very nice. But I will **not** implement them into sections, **unless** the exact same feature goes into blocks.
In other words: Get taxo-based path interfaces into blocks, and it will get into sections too.
Bèr
#8
I certainly already read what you wrote and tried to angle my response appropriately, but I still don't understand why you cling to this idea of matching the block module's interface (which you're not actually doing -- the block module uses a single-line textfield and encloses regex's in angled brackets, whereas you have a multi-line textarea and do not use delimiters). Why make coding easier on yourself if the overall functionality suffers? I'm not about to create a new module just to settle this debate, but I don't want to settle for a patch either; others are calling for this feature and it should be accessible.
Besides: how in the world would I go about getting taxonomy-based paths into blocks?
#9
I am talking about the blocks system in HEAD.
Why i cling to this blocks UI? again: its about useabilty, simplicity etcetcetc. You can call me stubborn, and you are right then, but any other code that exact blocks interface will not go into this module.
How to get it into module? Code nice, drupal compliant code make patches and issues, for them, and if people will like it, core maintainers might consider to actually commit that. Once committed, I will synch sections module with that.
But again: nothing withstands you from implementing and sharing a patch for sections module. The patch might help others too.
Bèr
#10
Block now supports the following type of settings. Will you be implementing that as a feature. While not taxonomy based this does allow greater flexibility and follow your dictum of aligning the development of sections with blocks
Content specific visibility settings
Restrict block to specific content types:
book page
flexinode-1
flexinode-2
image
page
story
Selecting one or more content types will cause this block to only be shown on pages of the selected types. This feature works alone or in conjunction with page specific visibility settings. For example, you can specify that a block only appear on book pages in the 'FAQ' path.
#11
yes. the plan is to get it aligned when I have time or a client that want to use sections.
Feel free to send me patches!
#12
Perhaps my client can become your client!
I have implemented sections on drupal site and i am using a regular naming convention for url aliases to work around the fact that blocks can be set by content created type and sections don't yet support that. If the sections supported it my end users wouldn't have to remember to name their url aliases consistently--it's not that hard but i want it to be as easy as possible so they will do it right.
I don't know php and can't write a patch but i'd be interested to know what kind of $ it takes to get something done by a fine programmer such as yourself.
of course if my client buys this we would be glad donate the patch you write back to the drupal community
post here if you like or email me via the contact form.
thanks
jess
#13
I am very sorry to say that I am all full booked at this moment.
Also, I really hope people do not misread my comment as "I need money to do this". Above all I need time.
However, I propose you get a bounty going for this, and if the code coming out of tha tbounty is up to standards, I will include it in the sections module.
I am sure there are enough people willing to pay a few bucks, to pay a developer to get this into sections module.
#14
#15
http://drupal.org/node/76620: A general task to get all such features in.
#16
I also think theming sections based on taxonomy would be a significant improvement to the Sections module.
Is there any progress in developing this functionality?
#17
In the event this might help others implement a solution for 6.x, you may be able to use the option to display Sections based on this php code returning true (from http://drupal.org/node/98300):
<?php
$desired_vocab = 1; // put here the vocabulary ID you're interested in
// check taxonomy first
if ( arg(0) == 'node' and is_numeric(arg(1)) ) {
// Yes, we're viewing a node.
$node = node_load(arg(1)); // cached
foreach ($node->taxonomy as $term) {
if ($term->vid == $desired_vocab) {
return TRUE;
}
}
}
if ( ((arg(0) == 'taxonomy')
&& (arg(1) == 'term')
&& is_numeric(arg(2))
&& ($term = taxonomy_get_term(arg(2)))
&& ($term->vid == $desired_vocab )) ) {
return TRUE;
}
return FALSE;
?>
#18
Isn't it not possible to use the path based switching for this? It would only become difficult for taxo combinations...