Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Comment Links

24

Comments

  • Fatal error: Cannot redeclare commentlinks_addlink() (previously declared in forum/extensions/ReportPost/default.php:18) in /forum/extensions/CommentLinks/default.php on line 76

    Posted: Monday, 9 April 2007 at 9:16AM

  • heheheh 2 extensions using same namespace
  • Wallphone, thanks for the reply.

    I have the latest versions (as of this writing) of HTMLformatter and ExtendedTextFormatter installed and enabled. I have confirmed that both extensions work fine to format text in my forum. And yet, I wasn't seeing the "HTML" option on my Mac at home. I say "was" because on my Mac here at work now, I see both "text" and "HTML" options. Its odd. Because this is the same exact Mac I use at home, with the same 10.4.9 OS version and the same version of Safari (and Firefox). Perhaps I just need to restart my Mac at home, which I will try later this evening.
  • You know, that just had to happen while Mini was on vacation.

    Just for the record, I had that function name first!
  • I renamed that function and it worked but still the problem persists in Safari where the menu only works once for each comment.

    Is something not closed, finalised, flushed?
    Maybe it's a Flash issue.

    Posted: Monday, 9 April 2007 at 1:44PM

  • Hi, Code Prettify don't work after enable Comment links, I guess it may be a prototype problems (Prettify is use prototype too).
    Is that right? :P
  • Actually, CommentLinks uses the body tag attribute onload="" to save some values into javascript variables, and Code Prettify attaches to the onload event with Javascript--like a good script should.

    If you remove the code from CommentLinks that toys with Body->Attributes, and replace it with a $Head->AddString similar to how Prettify does, then they will play nice together.

    I will plan on getting these both updated this weekend.
  • Thanks, wallphone. :)
  • Man I didnt realise I hadnt changed the namespace references...
    Would someone be so kind as to remind me to do that when I can keep my eyes open for longer than a few minutes at a time?
  • It does not seem to work with issue-tracker...
  • MarkMark Vanilla Staff
    Found a bug with this extension where it will requery the comment table for every comment on the page when viewing discussions with multiple pages. Had someone email me about it when a 32 page discussion was insanely slow the further into it you got. Did some extension switching on/off and discovered that this extension is the culprit. I haven't looked into it any further than that.
  • MarkMark Vanilla Staff
    Ahh - I see it's where you look for prior whispers && deleted comments.

    I wonder if there's a better way to do this?
  • Yep, thats needed to properly number comments on subsequent pages...

    Maybe something like SELECT COUNT (*) FROM lum_Comment WHERE DiscussionID = x CommnetID < y AND WhisperToUserID > 0 OR Active > 0

    where X is the discussion, y is the comment id of the first comment on that page... we must TEST! ::laughs like an evil scientist::
  • MarkMark Vanilla Staff
    Thought about this some more overnight. Why not use the Focus querystring parameter like the search page does? The way that one works is: you give it a comment id and the discussion id like this: http://lussumo.com/community/discussion/5649/?Focus=70586#Comment_70586 What that will do is search through discussion 5649 until it finds a page with comment 70586 in it and then it will stop and jump down to the inline anchor #Comment_70586. That way you don't need to do any extra queries - it is all handled during the focus.
  • I didin't use focus because it requires a discussion ID, and I wanted a method that would always link a comment in case it was moved from one discussion to another. Also wanted links that wouldn't break if friendly URLs is later turned on or off.

    side note: focus reveals a bug in comment links: this page starts numbering comments from 1 despite the comment being on page 8. I know its possible to fix that, but have been too busy lately to do much non-work related coding.


    Regardless, using focus still wouldn't speed up loading large paged discussions. Commenting out lines 84-98 (if block after 'count the whispers' comment), then setting $Number = $Context->GetDefinition('CommentLinks_Permalink'); on line 104 (just before 'uncounted comments should not be numbered' comment) will remove the numbering and its calculations and speed up the comments page loading.

    I got some promising results with some ad-hoc SQL, still need to test on a discussion with more than two pages... also should use the date posted time instead of CommentID in the where clause. I suppose it would be a good idea to make this an option in the next version, so that it can run without any extra DB queries.
  • Comment Links broken in Safari 3...
    Fatal error: Cannot redeclare commentlinks_locatecomment() (previously declared in /path/to/forum/extensions/ReportPost/default.php:45) in /path/to/forum/extensions/CommentLinks/default.php on line 135

    Posted: Wednesday, 13 June 2007 at 8:50AM

  • I think you'll find that issue arises from use of the ReportPost extension and CommentLinks at the same time cause I was too lazy to rename the function names used to locate the comment. I'm pretty sure i fixed it in the latest version of ReportPost though...?
  • Yah, I took a look, its fixed in Report Post 1.1

    Javascript bugs that keep the copy menu appearing a second time are still around in Safari. Maybe with this Safari for Windows I will be able to squash them.

    Wanderer, didin't you have problems with CommentLinks causing slowdowns also? Were they on discussions with many comments in them?
  • I am happy to say that Comment Links (tested on this forum) works perfectly with Safari 3! (The copy menu appears every time!)

    I'm not sure Comment Links was the cause of the slowdowns, it might have been coincidental.

    Posted: Thursday, 14 June 2007 at 5:06PM

  • MarkMark Vanilla Staff
    I didn't use focus because it requires a discussion ID, and I wanted a method that would always link a comment in case it was moved from one discussion to another.

    Well, considering that isn't a feature of the core package, I wouldn't concern myself with it - unless I was the author of an extension that allowed such a feature.

    Also wanted links that wouldn't break if friendly URLs is later turned on or off.

    It won't break if you use the GetUrl function.

    Regardless, using focus still wouldn't speed up loading large paged discussions.

    Yes it would - because there would be no need to parse through previous pages looking for inactive or whispered comments - this parsing would be done on the fly by the focus after the click.
Sign In or Register to comment.