I'm using this Site_map in combination with Slickmap CSS. They work together perfectly! No module code hacks needed, only pure CSS addition!

To make it work:
1. get slickmapg package: http://astuteo.com/slickmap/
2. use my modified slickmap-drupal.css (attached)
3. add css to your template.php:


(change your location)

Pure CSS addition! Nothing to code/hack. But you get a beautiful visual sitemap!


new1.39 KB

Please use this attached slickmap-drupal.css file.It fixes two little details.

new1.28 KB

Use THIS one, sorry, but this one is final!

Would it be a nice idea to suggest that there might be some way to optionally add this on certain pages? The sitemap is generally just one page per site, so how do we restrict it to that page?

Status:Active» Needs work

Awesome. Usable now, if we had some sort of tickbox flag in admin saying something like "Use SlickMap CSS" to switch it on and off it would be even better! =)

I might take a look at this today if I get a sec - shouldn't take long.


this is a very nice idea, and the sample pages look really great.

However, for a Zen-based sub-theme this seems not to work out of the box (after clearing the theme registry and caches, the formatting of ./sitemap is changed, but the visual map does not show up). Also it's not quite clear why you're embedding the stylesheet in template.php (the place for PHP preprocessing) and not in [THEME].info (to my understanding the place to add additional stylesheets to a theme).

Thanks & greetings, -asb

Slick indeed! I will test this during the weekend.

I will not make it the default, but add an option to activate it in the site map settings.

Rather than altering the original module, wouldn't it make sense to add a smaller add-on module that performs a brief hook_form_alter in the site_map module config, saving its own settings and doing the necessary theming and css additions via the medium of module-specific theme preprocess functions...?

I would agree if the maintainer was nowhere to be seen and we were talking integration, but he's very much present and volunteering to add the feature (#6) so why not? It's just a CSS file. People can attach CSS wherever they like anyway in template.php if they wish. I don't see a problem with optionally showing the module's default site map page (/sitemap, AFAIK?) with the SlickMap CSS applied via a tickbox as a feature of the module, for people who want to write no code whatsoever, personally.

Quick follow-up - to add SlickMap CSS in to any page on your site (for advanced users) this might be useful:

Assigned:Unassigned» frjo

I have had a look at the code from #2. It looks promising but needs work. The slickmap CSS needs to remove more drupal/theme styles and it should be made not to interfere with other parts of the site map. It also looks like it should be possible to streamline it a bit.

When I have had time to work with it a bit I will commit it to 6-dev for other to try out.

There will be a setting to activate/deactivate the slickmap style.

I do net see why this need to be in the project. Every theme is able to override the standart site_map.css by adding the above to the theme folder... so no need to do anything in the module at all! I would only add a comment to the readme.txt about this nice CSS and that's all.

By design.

Aside - all images linked in the CSS are missing in the ZIP.

Title:Feature: add "Slickmap CSS" for visual sitemap!Feature: add ability to select site map CSS from a shared directory using admin options ("Slickmap CSS" could be one included!)
Version:6.x-1.0» 6.x-1.x-dev

@hass: But you're thinking as a theme developer. You can't *assume* everyone is comfortable with applying their own CSS to stuff. A SlickMap checkbox in admin would be a nice feature for non-devs.

Thinking of which, perhaps we could expand the scope of this? What if there were a directory you could just drop CSS files in to. Say sites/all/libraries/site_map/css. The module could pick up the file names of all the CSS files in that directory and list them in a drop-down in admin. You select the one you want to use and the module does the drupal_add_css('path/to/selected/file.css') for you in a template preprocess function. That would be truly awesome! Not only would it allow people to start developing "skins" (just single CSS files) for site maps, you could include some in the package. And anything you didn't include, even a total novice could download the file from the issue queue and drop it in their sites/all/libraries/site_map/css directory to skin their site map.

What do you think? Changing title to suit. I don't mind having a crack at this, if you like? =)

Go greg.

