Basically what the Title says, after every entry in the Tracker, there's another entry for "Menu Icons CSS" that points to menu_icons/css, and it's extremely annoying. Find a way to prevent it posting a link in the tracker, or don't use a regular Drupal page for the CSS.

CommentFileSizeAuthor
#23 menu_icons.create_css_file.1.patch5.06 KBskilip
#17 ico_crealavoro.png490 bytestoninbardhi
#15 css_break.png53.46 KBSpikeX

Comments

SpikeX’s picture

SpikeX commented

Small update: It appears on my web tracker as the MOST VISITED page on my site, as well.

However you're accessing this CSS sheet, you need to change it, because it triggeres a "page view" HTML-wise, and you need to change it to just be a stylesheet include, using an HTML <link> tag.

skilip’s picture

skilip commented
Status: Active » Postponed (maintainer needs more info)

I'm not abled to reproduce this. Could you please give me more details about on which page the messages are displayed, and which module is responsible for displaying the messages?

SpikeX’s picture

SpikeX commented

Well, obviously it's the Menu Icons module, first off.

It appears in the page tracking in Drupal User > Track > Page Visits (/user/1/track/navigation), as well as in my third party statistics software for the entire site (this isn't even connected to Drupal).

Whatever system is in place to "access" the custom CSS, it can't register as a page hit (as it's doing right now).

I'll provide screenshots if you still can't reproduce this.

grendzy’s picture

grendzy commented

/user/1/track/navigation
Just FYI, that looks like the core statistics module.

Are you using the "popular content" block, or is this only on the admin & user pages?

SpikeX’s picture

SpikeX commented

This is only on tracking on user pages. But, like I said, the statistics module isn't the problem, since my third party software that has nothing to do with Drupal, reports that /menu_icons/css is the most viewed page on my website by about 75%, and that's just not correct.

sethcohn’s picture

sethcohn commented
Status: Postponed (maintainer needs more info) » Active

Current usage IS a link, so I think that's the issue here, not the reverse, and perhaps it should instead be a style @import as the others...

<link type="text/css" rel="stylesheet" media="all" href="/menu_icons/css" />
<style type="text/css" media="all">
@import "/modules/node/node.css";
@import "/modules/system/defaults.css";
@import "/modules/system/system.css";
@import "/modules/system/system-menus.css";
@import "/modules/user/user.css";
@import "/sites/all/modules/admin_menu/admin_menu.css";
@import "/sites/all/modules/admin_menu/admin_menu.color.css";
@import "/sites/all/modules/filefield/filefield.css";
@import "/sites/all/modules/panels/css/panels.css";
@import "/sites/all/modules/cck/modules/fieldgroup/fieldgroup.css";
</style>
grendzy’s picture

grendzy commented

Current usage IS a link, so I think that's the issue here

I'm not so sure... The CSS file is a menu callback, so I think it would register in the statistics module's {accesslog} either way.

Regarding the third party stats... I'm guessing the poster is using something like awstats? In that case, changing the path to menu_icons/style.css might cause most log analyzers to ignore it.

SpikeX’s picture

SpikeX commented

