Questions about the buddy list and vB3 without javascript

[Denyer]

Hi, this spins off from: http://www.vbulletin.com/forum/showthread.php?t=135615

I've added the mail address I'm registered with here to the support panel for the vB in question. If there's anything else I need to do by way of verification, please let me know.

1/

How is the buddy list handled for users without javascript? As far as I can see, it's a popup window with no option to show it as part of the control panel display (as was the default with vB2.) If you can tell me otherwise, and point me towards the vB3 options that handle this, I'll be a very happy bunny.

If it isn't possible, I'd love to chat with the developer who thought making functionality reliant upon popup windows an acceptable design decision.

2/

How do I make read receipts being sent the default option—as with vB2—when a user clicks to read a private message? It doesn't seem to be with vB3; users get assaulted with a javascript yes/no question that then attempts to open a popup window.

I suspect the vB2 behaviour is possible in templates if not as an admin option, but I'm entirely new to vB3 templates.

3/

What do I need to include or do to get $forumjump to show on pages such as profile.php and calendar.php? I've been told by others who use vB3 that this global variable isn't supplied to them.

I'm reasonably php literate and should be able to figure out the template system, but only really have any experience of the admin options in vB2.

Thanks,
Stu.

[Steve Machol]

1. I just tested this with my FireFox browser and javascript turned off. Anything that relies on javascript does not work, including all the options in the Quick Links menu.

2. Read receipts are a Usergroup setting: Can Use Message Tracking

3. This requires modifying the code. We cannot officially support code modifications or forums running modified code, however can try searching or asking for help with this over at www.vbulletin.org.

[Denyer]

1. I just tested this with my FireFox browser and javascript turned off. Anything that relies on javascript does not work

Unsurprisingly. However, vB3 provides alternatives within templates for browsers that cannot view the DHTML menus or forums that have them disabled—by adding those options into forms at the foot of pages. In other words, the interface remains functional.

If I'm understanding correctly you're saying that if/when we upgrade, members can no longer use the buddy list feature unless they use javascript and allow popups?

Unless we do something fancy by capturing the php output from the buddy list page into a variable and inserting it into the template.

Read receipts are a Usergroup setting: Can Use Message Tracking

Not sure you've quite got the question. Read receipts are desirable, and we don't want them switched off. However, the way they're handled appears to have changed (quite needlessly) from vB2 to vB3.

In vB2, when you click the link to read the receipt is sent unless you click an alternate link to not send one. In vB3, the receipt is apparently sent at a later stage by the page that displays the message. It seems to do this via a javascript query which spawns a popup window to send the receipt.

eg, vB2 method:

private.php?s=&action=show&privatemessageid=65521
private.php?s=&action=show&privatemessageid=65521&noreceipt=yes

vB3 method:

private.php?do=showpm&pmid=13315 (+ query +popup)

Now, is there any way of passing a variable in the same way, so that I can simply stick a usergroup-conditional alternate read link into the part of the template that presents new messages? (The new conditional template model is very nice, by the way.)

Or is this an instance of vB3 losing functionality that vB2 possessed?

My current thinking is that whatever code is in the spawned popup can probably be called (possibly in an interim page of php if needs be) before the page containing the message.

Indeed, calling this:

private.php?$session[sessionurl]do=dopmreceipt&pmid=$pm[pmid]&confirm=0

...sets the flag, though it's a dead-end to call directly because it's intended to be called as a popup.

An interim page using ob_get_contents on that which then forwards to the message would probably work, no modification of the vB installed files required.

Apologies, some of this has been me thinking out loud, but I'm quite confident that it's possible without having to get into modification of anything other than templates.

[Steve Machol]

I'm not sure I can ansswer any of this for you. As for why the code changed and the functioning of specific code, I'll have to defer to the Developers to answer this.

If you have specific suggestions on what you would like changed in vB3, then please post them in the vB3 Suggestions forum so the Devs will take note.

[Denyer]

No worries. Output for read receipts from private.php can't be buffered conveniently because there's a flush(); in there, but an interim file that includes global.php and the relevant code works fine. I assume major changes to the names of passed variables aren't likely to occur within the 3.x.x development branch, so it should also be reasonably safe maintenance-wise.

The only question now really is how long we want to spend bolting stuff on to try to make the transition from vB2 as seamless as possible for users.

Will go and try to phrase something tactful about functionality being entrusted to client-side scripted popups...