If you would ask for such a feature in core I'm pretty sure it would get a won't fix/by design as we all know that theming is the way to override things. Is it really tooo difficult to copy and paste the CSS file to a theme?

Assigned:frjo» greg.harvey
Status:Needs work» Needs review
new4.9 KB

Then go I shall... patch attached. Please review.

@hass: You must've missed the whole usability stuff they've been plugging for for D7. Yes, it really *is* too difficult for most of the people in the world to copy and paste a CSS file to their theme and add the appropriate PHP to template.php/a module. Because most of the people in the world are *not* (not even slightly) programmers, themers or have any experience of doing anything remotely similar. Why make them suffer?

Furthermore, why would you obstruct a patch that makes *no* difference to your personal experience of the module but potentially makes it a better experience for others. I don't understand...? =/

@greg: there is no need to add anything to template.php. Only copy a new site_map.css into the theme folder and that's it. If people cannot copy one file - how have they installed Drupal or the sitemap module?

Don't get me wrong. I'm not against usability, but I think the module should not implement it's own "usability" in the module. D7 does much for usability, but it doesn't mean that every module should have 100 custom CSS files and the theme system is no longer used and we are in D6 now. This change only cripples the module and theme system, nothing else.

Status:Needs review» Needs work

http://api.drupal.org/api/function/file_scan_directory/6 should be used only. I'm not sure about realpath here. Don't waste time... wait for the maintainer if he is willingly to break with the theme system before re-rolling again and again.

I think "break the theme system" is a bit of an exaggeration. drupal_add_css() has no purpose if using it breaks the theme system. If you copy the CSS to the theme directory you need to add it to the theme's .info, no? Or perhaps I'm missing something? Also, how do you tell it to only load on the site map page? You don't want to load that CSS on every page - only the site map page. =/

Edit: To clarify what I mean precisely, drupal_add_css() exists so modules can inject CSS in a fine-grained manor on the pages where it is needed and nowhere else - that's the whole point of it - you don't need to load unnecessary CSS on all pages. You can fudge it using template.php or in a tpl file, but that is NOT what the function is for. The purpose of this patch is to keep that fine-grained injection of CSS, only where it is needed, but give the novice user the ability to select the CSS file they wish to inject by simply copying it in to the correct folder. That is why, IMHO, it is not breaking the theme system. It is using the tools available correctly and making it simpler for novices to do so. =)

Seems like you are right... this must have changed somedays and I missed that... in the beginning of D6 it was only required to add the file to the folder... looks like a bug to me.

Re: realpath, I was just trying to get to the system path of the Drupal installation so I could work to the libraries folder from there. Do you know a way, other than realpath, to reliably determine the /path/to/this/drupal/site using the Drupal API? I couldn't find anything... =/

Also, for some reason all the file.inc functions seem to assume the directory being worked in is either within Drupal's tmp or files directories, which is no use as neither is the case. I kind of gave up on using them because they kept returning FALSE because the directory is outside of files. I'm not sure about file_scan_directory() though - I didn't try that one. I'll test it now.

Status:Needs work» Needs review
new4.92 KB

Ok, file_scan_directory() works great - thanks for that. New patch attached. =)

Still not sure what to use instead of realpath(), but if there's an API function to achieve the system path I'm happy to substitute the PHP equivalent.

Actually, use this patch - occurred to me it *might* be useful to be able to easily alter the path to the CSS files, so made the Drupal path a param of the _site_map_get_css() helper function. Not essential, but seems silly not to do it.

Sorry, last patch - I'm going to get on with something else - but re-reading the code the form bit could be smarter. Slight revision attached (doesn't have the field description twice, only once - if statement moved to only be generating the options array, not the whole field).

I cannot take a look nowbut check out wysiwyg module…

Ok, I'll check it out later. No time myself right now. Half way through an evil import to Drupal job. 42,000 XML documents! =/

Status:Needs review» Needs work