I think two things are at work here (possibly, I'm kind of taking a guess here).

First, the fact that the stylesheet call doesn't end in .css. That's the first problem.

Second, menu_icons/css... does that acknowledge itself as a Drupal page? I mean, when it's called, does it run code that would make Drupal think its its own page? If so, you should rethink that code.

You know what you could do... is have the module write its own .css file, and rewrite it whenever a menu is updated, or on cron runs (if it detects that it needs to be changed).

skilip’s picture

skilip commented

@SpikeX It's not desirable to write it to an actual file, since you'd have to have write permissions for the menu_icons directory. (though it is possible to put the file in the files directory)

Have installed all statistics / tracker modules shipped with core, but still can't reproduce the issue you're experiencing. What 3th party module are you using, that might cause your problems?

SpikeX’s picture

SpikeX commented

Nothing, as far as I can tell? I'm just using Drupal's page tracker that's installed by default (where you can view the most recent pages that someone has viewed in a list). Every other entry is a Menu Icons entry.

I really can't begin to think of what other module would produce this kind of effect... I mean, I have all the basic modules installed like Views, CCK, that sort of thing, but none of that should interfere?

SpikeX’s picture

SpikeX commented
Status: Active » Postponed

I found a workaround that seems to be working.

In the module file, on Line 127, replace the function with:

function menu_icons_init() {  
  // drupal_set_html_head('<link type="text/css" rel="stylesheet" media="all" href="'. url('menu_icons/css') .'" />');
  $css = '<style type="text/css" media="all">
  ';
  $css .= file_get_contents("http://[mywebsite]/menu_icons/css");
  $css .= '
  </style>';
  drupal_set_html_head($css);
}

It's crude, but it works. No longer are you using the Drupal system to include the CSS file, and since you aren't linking to it (without the .css extension), Awstats shouldn't pick it up anymore (we'll see next month when the stats rollover).

I'm postponing the bug since I fixed mine and you couldn't reproduce it on your end.

Still, I highly recommend that you change the way your module accesses the CSS file. The current method is not up to standards.

skilip’s picture

skilip commented
Status: Postponed » Active

SpikeX, then what's the awstats thingy? Is that a module?

I'm moving the status back to active. You must understand we're trying to find a constructive solution here. This is an issue, not a (support-) forum topic.

sethcohn’s picture

sethcohn commented

