Is someone willing to make a definitive writeup of this? If you want to sit down and work together on this just let me know, and I'll help where I can.
I see so many parts of code snippets, and comments that it worked as well as comments that it didn't work, that I can't make heads or tails out of how it is supposed to be done.
Please if you post something try to be as clear and complete as possible so that people can understand, or maybe it is just me?
From what I gather:
Were supposed to do this in template.php, and only call the output result in the template file (but which variables, how and why).
The theme function got replaced by the render function.
For background info please see this support issue:
How to display a menu in a template file?
If I may make the suggestion we consilidate efforts there on working on the issue before adding it to the final draft of the doc page.
I've opened up a book page to build a documentation page on this, if you know how to do this the proper way please write it down so we can all save some time on this in the future. The book page can be found at How To Do Theming Examples Made Simple in Drupal 7. You can then add a child page for the subject.
Thank you for your participation! :-)
Comments
Edited the existing page
There is an existing page on it here: http://drupal.org/node/988694
I have edited it slightly to be more explanatory.
My initial response was this:
For Drupal 7, in almost all themes, menu links are displayed by calling theme('links__system_main_menu'). However, if you will search for this specific function in Drupal API, you will not find it, and may be confused.
The answer to the confusion is that 'links__system_main_menu' is not an actual function, but a pattern. A pattern, like 'page__article'. In this pattern, theming engine will look for this theme_... function, and if not found, it will use theme('links'). This is what happens in most cases, when this function is called when rendering your menu.
So, to theme it, you need a function theme_links__system_main_menu(&$vars) in your template.php file. And, of course, at least the code calling it from the page.tpl.php file:
<?phpprint theme('links__system_main_menu', array('links' => $main_menu));
?>
When implementing it in template.php file, you should replace the initial work 'theme' with the name of your theme. It will look like yourtheme_links__system_main_menu(&$vars).
To theme the menu, one should start with the theme('links') code form theme.inc file. Code from theme_links() should be copied over and adjusted to reflect the desired changes.
Is the example mainmenu in Bartik the best way to do it?
(Not sure if this is the best place to post feedback - I'm new here. Let me know if it would better belong in a forum or issue tracker or something.)
I've been working on my first Drupal site, to get a feel for the system, and after fiddling with a stack of modules to organise my content, I decided to try altering the theme.
Naturally, one of the first things I wanted to try out was changing the appearance of the main menu. My starting point was the Bartik page template.
One thing I wanted to do was adjust the attributes of the li tags. I couldn't see any obvious way to do it with the theme('links__system_main_menu') parameters. So I looked for a theme function I could override, and found theme_menu_link().
However, no matter how much I fiddled with this function - and I wasn't entirely sure I'd properly understood how to override theme functions - I couldn't get the output of this menu to change.
Eventually, I discovered that mytheme_menu_link() was being called for some of the other menus on the site, but not for theme('links__system_main_menu'). I'm still not sure why this is.
I understand that there are several ways of doing menus, with different advantages and disadvantages. But for the first menu that anyone sees, and quite possibly the first step on the road to learning about drupal theming, it seems strange to use a method that bypasses all the normal theming functions.
use blocks
It is better and far more easier to add a custom region (if needed) and display the relevant menu block there!
theme_links() sucks
The menu code used in page.tpl using theme_links() is a horribly complicated, non-obvious way to add menus to your site.
Instead, use the Menu Block module at http://drupal.org/project/menu_block and if none of the existing regions in your theme are exactly where you want the menu, create a new region.
- John (JohnAlbin)
if theme_links() sucks then what about menu_tree
To show all the menu tree in tpl
<?php
$menu_name = variable_get('menu_main_links_source', 'main-menu');
$tree = menu_tree($menu_name);
print drupal_render($tree);
?>
And still to add unique classes to
ulandliyou need to overridehttp://api.drupal.org/api/drupal/includes%21menu.inc/function/theme_menu_tree/7
http://api.drupal.org/api/drupal/includes%21menu.inc/function/theme_menu_link/7
or you can use superfish or nice_menus.
doesn't d7 menu always have a
doesn't d7 menu always have a menu block created without needing menu_block module?
You are right
But what if you only want to show all the menu items under the current active menu item. menu_block gives you this option.
Great to see such a response!
Great to see such a response! :-) I read a lot of interesting comments.
The sites menu's location won't hardly ever change. The menu items themselves are built dynamically from taxonomies.
The important bit is that the routing is efficient and easy to maintain.
If I use a menu block then with the site layout I have to:
Do a lot of rewriting in the Visibility Settings of the block anyway, and if I want to do this I have to to use the PHP Module to do this with PHP. That is an extra module just to show a block on a certain page... Either that or show the block in the theme file, using conditional statements. If I'm having to write conditional statements anyway why not use the menu directly, and save the overhead of a block?
The other option is to use something like PathAuto and GlobalRedirect. Then you can set path indentifiers which makes setting the location of the blocks easier. However the site is not going to use pretty urls, because I noticed a slow down, and I want to optimize the result for speed. I noticed a significant speed increase on load times when just using the ?q= variable. In the end I want my visitors to have a speedy site. Will it hurt the search ranking? Well, I'm willing to test this on this site. I see plenty of high ranking sites that don't use pretty URL's. I've always used them in recent years, but if it makes no difference, and there is a performance increase, then it is a no brainer.
Last but not least I want to theme the menu with ARIA roles and custom html (less cruft). I could do this in a block.tpl.php as well of course, but then I'm theming a block to show a menu which I have to theme?
Javascript menus I want to avoid, because I'm cutting all the javascript that is not used from the front end to save on page weight, and improve speed of the site.
A Drupal theme can come pretty heavy out of the box. I want to really trim off any unnecessary fat, and customize to taste. Which is a lot of fun to do, in it's own right. :-)
One thing that I am concerned about is what the caching or performance differences between menu and blocks are. Unfortunately I haven't found any data on this...
Blocks can definitely be a way to go, in certain situations. In other situations, using menus may be handier. I think it depends on your use case. On the other hand theming in Drupal can be so immensely complicated. I hope we can really continue to lower the learning curve.
A test case that I'm working on right now uses menu_tree, but I'll take a look at the options you posted Alexei. Looks interesting.
Didn't expect so many constructive comments. It's great to see. :-)
Don't know why but seems to
Don't know why but seems to me you are trying to improve the speed of your site in the wrong way...
If I was in your position, I will not worry about those things such as removing clean url and improve the site load speed by doing advanced caching such as varnish + memcached
There are many comments,
There are many comments, because this topic is painful. While there are good ways to display a ready menu or a part of it, it's very difficult to get into that process and change something if you need it. By the way, in Drupal 6 it was much easier to do.
But then, say, if you want to format your menu in a way that will allow certain special theming, you will find it hard to do. Doing it by intercepting that theme(link) code is the only way I have seen so far.
But then if you are doing something rather complex, it may turn out, that there are easier ways to do it. If you end up doing rewriting, redirects, and using taxonomy as menu, that there may be a better solution. There is a module called taxonomy menu. It will present a taxonomy or a part of it as a menu in a block.
Hi Alexei, Thanks for the
Hi Alexei,
Thanks for the tip. I'm using the taxonomy menu module. Although I may write a custom function in the future, as for my site it is more than I need.
Drupal just has some snafu's, which once you understand them, theming can be quite easy usually, however, there are just some weird quirks.
Personally I feel some of the stuff doesn't have to be so complex from a theme and application point of view. That is something where there is room for improvement. Including some of the documentation. Although Drupal has come a long way. Let's give credit where credit is do.
Maybe we should as a group of themers sit together and write some functions that will aid in theming. Just some functions that we know we use often. A toolbox if you will.
As far as I know, there is an
As far as I know, there is an initiative underway, for Drupal 8, to use Twig for templating. That should make things better. If you happen to know Twig well, check out the Drupal 8 Design Initiative - they are short of hands. http://drupal.org/node/1089096
Btw, there will be no theme
Btw, there will be no theme menu function anymore in Drupal 8. Everything will be blocks and regions. So using a menu block even now will already make sense. Actually I'm using this technique for 5 years now or so (menu as a block).
Cheers,
Andrey
Free and Premium Drupal Themes | Drupal Sites Showcase. Add yours! | My Blog
@Alexei,Thanks for the tip.
@Alexei,
Thanks for the tip. Good to see this has some attention.
Yes, I have heard about Twiggy. While I find it interesting slapping on another coat of paint on the same house won't make a difference though. Besides some people are just getting used to PHP templates. In WordPress look up a function in the Codex and there it is. Put it in your theme, and it works.
In Drupal? I've spend a day now trying to embed a view in a taxonomy-term.tpl.php. Followed all the directions. Even wrote some documentation on it, after receiving help from someone on the subject. What does the thing show in my website? The view, plus a page.tpl or node.tpl info, that I can't seem to switch off anywhere.
And so it goes on and on and on with just about every single thing you want to implement in Drupal 7.
I try to help where I can, but how am I supposed to help if I have to guess my way through a lot of stuff, because it is so complicated.
There needs to be a think shift with developers, that people actually have to use this stuff, that don't work with it everyday. Help us help you kinda deal. I could be writing documentation or doing other cool stuff. Instead I'm looking at a page with code, which just doesn't do what it says on the box.
And I'm about to rage quit. I'm gonna do something else for now. I'll figure it out. Maybe I'll wait till Drupal 8, or go back to 6. This is just costing me too much development time.
@betarobot,
That would be interesting. How do we theme menu's then?
Using template (pre)processes? God, no, will the nightmare ever end.
Always puzzled when people
Always puzzled when people say 'how you theme it'... there are a bunch (i.e. usually enough) of classes produced by drupal, just apply CSS for code sake!
Re core menu blocks I had to use only one preprocess to give each item unique class (as in my base theme http://drupal.org/project/noodle):
/**
* Add unique class (mlid) to all menu items.
*/
function noodle_menu_link(array $variables) {
$element = $variables['element'];
$sub_menu = '';
$element['#attributes']['class'][] = 'menu-' . $element['#original_link']['mlid'];
## print_r ($element);
if ($element['#below']) {
$sub_menu = drupal_render($element['#below']);
}
$output = l($element['#title'], $element['#href'], $element['#localized_options']);
return '<li' . drupal_attributes($element['#attributes']) . '>' . $output . $sub_menu . "</li>\n";
}
That's it. But, it was a few years ago, since then I tend to use aforementioned menu block module which should add classes without need for this preprocess. So this preprocess is more of a legacy piece for me.
Cheers,
Andrey
Free and Premium Drupal Themes | Drupal Sites Showcase. Add yours! | My Blog
Somehow previous was double
Somehow previous was double posted...
To fill the gap: you may also check http://drupal.org/project/biolife (or this little drupal install https://github.com/betarobot/noodle-biolife-fullsite) to see how you can live happily without menu variable in your page.tpl.php.
Cheers,
Andrey
Free and Premium Drupal Themes | Drupal Sites Showcase. Add yours! | My Blog
Thanks Betarobot, It's the
Thanks Betarobot,
It's the whole add another class way of working that is part of the problem I feel. But luckily that has been set on the agenda.
Should be able to manipulate the data coming out from the database, and at an (application) design level to easily work with the output, and style that relative easily.
I'm currently using the groundwork theme, which I just discovered uses all blocks, so from that standpoint using a menu without a block is pointless. It does tie in with what you say about Drupal 8 not using menu's as is, so that would be solid.
In any case I have found groundwork to be light, easy to theme, as well as adhere to standards, and comes with Aria Roles.
I may just write my own theme, if I want it really light weight. It will be a good exercise.
However working together with others can give improved results vs. everyone, including me, doing their own thing.
Maybe it is just because designers are more visually oriented? Yet, somehow I think that is selling people short. There seems at times a really hard line drawn with Drupal between programmers and designers, and the two need to keep communicating well in order to produce something that works. That differentiation between those two may also be the cause of some of the design problems. There really needs to be a in between. WordPress for example has done this really well.
There is definitely added benefit for using a system such as Drupal. On the other hand it should facilitate not get in the way. Then it is just a time and money waster. Like I said, Drupal 7, in many ways is beautiful. There is just still a way to go before it is really the awesome platform, that I believe we all see, that it can be.
Some parts of Drupal are really done well, without a doubt. But Open Source projects were meant to be an improvement, to old days. I'm really struggling to see the improvement at times.
Why are there so many
Why are there so many functions/ ways to display a menu? Isn't that part of the problem?
Wouldn't it better to consolidate those in one menu function? It could cut down on code maintenance as well.
There is really one way to do
There is really one way to do it. But it is a power of Drupal, that it (usually) allows you to hook in the process and change things there as you like. Menu is presented you you as an array. Render function takes the menu data at a higher level, and then it themes it. So links theme function would be included in the render command.
It's like render function is "Build me a house", and theme function is like "I want to paint it myself, (moving around a room or two as I do it)". It really becomes very advantageous to use in time.
@Duckzland,I was wondering
@Duckzland,
I respectively disagree of course. :-) For running what is in essence a simple PHP database website? That's putting the horse behind the cart. This results in higher hosting costs and more consumption of electricity. In some cases unnecessarily.
Let's put in more cruft, and then throw in more horsepower. I don't know about you, but drupal.org is slow as molasses at times.
Also with the mobile initiative, the less cruft the better. Besides the whole point of the Drupal theming layer is being able to customize it yourself. If you want the standard way fine, there it is easy to use. If you want more power open up your editor and style away.
Besides most Drupal sites I know aren't exactly known for their speed. Quite a few of them are slow as molasses. While there are certainly some improvements to be made.
By the way I think a lot of code in Drupal is a stroke of genius, really well thought out, and works beautifully. There are some things which, from a theming (learning perspective) point that I'm and others as well are struggling with. Views for example has made some great steps with this, allowing to override the themable output easily in all sorts of ways. Why does it take me 5 minutes to add a menu in WordPress or PHP for that matter, yet do I need a degree from MIT in PHP to add a menu in Drupal? Let's face it though Drupal is not, yet, known for it's ease of designing with.
Also just to make theming easier at times would be such a great help.
Why do I need to preproces a function in template.php with all kinds of code when I could just use a simple function in the theme, yet that function remains powerful enough to do anything with a menu I may need.
For example what if the menu function would look something like this:
dp_menu($menu, $wrapper, $container, $element, $level, $value_type)
Where:
$menu = The identifier of the menu | Required
$wrapper = The wrapper (e.g. <div> or <div id="id" class="classes">) | Optional (Defaults to a <div> with core markup)
$container = The menu container (e.g. <ul> or <ul id="id" class="classes">) | Optional (Defaults to <ul> with core markup)
$element = The item container (e.g. <li> or <li id="id" class="classes"> | Optional (Defaults to <li> with core markup)
$levels = How many levels do you want to show (e.g. parents, parents and children, only children) | Optional (Defaults to menu settings)
$value_type = Plain text (1), URL (2), Link (3) | Optional (defaults to 3)
I think with a function like that you have the functionality you need (Let me know if I forgot anything) While have an easy and powerful function to use at theming level. You could even then write a hook which allows you to change those settings from within a block.
Let's not get sidetracked too much on a performance discussion though, this is mostly about how easy it is to design in Drupal. The performance issue is secondary while still at a same level of importance, one results form the other one could almost say.
Either that or we have to say: well Drupal is only accessible for large corporate sites or people who have access to large hosting plans and a-ton-of-server-power. Aren't we kinda missing the mark and cutting out a lot of potential users then?
I respectively disagree of
How much is a good VPS nowdays? thousands of dollars? compare that to the time needed for you to "strip down everything" , throw away SEO friendly url, over optimizing things to a level that nobody beside you (read no other developer) can fix your site if its broken.
define large hosting plans, does a USD20/month VPS counted as a LARGE hosting that normal user can't afford?
so to make the adding menu problem easy for you, grab those cheap vps and use modules such as menu-blocks with powerful theme such as omega + delta + context combo.
I'm not stripping down
I'm not stripping down anything I'm building up a custom front-end using PHP, HTML, and CSS using existing coding standards. I bet there are more people that know the coding standards for those three than Drupal.
Drupal is also known for its steep learning curve, and the template systeem has changes with every version. How much does it cost to change the template and other stuff on the website every version? And from what I gather there is a shortage to find people that know how to work with Drupal. There is a reason for that it is too difficult to learn.
Just the other day met a talented designer, who was looking at Drupal. This person builds a site in no time. In Drupal, forget it, stuck in beginner's hell. Ready to quit already. Yeah, sure it's all the site-builders fault. Just use 'yet another module', to do something else.
What is a relative constant with Drupal? The database.
So if a Drupal version changes , or you change database, you may have to update some queries, but the layout can stay the same.
You can use modules such as Panels, Context, and Views to build some of the mock-up site where it benefits you. Then once you have a layout build your site with PHP, HTML, and CSS. There is loads of documentation if you get stuck. You save a lot of unneeded bulk. If used in the right use case you can get a lot of performance.
It takes me a-ton-less time to put up a normal site than a Drupal site. Let's face the facts here.
When modules store their data without mockup in the database you can call on that if you want.
The seven theme and backend for Drupal is a things of beauty.
You can use this for administration, and building some of the internals, such as taxonomies.
So whichever way you deploy it after that: you win overall.
Hej, I'm not saying it is for everyone. It fits for me. If you want to use something else go ahead. For me it feels like when we could stop working with IE6, or Dreamweaver first came out. Awesome.
Have you seen the bug que? Besides context for example is still in beta for 7. Putting buggy beta modules on my site instead of a lean coded model is better? No, it's not. I'll happily help on fixing bugs for stuff I use, my track record speaks for itself.
Drupal experience
Drupal can be a mixed experience for many developers. I've been working with Drupal for just on 4 years now, focused on D7 for about the last 20 months.
I'm a computer scientist with 17 years experience with web design and development, and I often come across design choices in Drupal that make me shake my head in disbelief (aspects of fields, for instance). Having said that, I can knock up a very complex data model in D7 very fast, without coding, and knowing that I don't have to worry about SQL injection, or more than half of my form validation requirements, or my widget rendering, or form attributes, or about a half a million other things. A good responsive theme such as omega or skeleton delivers clean modern HTML5 code, correct doctype and char encoding, latest tags, all the good stuff. I've studied a lot of the new HTML5 stuff, too, but I'm always pleasantly surprised when I inspect the code and go "oh, that's already in the theme. well, that's good, I might have forgotten that."
So I mean, even though Drupal annoys me sometimes, and often requires compromise in terms of architecture and performance, it also does at least 80% of what I would have had to otherwise code myself. Drupal enables me to focus much more on architectural and UI design, which is what I should be focusing on, instead of the basics that go into every site.
If you're unsure about the value of Drupal, ask around. Ask people who work with it every day, designers included. You're weighing up the time cost of learning how to use it (and it's not exactly rocket science) versus the time you'll save building your next 10-20 or more sites. It's very much a case of "learn how to fish and eat for a lifetime" (if you'll allow me to paraphrase). With every site you get faster, and every year or two a new version of Drupal comes out which is always a quantum leap better. I've worked with D5, 6, and 7 now, and there are always clear improvements. In D8 some of the most serious problems that have plagued Drupal are being addressed, such as WYSIWYGs and config management. Drupal constantly improves at essentially no cost to you, and this highlights another of its main advantages - modules and base themes get better at no cost to you, so you can periodically update your site with bug fixes and security patches, for free; if you build the site yourself, let's be honest, that stuff normally just doesn't get fixed.
A disadvantage is that since the advent D7, I have noticed not as much work being done on modules. This is a serious issue, but the old adage remains, if you want the module fixed, fix it yourself. Unfortunately the number of people capable of doing that work, who have the time, is not enough for the task. Personally I think they are pushing D8 through too fast for the modules to keep up, but maybe it will be worth it.
Another advantage, on the other hand, is that Drupal is massively popular, and something like 2% of the internet runs on it. There aren't anywhere near enough good developers to go around. So, if you make the effort to learn it and get good, you'll always have work, and you can make more money.
mossy,You make some
mossy,
You make some excellent points. I agree with you for the most part. Those are all things I say to myself, when I'm looking at Drupal. Yet, why does it take me a day to a week to design a site in WordPress or with normal PHP and HTML, and does it take me three times, or longer, as long in Drupal.
From what I gather there is developer burn-out developing in the community. Which isn't hard to understand when you think about it.
Yes, Drupal has made huge leaps. 7 took a long time to come out. The goal was for a quicker release of 8. With all the changes planned in 8 maybe some people are just thinking, well should I spent time on 7.
It's not a question about learning how to fish. It's a question about having a theme layer which in some sense is indepent of core changes, and easy to use. Having learned 6, I find 7 actually harder to build the front end in than 6. This while the goal of Drupal was completely opposite. Having said that the administration backend is a thing of beaty, Bartik is beautiful and absolutely stunning. Drupal Gardens is awesome. Drupal 7 has many many things going for it.
Triple nested arrays that have to be overwritten with a preprocess function in a template.php so that I can change something in the theme is not one of them. I spent half the time looking through massive arrays and div soup, looking for a wee bit of info way way way in the bowels of Drupal.
Why? No one here has been able to answer that yet. Why do we do it like this? It's all about 'Yeah, learn the Drupal way?' Why, should I? convince me by showing me it's faster, easier, better, cheaper to deploy. Talk is cheap, show me the code. ;-) Because I have serious reservation whether it is, not in the short term, and not in the long term, Don't you think I would be shouting it off the rooftops, if I was like wow Drupal is this really great amazing thing.
Stop talking yourself into that it is great people. It's good, but not great.
You know compare it to a pipe which you want to flow water through.
Do you want a solid pipe to exact engineered spec, or a pipe which has all kind of welded (buggy) patches on, wondering whether it will hold up. That is no way to begin on a project. That is waiting for the thing to explode when something updates, or goes buggy. Trust me I've been there with Drupal. There is a reason that I use and recommend WordPress.com and Drupal Gardens to people.
Unless you have the time, know how, and resources to maintain a Drupal site. If Drupal wants to grow, then that curve has to lower, or the teaching has to improve. Drupal core with me has an excellent track record. Just adding another module, because programming in core is too hard, doesn't make any sense. Core can do all this stuff already. (this is the short version, otherwise this post will get way to long, it's already quite long).
But you know design should be fun, and whenever I'm working with Drupal it's not. It is a painful experience. When I go to work with other products it's like hej this is why I love design stuff.
Design in Drupal 7, worse than Microsoft, by a long way. That is how bad it is. This from someone who treats open and closed source equally.
Drupal experience
(sorry for repost, GDO does this sometimes)
No probs. I found out that
No probs.
I found out that GDO sends an e-mail everytime you do a text revision or correct a spelling mistake as well. Sorry, about that folks, I'll keep that in mind in the future.
Did you only want to do this the hard way Dolphin?
I couldn't help but notice you didn't say what you are really trying to build there and - no one has asked either - but is there a danger that you're simply trying to run before you can walk here?
I had lot's of similar issues when starting out with Drupal a couple of years ago and as a non-programming designer I used to marvel and pull my hair out in equal measures over what I could and couldn't easily do with Drupal. Placing and editing menus was definitely of the hair-pulling variety. How could it something so basic be so complicated?
But assuming you are a relative beginner with Drupal then have you not looked at the Omega theme system for whatever your needs are? I personally love the Omega theme as it includes a wide range and number of configurable block/layouts out of the box, they're responsive too if that floats your boat. Omega's Delta module allows you to "tokenise" just about all of the usual Drupal page elements too (page titles, breadcrumbs, default menus and so on) and place them into any block/region on the page (or you can easily add and/or reconfigure them).
Menu Block itself is terrific I would say. You only need to enable it and configure starting parent menu item, drill-down depth and other useful options (like linkable block titles, etc). Using Omega/delta you can then place them pretty much anywhere you like but even better than that you can use Context module to create as many layout variations as your site/project needs, all responsive if needed, and you can move all your content, titles and menus around to heart's content without writing a single line of code.
It's great if that's what you're looking for. Are you?
The other menu system that's also terrific is the aforementioned SuperFish which also works superbly and supports touch events for mobile usage, again if that's something you're looking at. Nice Menus is also great but the extra touch support, together with other great options makes Superfish a great choice for one-click adding slick, advanced, highly themeable, drop-down (or out) menus.
As you can probably tell I'm a huge fan of responsive sites/development, as a designer, and so the Omega/Delta/Context build system + either Menu Block and/or Superfish gives me great control, themeability and power without having to muck about with any code whatsoever (except CSS of course).
Modules referred to are here:
I hope that helps - but good luck anyway Dolphin.
Q
I was going to offer
I was going to offer solutions similar to @quantos', because in most Drupal use cases, doing things in a Drupal-configurable/editable way is best, because that's one of the main reasons to use Drupal... so that people who don't know how to write code can maintain websites.
I've taken over many "rescue" projects, where a programmer just ignored "the Drupal way" and did everything her/his own way and hard coded the theme to the point where clients (content editors, organizational webmasters, etc.) could no longer reliably use the Drupal admin UI to make client-appropriate adjustments. When Drupal sites are built that way, it's very hard for another dev to come in on a site that isn't using best practices, and it can make the site brittle and unsustainable in the long run.
If you want the site to be very, very light, then perhaps Drupal is not the best choice. Though in my experience, the "notorious slowness of Drupal" is over overstated and exaggerated for most use cases. I've seen this argued into the ground repeatedly, so if you're finding Drupal with a typical set of modules unreasonably slow, then so be it.
If you need a menu that loads conditionally, using a menu block and placing it via Omega + Delta + Context is a great option. In many cases, just a decent theme and the Context module alone may solve your problems. You can also conditionally control layout configurations and content with Panels.
Of course there are exceptions and special use cases where doing something else makes sense. If you're there, then you're there. Best of luck either way.
Omega / Delta / Context / Superfish
I would definitely second the comments and thoughts that Quantos has put forward. As for effective and relatively easy to use, Superfish is very hard to beat. The CSS is definitely convoluted to understand, once you do though you can build some really great awesome looking menus.
The ability to do so without hitting up code craziness is a huge time saver. I can understand the frustration here...
"Eat food. Not too much. Mostly plants."
— Michael Pollan (In Defense of Food: An Eater's Manifesto)
Thank you for your
Thank you for your comments.
I've been working with Drupal, since Drupal 4.7. I have built several sites in Drupal, having exceeded 8,000 visitors a month. I am reasonably familar with the Drupal way. Of course it doesn't help if that way changes every version. I could rant here, trust me. And I share your experience of frustration and happiness. But you know what it is taking too much of my energy, and I really do have other things I want to do with my life.
I know enough of Drupal that you shouldn't start with a new version until you know your way around. etc. etc. I know all about walking before running etc.
Before I read your comments, I was going to post anyway. Enough is enough. I'm ditching the Drupal theming layer.
I'm just going to build a front end using PHP, HTML, and CSS for this website. I'm using the Drupal for the backend and handy stuff. Building up the queries and stuff in views.
From what I read about Drupal 8. It looks promising. Worst case scenario I'll port the database over.
Drupal theming is taking too much of my time for what sometimes must be the most simple tasks. Plus PHP, HTML, and CSS have extended documentation.
I love Drupal. I was amazed by Drupal 7, till I got to the theming part. It is not fair to expect people to work under these circumstances. You may disagree, fine by all means, but I'm done with it. Like I said I'll refrain from ranting, as I want it stay a positive discussion.
Just wasted another entire afternoon figuring out why taxonomy-term.tpl..php doesn't do what it does.
Who knows maybe in the future it will be better.
Ooooh context
Ooooh context module.
http://mustardseedmedia.com/podcast/episode38
Wow, that is some really cool stuff. :-)
You're right to mention that.
Don't know if I'll use it, but I'll check it out.
Thanks for sharing.
Cocoa Thoroughbred Theming
O.k. with context module I can't add a block to taxonomy term page with a panel. There are others who have the same problem. If embed a view and use taxonomy.term.tpl.php then I get another error. Then when I look at something like var_dump($node) and look at all the stuff loaded, that is a lot. Most of which I don't need. The whole (pre)process stuff with nested arrays, my god the horror. Plus using all that I still get stuck with have to this menu building. Plus it seems like Drupal loads everything, and then you have to unset it. I'd rather have it the other way around. That's is nothing against the individual modules. With some work I'm sure those problems could be solved. I'd rather get a site up and running and help with those bugs, then waste my time with the current theming layer. However for me, adding everything up. I'm sticking with ditching the current theming layer.
Just roll your own. You know someone once told me a theme in a cms comes with everything turned on, because it has to work with every use case. The same goes for Drupal. However, in doing so, for me as a site-builder, and from a performance aspect:
I mean hide('content')? Really? Don't load the stuff on the first place, only call it if you want it.
So then what?
Well I'm going to start with a open source GPL theming workflow called
Cocoa Thoroughbred Theming
As fast as a thoroughbred horse, as easy as making a cup of hot cocoa.
Call it the Lubuntu version of the Drupal theming layer. I want to build sites when I use Drupal, not spend weeks pouring over documentation, and having a slow site for no reason, except that it is easier for some users. Drupal theming is like a huge bus, that has everything including the kitchen sink, well I want the McLaren or Ferrari version.
Will it go anywhere? I don't know, and with things looking like they do for Drupal 8 and beyond, it may not be needed in the future.
Others are welcome to join in, ofcourse. We could write some custom functions/ queries that we can just easily and quickly load, stuff like that.
Thanx for all the hard work everyone. I do really appreciate it, but I feel the need for speed and easy of use when building the front end.
I am a bit lost as for what
I am a bit lost as for what you are doing, Dolphin. You started with the need to preprocess the menu, to displaying the taxonomy as a menu, to displaying a block at the menu page. If you are advancing through the stages of your project, would be nice if you would outline them as you move form one to another.
As for the taxonomy menu on a taxonomy page, I see no reason why context would not work for you. But if it won't, you can surely do without it and use a block visibility settings set to php, and process the args.
Say, in visibility settings, you can have:
<?phpif (arg(0) == 'taxonomy' && arg(1) == 'term' && is_numeric(arg(2)) {
return TRUE;
}
?>
And that will render the block only on taxonomy pages.
Context is a powerful and big module, and using it is a strategic decision. You surely don't need it to have visibility of one block set.
Yeah, I can understand you
Yeah, I can understand you saying that, maybe I was a bit unclear about that, or it has grown along the way. The menu problem has in a sense I guess become a metaphore for how difficult it is to design in Drupal.
I really appreciate the suggestions people are making, and by all means let their be discussion, but I'm not going into a technical discussion about the current Drupal theme layer for 7 anymore. Moving on. For the 8 and beyond development, yeah sure, great discussion.
It may take some time for me to react the coming weeks , just so people know.
And Alexei,
I really do appreciate you thinking along. You have some great ideas.
I'm just done with the current way of working. It's nothing personal. It is time to have some fun. :-) I want to concentrate on stuff I like, not stuff that frustrates me to no end.
No problem. Drupal has a
No problem. Drupal has a great community, and it's freaking great how many people have responded. I have not so far met a task in my almost 5-year Drupal practice, that I could not find help with in Drupal community. :)
Alexei,I agree with you
Alexei,
I agree with you wholeheartedly. Thank you for your comment.
Wonder if XML may be a way go
Wonder if XML may be a way go on this.
This could:
1: Alleviate the concerns of some of having to build queries
2. Allow for flexible content display, which would fit into the way Drupal/ the web is heading
3. Lower the learning curve, and speed up building the front-end
4. Allows to work directly from output such as from views (which is going to be included in core).
5. Allow the heavy lifting to be done in the back, which can be cached, while the output could be relatively light.
6. Could be implemented as a module, allowing for implementation in Drupal 6/7 as well as in the future. This while development for 8 could continue normally (maybe even take some of the pressure), when 8 comes port the module, if needed.
Content area:
category.xml
Sidebar area
sidebar-a.xml
o.k. so there are already a
o.k. so there are already a couple of modules that do this. :-)
Having looked around I found these two interesting as a starting point:
Services
Services views
This opens up all sorts of possibilities. One of them is that it could simplify theming a lot, as well as speed up a front end.
Using a mostly largely static site? Just write the XML to file on the server, and load them from there in your layout. Have an update? No problem, just update the XML file. Adding any additional caching needs along the way. Need a more dynamic site? Well, that too, should not be that difficult. Want to load your XML content into your Apple or Android app? Should be doable, right?
The beauty is you can relatively easy have the output as you want it, to display how you want it in your theme.
Win win. Some of this is theory, and I'm curious what other people think about it. It could potentially make theming life in Drupal easier and quicker by a mega factor, as well as lowering the learning curve for designers and site-builders.
It seems you are trying to
It seems you are trying to reinvent the wheel without some basic information. Knowing Drupal a bit more before going on with such initiative would just help. Say, there are template engines: http://drupal.org/project/theme%20engines
You just might want check some options. The one you call 'drupal template layer' is called PHPTemplate (that's why it has so much php in it, hence the name).
As you can see the majority of template engines would not really update for a while. And that happened just because PHPTemplate became mature enough/default and was most popular of them all anyway. But maybe you'll like PHPTAL or revive Smarty. Or even port WordPress template engine to Drupal if you wish.
And btw: you can try to use Twig for D7 already: http://drupal.org/sandbox/ReneB/1075966
Cheers,
Andrey
Free and Premium Drupal Themes | Drupal Sites Showcase. Add yours! | My Blog
Thank you betarobot,I
Thank you betarobot,
I appreciate you thinking along. I think your design look really nice. I value you thinking along with this.
The last thing I want to do is re-invent the wheel. ;-)
Yes, I remember there being multiple template engines. Hadn't heard the reason they were left out because they were outdated.
I'm not trying to be stubborn, but I don't understand your point. Could you please explain it?
Keeping things up to date is a valid concern. I agree with you there. But won't relying on something like Twig increase (external) dependency, and possible increase workload? Besides how will the community react to having to learn a new theme language? (I hate already, by the way) Won't all old themes and websites have to be ported? And will it really improve things? It's good to have this discussion now I think.
Having looked at Twig. I'm not sure I want to use that. It seems pretty complicated actually.
From what I gather Drupal 8 will have a different interface:
http://groups.drupal.org/node/259593
See my comments for ideas on that:
http://groups.drupal.org/node/259593#comment-836973
http://groups.drupal.org/node/259593#comment-836988
Combine this with the Drupal goal of being more flexible in output (e.g. mobile, tablet), and a lighter footprint. As well as making it easier for designers.
To tell you the truth I don't see myself working with Twiggy. I'm not going to learn another language just for one platform. Especially when that platform is already exceedingly difficult, and there are other options out there. I think Drupal could potentially lose a lot of users with this step.
The services modules has 14,895 reported installs. Views has 521,323 reported installs. Those are hardly small numbers, I would not cal that re-inventing the wheel by any means. So, it is building on widely used modules, where, like I said, views is going into core.
For example something like this for a dynamic category page, just some really quick pseudocode to get the idea (Which I'm sure could improve, and I haven't tested but just a mockup, there may be better ways):
<div id="header-wrapper">
<?php include('header.php'); ?>
</div>
<div id="main-menu" role="navigation">
<?php
$main-menu = 'main-menu.xml';
if (file_exists($main-menu)) {
$xml = simplexml_load_file($main-menu);
print_r($main-menu);
} else {
exit('Failed to open main menu xml.');
} ?>
</div>
<div id="content" role="main">
<?php
// Select on basis of args in URL
$fruits_id = int(arg(2));
$category_xml = 'category' . $fruits_id . '.xml';
if (file_exists($category_xml)) {
$xml = simplexml_load_file($category_xml);
print_r($category_xml);
} else {
exit('Failed to open content.');
}
?>
</div>
<?php if (arg(0) == 'section' && arg(1) == 'fruits') { ?>
<div id="sidebar-a" role="complementary">
<?php
$sidebar-a = 'sidebar-a.xml';
if (file_exists($sidebar-a)) {
$xml = simplexml_load_file($sidebar-a);
print_r($sidebar-a);
} else {
exit('Failed to open sidebar.');
} ?>
</div>
<?php } ?>
Where category accepts parameters from the url.
Now, right away we see for example that opening the (dynamic) url for the xml could be a function. So then all we would have to would be something like this pseudocode in the theme:
function load_the_xml_file($file, $args)As the data is pulled in from an XML file it could be easy to add the markup and styling from what I can see so far.
That whole thing took me about ten minutes to write. (It probably looks like it, but remember it's just a quick conceptual mock-up) That is a lot quicker than how theming is done now.
Couldn't we use the PHPTemplate or a Drupal engine for this, then? Something which people know how to work with. Or why would I use a templating engine at all? Instead write a module which converts some of Drupal standard stuff like site name into the theme?
Shouldn't the focus be on improving existing things instead of switching to something completely new like Twig which will have it's own problems?
Edit: Things that would need to be looked at of course is memory and perfomance issues. XML is used pretty widely, so undoubtedly there is documentation on this. Then look at which is the best method e.g. load from file, dynamic pagination (in filename e.g. category_1_1.xml, category_2_2.xml), or load from database depending on the situation.
Ahm... using XML files in
Ahm... using XML files in drupal will be exactly that new thing nobody understands...
Also, I've spent some time working on a Magento theme for a friend, and Magento uses this split CMS/XML/TPL approach. Something you can do in Drupal in 2 min and a few clicks/tpl edits, you have to spend 30 min fixing a lot of files. Still gives me shivers! So I'm out of this discussion ;)
Cheers,
Andrey
Free and Premium Drupal Themes | Drupal Sites Showcase. Add yours! | My Blog
Edit: See my comment below.
Edit:
See my comment below.
Decided to give Drupal another shot
I need to stop focusing on what can't be done, and start focussing on what can be done.
Things like these projects:
https://drupal.org/project/block_aria_landmark_roles
which adds aria roles to blocks.
http://drupal.org/project/block_class
Which allow you to add a class to a block
Both through a dynamic system while being able to change it easily.
I decided to remove my previous comments because they did not work towards a solution. My apologies for that.
Long and windy road
Managed to find a way to print a menu tree based on the vocabulary id.
Update:
Bug notice: The current code will print a opening and closing ul on every child li. Working on a fix, where setting the children level is also automatically done.
Version Proof?
One nice thing about this from what I read in the API is that the taxonomy_get_tree() function works in multiple versions of Drupal (with exception of the $load_entities, which we're not using here). So you may be able to use this in different versions, up to and including 8. This needs to be checked.
Link to taxonomy_tree_api()
I chose for using a taxonomy for a menu, because it will allow for a menu based on the taxonomy terms, this reducing redandancy in creating and building menu items. The taxonomy_tree function also uses caching, which saves overhead.
This way also able to set the custom HTML markup and styles for the menu.
<?php
function vocabulary_menu($vid) {
// Get the taxonomy tree based on the vid
$terms_menu = taxonomy_get_tree($vid);
// Set the URL path e.g. '/?q=taxonomy/term/'
// (don't forget the last slash) The term id will be added later.
$path = 'path_to_your_taxonomy_term';
$menu = '<ul>';
// Do our loop
foreach($terms_menu as $menu_item) {
// Get the menu item name from the array
$name = $menu_item->name;
// Get the taxonomy term id from the array. This is used to build the link path
$link = $path . $menu_item->tid;
// If term level is 0 then build
if($menu_item->depth == 0) {
$menu .= '<li><a href="' . $link . '">' . $name . '</a></li>';
}
// If term level is 1 then build
if($menu_item->depth == 1) {
$menu .= '<ul>';
$menu .= '<li><a href="' . $link . '">' . $name . '</a></li>';
$menu .= '</ul>';
}
// If term level is 2 then build
if($menu_item->depth == 2) {
$menu .= '<ul>';
$menu .= '<li><a href="' . $link . '">' . $name . '</a></li>';
$menu .= '</ul>';
}
}
$menu .= '</ul>';
// Print the menu when using the function
print $menu;
}
?>
<?php
// Example: The number is the ID of the vocabulary. Place this (with PHP tags) where you want the menu to show.
vocabulary_menu(3);
?>
Things to improve/ different versions
Please feel free to comment if you see any improvements to the code or method. Once reviewed this could be added to the documentation.
The tricked out version V0.6
Update:
Bug notice: The current code will print a opening and closing ul on every child li. Working on a fix, where setting the children level is also automatically done.
Drupal Version
7.16 It may work on other versions but this has not been tested.
To-reiterate
Wanted to show a menu with custom styles and Aria role based on certain criteria such as taxonomy terms, nodes (some of which are node panels), or content types.
What is different with the previous version
For more info please see the previous post.
What will it do
1. Show menu based on vocabularies on taxonomy term pages.
2. Show the menu for a node id (please note if you want multiple nodes you'll have to use an array and change the code).
3. Show the menu on specified content types
Status
Alfa code. If it breaks you get to keep both pieces.
Code and documentation are subject to review.
Will this work for you?
Meh, you'll probably have to do some fiddling.
The Code
In template.php:
<?php
/**
* First part of three of the vocabulary menu function. This is the routing part.
* Calls the build menu function vocabulary_menu_builder() only if these criteria pass
*/
function vocabulary_menu_router() {
// Check to see if we are on a taxonomy term, and get the vid if we are
if (arg(0) == 'taxonomy' && arg(1) == 'term') {
$term_id_url = taxonomy_term_load(arg(2));
$vid = $term_id_url->vid;
// Check to see if we are on a node and get the preset vid if we are
} else if (arg(0) == 'node' && is_numeric(arg(1))) {
// Set the node id's you want the menu to show on
$node = node_load(arg(1));
// Select based on preset nid and node type
if ($node->nid == 'your_nid' || $node->type == 'your_node_type') {
// Set your vocabulary id
$vid = 1;
}
// Select based on preset nid and node type
if ($node->nid == 'your_nid' || $node->type == 'your_node_type') {
// Set your vocabulary id
$vid = 2;
}
}
// If the criteria pass build the menu
if (isset($vid)) {
return vocabulary_menu_builder($vid);
return TRUE;
} else {
return FALSE;
}
}
/**
* Second part of three of the vocabulary menu
* This builds the menu. This only gets called if the criteria in the router pass
*/
function vocabulary_menu_builder($vid) {
// Get the taxonomy tree based on the vid
$terms_menu = taxonomy_get_tree($vid);
$vocabulary_info = taxonomy_vocabulary_load($vid);
/**
* Set the div for the menu, optionally adding id or classes.
* If you don't want a wrapper div remove or comment this out.
* Don't forget to do the same thing for the closing tag.
*/
$menu = '<div id="your-id" class="your-class" role="navigation">';
/** Get the menu title .
* If you want a custom title, remove the two lines below, and replace with $menu .='<h2>Title of your menu</h2>'.
* If you use a custom title you will have to set conditional arguments for different titles
*/
$menu_title = $vocabulary_info->name;
$menu .= '<h2>' . $menu_title . '</h2>';
// Set the URL path e.g. '/?q=taxonomy/term/'
// (don't forget the last slash) The term id will be added later.
$path = 'path_to_your_term';
$menu .= '<ul>';
// Do our loop
foreach($terms_menu as $menu_item) {
// Get the menu item name from the array
$name = $menu_item->name;
// Get the taxonomy term id from the array. This is used to build the link path
$link = $path . $menu_item->tid;
// If term level is 0 then build
if($menu_item->depth == 0) {
$menu .= '<li><a href="' . $link . '">' . $name . '</a></li>';
}
// If term level is 1 then build
if($menu_item->depth == 1) {
$menu .= '<ul>';
$menu .= '<li><a href="' . $link . '">' . $name . '</a></li>';
$menu .= '</ul>';
}
// If term level is 2 then build
if($menu_item->depth == 2) {
$menu .= '<ul>';
$menu .= '<li><a href="' . $link . '">' . $name . '</a></li>';
$menu .= '</ul>';
}
}
// Closing tag for the list
$menu .= '</ul>';
/**
* Set the closing div tag for the menu,
* If you don't want a wrapper div remove or comment this out.
* Don't forget to do the same thing for the opening tag.
*/
$menu .= '</div>';
// Print the menu when using the function
return $menu;
}
/**
* Third part of three of the vocabulary menu
* Use this function in page.tpl.php where you want to show the menu
* Shows only if there is a result
*/
function vocabulary_menu_render() {
if(vocabulary_menu_router() == TRUE) {
print vocabulary_menu_router();
}
}
?>
In your page.tpl.php where you want to show the menu:
<?php print vocabulary_menu_render(); ?>To Do
Please feel free to comment if you see any improvements to the code or method.
Hope it helps you on your way. :-)
DesignDolphin : I appreciate that you are learning a lot...
But I am getting sort tired of getting 12 emails from groups every time you have an epiphany. Could you at least try to refrain from editing comments after you make them (If that is what has been causing all of the emails)
Also, have you checked out http://drupal.org/project/taxonomy_menu ? Yes, it is another module, but I for one don't think that that is a bad thing, this sort of functionality based thing really does belong in a module, rather than the theme.
Topic Closed
I don't know why your getting mails for this topic. Your the second person to mail me, who isn't part of this discussion.
Please contact Drupal groups.
I have no clue why your getting mails.
I'm no fan of Drupal Groups sending a e-mail when an edit is done.
Like I said before in this group, I discovered mails are sent when I edit/ or post for that matter, and am trying to keep edits to a mininum.
Thank you for your suggestion. Please read the comments in the topic first though (I know there long ones, and you may have missed), but taxonomy menu and module route has been spoken already.
Otherwise I think it may better to just close the discussion, and post elsewhere. That may be better, because don't want people's mailboxes to overflow because of a feature. Editing text or code is just something that there can be a need for at times.
Thank you for feedback. Apologies for any inconvenience.
TOPIC CLOSED.