I missed to note Libraries API http://drupal.org/project/libraries... this is the clean way for the libraries. Nevertheless I believe this is a core bug... I will try to install a Drupal 6.0 and check out in what version the auto detection of CSS files have changed.

Ok, I'll be curious to know your findings. I never realised Drupal *ever* was smart enough to allow you to add a CSS file to the theme and have it only appear where the original module specified it. That's a cool feature and armed with that I totally see your point. =)

Yeah, tried it now with 6.0, but doesn't work... it must be a dream I have had... or missread documentation... or it was a discussion about and I never realized this is not yet implemented... I can only guess... sun's case is marked as "bug"...

Hmm, the Libraries API is very thin at the moment and only a dev snapshot. I think *if* this patch is accepted by the maintainer then "Integrate with Libraries API when a production release is available" would be a sensible feature request. I won't create a dependency on a dev snapshot. It would put many people off using the module.

Leaving as "needs work" because I'm yet to check out alternatives to the PHP realpath() function.


Status:Needs work» Needs review

Setting back to "needs review". The realpath() stuff works and I haven't found a "proper" alternative. It can always be "fixed" by another patch later, if necessary. Libraries integration can be added later, or we're kitten killing. Let's get this rolling! Pointless to let the good get in the way of the perfect, as the saying goes.

@hass Thanks for the review and helping to thrash out ideas so far!

@asb Can you review yourself apply this to the dev snapshot if you think it's ok?

#27 is the patch to try. Thanks! =)

I still think, this is not the Drupal Theming way... :-(


@greg (#35): I'd like to help, but haven't followed the latest development and dev-snapshots. Should this now be a "one checkbox" solution (meaning: should this be integrated in the dev-snapshot), or do I need the Libraries API, or is it still a "roll your own" approach?

Having that said, the patch from #27 applies cleanly against the current dev-snapshot 6.x-1.x-dev from 2009-Oct-15 (quite old, though). There is a "Site map CSS file" at ./admin/settings/sitemap where I can choose between "none" an "default" after clearing the Theme registry.

I have installed the CSS file from #2 at ./sites/all/libraries/slickmap and downloaded the package from http://astuteo.com/slickmap/ into the same folder. Also I added drupal_add_css("sites/all/libraries/slickmap/slickmap-drupal.css"); to Garland's template.php. That gives me the look as in the screenshotattached (not quite what I would expect ;)

Also I downloaded 6.x-2.x-dev from 2009-Dec-07 and tried to run the patch from #27 against it, but this fails:

# patch < 514436-css_selector-improved_form_code.patch
patching file README.txt
Hunk #1 succeeded at 43 with fuzz 2 (offset 2 lines).
patching file site_map.admin.inc
Hunk #1 FAILED at 125.
1 out of 1 hunk FAILED -- saving rejects to file site_map.admin.inc.rej
patching file site_map.install
Hunk #1 FAILED at 20.
1 out of 1 hunk FAILED -- saving rejects to file site_map.install.rej
patching file site_map.module
Hunk #1 succeeded at 91 (offset -5 lines).
Hunk #2 succeeded at 588 with fuzz 2 (offset 45 lines).

So this seems to apply only to 1.x, as the issue tags suggest ;)

Greetings, -asb

new25.02 KB

Well, I wrote a long reply then d.o threw a fit and lost it.

@asb: basically, what you see sounds right. Sounds like it works fine. No need for Libraries API - it's a dev snapshot and hasn't been touched for months, so I doubt we want a dependency on that. Doesn't look like a well maintained, or even stable, product.

So, I know it's the wrong way around, but if you like the patch you could apply it to 6.x-1.x-dev so it goes in to 6.x-1.3, whenever that might be, and mark this up as "6.x-2.x-dev", "needs work" so we can set about a 2.x patch?

new1.28 KB

For Zen css-file from morningtime has redundant tags

Change in css:
instead .site-map .sitemap-menu .content .menu
use #site-map .site-map-menus

or download file