Actually, it is very desirable to have it written to a file, since otherwise it has to calculate this repeatedly, and it never changes unless a menu change is made (which is when you regenerate it).
I dislike the above workaround (which still isn't going to change your stats issue, just shift it)

Put the file into the files directory, that's why it's there. Then load it as normal css, like any other module does for module based css, and that way, it can be aggregated, cached, etc.

SpikeX’s picture

SpikeX commented

Awstats is completely unrelated to Drupal, like I've already said in this issue.

http://awstats.sourceforge.net/

All it does is track web traffic, and the fact that it was showing an extremely large amount of hits on /menu_icons/css tells me that it wasn't being accessed properly like a regular stylesheet.

How hard would it be to just add ".css" to the dynamic CSS page, making it /menu_icons/menu_stylesheet.css or something along those lines? That might solve a few of the problems here.

SpikeX’s picture

SpikeX commented
StatusFileSize
new css_break.png53.46 KB

Okay, so my previous fix ended up not working... the PHP file_get_contents() will actually hang the script.

I tried changing the extension of the page to .css (make it something like menu_icons/icons.css), but that doesn't help the problem.

What you're doing is registering the page with Drupal, as a page. When you do a hook_menu() and do this:
$items['menu_icons/css'] = array(

You're telling Drupal that's a PAGE, and whenever it's called, the user "hits" it and it gets tracked.

See the attached screenshot for the problem.

Essentially, you cannot make Drupal think this is a page at all. It has to be an actual .css file.

skilip’s picture

skilip commented

That means that AJAX (or AHAH) callbacks are also tracked. That's IMO a bug of the tracking mechanism. However I'll create a fix fir this anyway. It'll be easy to write a css file into the files dir.

toninbardhi’s picture

toninbardhi commented
StatusFileSize
new ico_crealavoro.png490 bytes
SpikeX’s picture

SpikeX commented

... What is this?

skilip’s picture

skilip commented

@SpikeX: I had a little bright moment; did you try to aggregate your CSS files? (admin/settings/performance)

sethcohn’s picture

sethcohn commented

That won't work unless it's done as part of the normal Drupal css methods. Another reason to change this to do it 'properly'.

SpikeX’s picture

SpikeX commented

Some module (may be this one) doesn't like the CSS aggregation method that Drupal implies, whenever I turn it on my site breaks. I just leave it off.

Good idea though.

skilip’s picture

skilip commented
Title: "Menu icons CSS" appears in Tracking after EVERY PAGEVIEW » Use a physical CSS file instead of a menu callback to avoid tracker modules register menu_icon's css
Assigned: Unassigned » skilip
Status: Active » Needs review

This patch fixes this.

skilip’s picture

skilip commented
StatusFileSize
new menu_icons.create_css_file.1.patch5.06 KB

Forgot the patch...

grendzy’s picture

grendzy commented
Status: Needs review » Needs work

Nice! I would consider using an md5 sum for the filename, instead of menu_icons.css. Drupal sets ExpiresDefault to 2 weeks for files, so the browser cache could contain a quite old version of the file.

Also, I think drupal_clear_css_cache() where cache_clear_all() was removed would update the styles for those using CSS aggregation.

Thanks!

skilip’s picture

skilip commented

Hey Grendzy,

Unless you tell Drupal to aggregate and compress your CSS files @ 'admin/settings/performance', the files are added to your xhtml head with a random query argument in teheir paths. e.g.: /sites/default/files/menu_icons.css?Q. This already avoids client side caching of the CSS files. drupal_clear_css_cache() is only useful when aggregating is turned on, while it will only create a new compressed file. So there's no need to do anything with caches in menu_icons ;)

grendzy’s picture

grendzy commented

Good point about the query string.

I'm still not sure I understand what will happen to aggregated CSS files. Won't e.g. 68b329da9893e34099c7d8ad5cb9c940.css become stale when menu_icons.css changes? And if so, shouldn't the aggregated files be rebuilt whenever an icon updated?

Or, there's drupal_add_css(... $preprocess = FALSE)

Am I missing something else?

SpikeX’s picture

SpikeX commented

Arg, patch files! What is this community's obsession with patch files. I don't understand them, I can't use them (I'm on Windows, what am I supposed to do?), and I've already modified my menu icons module file pretty heavily, so wouldn't that ruin the patch anyway?

Maybe I just need a better explanation of what they are, I dunno.

skilip’s picture

skilip commented

@SpikeX: http://drupal.org/patch. In IRC #drupal there are dozens of guys willing to help you with it (including me).

grendzy’s picture

grendzy commented

Apply patches on Windows:
http://drupal.org/node/60179

mshepherd’s picture

mshepherd commented

Any news on this? Does the patch on #23 work OK? When it will it committed to the release? I too have an aversion to patches. While I can use them, I'd prefer to run a proper version of the module, rather than a patched one.

mshepherd’s picture

mshepherd commented

I think this is also causing a problem with the devel module:
http://drupal.org/node/596238

binford2k’s picture

binford2k commented

This just indicates that you don't know what a patch is. A patch simply contains the differences between two versions of a file. A patched version of a file is identical to what you call a "proper" version.

Our "obsession" with patches is that they are more efficient. They are much smaller, and contain *only* the differences. That means that if I want to see what changed, the patch will show me.

It also means that you can apply the patches by hand. Open the file it refers to, delete all the lines shown with a - in the patch and replace them with the lines with a +.

The only drawback to patches is that sometimes the developers forget to apply them to the released version of the module. hint, hint.

skilip’s picture

skilip commented
Status: Needs work » Fixed

Release 6.x-2.1 fixes this. A physical file is created and placed in the files directory you specify in the Menu icons settings.

SpikeX’s picture

SpikeX commented

I was having some issues where the second page call to the CSS file created overhead, since Drupal would re-load everything essentially twice (once for the page, once for the pseudo-CSS call). I had to remove this module because it was slowing down my site so much (I used Devel to track down the culprit and it ended up being this module, unfortunately).

But now that you've created an actual .css file and are including it instead of calling a Drupal page, I'll definitely give 2.1 a try. Thanks for the update! :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Pushkar Gaikwad’s picture

Pushkar Gaikwad commented

So what was the solution ? I am not using menu icon module but still tracker is filled with this menu icon css log entries, can someone tell me what to do to stop it ?

SpikeX’s picture

SpikeX commented

If you aren't even using this module, why did you post here? Obviously some other module you have installed is creating these entries. You should find out what it is, and disable it, or submit a bug request to that module.