Makes the Google analytics pagetracker print twice (need to remove the reset of $closure from preprocess_page)

in cufon.module, line 112, remove:

$vars['closure'] = theme('closure');

seems to have no effect on the module, cufon fonts still displaying and no second GA codeblock output. haven't really tested thoroughly though.

Thanks. Worked for me too.

Awesome ... thanks!

Removing that line also works for me. I attached a patch.

#734630: Cufon module disables $closure in preprocess_page function

The patch from #5 is better than the one in that issue. Also, this is older.

Loss of $closure is a major issue for many people, so escalating.

It's been almost two months since the last post. Two different threads listed above have provided the necessary solution to fix this bug, and it's been RTBC. PLEASE PLEASE PLEASE roll this into a new release as soon as you can!

I'm marking this as critical because it affects the performance of another module. It skews Google Analytics stats (and any other modules that rely on having a tracking code at the bottom of a page). Many individuals and companies rely on these statistics to track how well their website is performing. This is especially true for eCommerce sites.

So what's going on here anyways?

Looking for 6.x maintainer. I can only do 7.x stuff.

I can maintain 6.x branch.

Prepare some patches for 6.x... :)

It's fine with me, but I don't know what Jeff has to say as he is Cufon head maintainer.

Thanks populist, #5 works a treat. Took me about 10 seconds searching to find this thread, very useful.

The issue ground to a halt after that. troky #13, could you ask him? Or at least point people in the right direction? Who's Jeff?

I know 6 isn't being supported but in #11 you say you're looking for a maintainer. You get an offer from Mohammed, then your reply in #13. To quote a previous poster: "So what's going on here anyways?"

I think JeffBurnz may have been on for a bit, but didn't make any commits. @troky, are you saying that you wouldn't accept Mohammed as 6.x maintainer w/o seeing some prior work to confirm that he would be a good maintainer? Seems reasonable, but probably best to accept anyone at this point, since this bug has effectively killed the 6.x branch for many people.

Does the issue not exist in 7.x?

I don't use D6 and I don't have time to deal with 6.x version.
If someone wants to maintain 6.x branch please contact me privately.

mh, I understand that it would be acceptable for you not to provide any new features for the D6 branch, but saying that a version of the module with 2500 users is not supported anymore because what.. there is a newer version that has less than 500 users? I mean come on, that's just unprofessional :x at least the critical bugs should still be fixed.

I took over this module because I needed D7 version so I made it. I've never used D6 nor made any modules for it and I don't have time for that but I fully support D7 version. From point of view, D6 version is abandoned until I find maintainer for that branch.

You say this is unprofessional? Well, yes it is... I am doing this for FREE in my FREE time so please, if you don't have something constructive to provide wait for somebody to do job for you.

hey hey, no need to get upset, if you just said you took over to port the module to D7 I would've had no complaints.

And I fully appreciate anyone who's providing these modules, it's just extremely annoying to see the amount of modules with several thousand of users that are generally abandoned. IMO it shows that the person who started working on the module did it more out of personal interest, i.e. to enhance their cv, or impress an employer, rather than real will to contribute to community.. I maintain several modules myself so I think I'm allowed to make this rant.. anyway, way off topic.

Just to get an idea - do you have someone in line who might take over the D6 branch?

Just to get an idea - do you have someone in line who might take over the D6 branch?

Unfortunatelly, no. Do you want to jump in?

Well, I would consider it, but I'm really bad at JS (and really dislike working with it), so I'm afraid I wouldn't be a good man for the job.. I'll ask my colleague who is a JS/CSS guru, if he fancies it I could come along to help out with more Drupal-related coding issues..

JS is not a problem here... I believe it doesn't need te be changed but if it does, I can help.

I need someone familiar with D6 modules and git who is able to commit some patches and test the module.

well, looking at the list of d6 issues most of them relate to js/css.. and I wouldn't feel comfortable maintaining a js-focussed module where i dont even have all the browsers to test it :) Anyway, hope you find someone. Good luck.

There's no reason cufon should be rebuilding closure or scripts -- it should just run *before* template_preprocess_page, which is actually quite easy to do considering hook_theme_registry_alter allows reordering of preprocess functions.

Patch does that + moves other js additions into same place, and the misplaced requirements check from hook_init into hook_requirments to get rid of hook_init

Needed to remove some copy and pasted comments

Committed to 6.x-1.x-dev.

Re-open issue if problem persists.

Bug in previous patch leads to cufon undefined errors :/ Sorry

I believe this patch is obsolete. Check 6.x-1.0-rc1