What URL features do you want?
 

URL's and IMG's in posts

Would you like to see URL and IMG handling improved? There have been various discussions here and there about URL handling in posts and what it should or should not do. The one that bugs me is opening a new window when the content is on-site, which applies to posting links to posts or threads or using [post] or [thread].

Vote away for the features you would like to see and post a little text if there is something not in the poll.

C.C

Mind me asking, but what exactly is this for? I don't think I followed the prior discussions. I might be able to contribute to the poll.

There were no specific discussions per se, just various threads/posts concerning complaints or desires centered around the handling of URL's and IMG's in user posts. My apologies if the poll questions are not self-explanatory.

What's this thread for? vB.org or some site of yours? *confused*

Just a question of other site administrators regarding features they would like to see in vBulletin. Just curious if others find the current [URL] and [IMG] handling sufficient.

As I was going through the poll, I was thinking "I actually could use that." I hope the developers implement almost all of these solutions (although some can be stressful on the database).

Good point. Some of the proposed features would require a query when the post is parsed, but given the relative infrequency of URL's in posts, it would be a small penalty.

As an example, converting the link
https://vborg.vbsupport.ru/showthread.php?t=68398
to
What URL features do you want? (CarCdr)

would, as you point out, require a query on that threadid.

Here are cases of on-site content that could be translated into more friendly looking/acting links in posts. I am not speaking of vbulletin.org here, just using it in these examples. The idea would be to have vBulletin itself translate the links in a more user-friendly way.


THREAD
https://vborg.vbsupport.ru/showthread.php?t=68129
https://vborg.vbsupport.ru/showthrea...0&page=2&pp=10
https://vborg.vbsupport.ru/showthrea...ght=size+limit

Automatically translates to something like
Subject of thread, Username


POST
http://www.vbulletin.com/forum/showt...046#post719046
https://vborg.vbsupport.ru/showthrea...mit#post540678
https://vborg.vbsupport.ru/showpost....06&postcount=1

Automatically translates to something like
Subject of post, Username


MEMBER
https://vborg.vbsupport.ru/member.php?u=4514

Automatically translates to something like
Member: Username


FORUM
http://www.vbulletin.com/forum/forumdisplay.php?f=55

Automatically translates to something like
Forum: Forumname

I tagged tham all, and would only iterate that I'd love to be able to indicate that a link iss "off-site" with a small image - seen this on a number of sites (non-vB).

Great idea - probably possible to offset some of the queries with the datastore...

Good ideas Natch.

Doesn't seem to be much interest though. Our site is testing two simple mod's listed in the above options:

1. Open threads/posts in the same window (not new window).
2. Threads/posts show as titles rather than plain URL's.

I like your idea of something special to mark off-site content, although I am not sure I like the icon idea more than marking the text itself differently (i.e., font or style change).

I really like that idea, and have wondered before if it was "doable". I find myself pasting links for FAQ items all the time, so I'll extend your example with:

FAQ
https://vborg.vbsupport.ru/faq.php?f...q_new_faq_item

becomes
FAQ: Showing up as unlicensed?

Yes but vBulletin hasn't got an AI of it's own. All this stuff would have to be manually coded in, and add to the bulk of the code. More regexp parsing when making posts, more overhead. It's not hard formatting your post to do what you said above you know :)

Dean, with respect, doing the sorts of things we are talking about is what computers do best, not humans. This ain't AI, it's really straightforward machine translation.

The overhead would be pretty insiginificant for the sorts of transformations we are talking about. The parsing overhead for this in a post display cycle is near zero. The only overhead worth considering is when a call to verify_id forces a query. Of course, there is no overhead if the post is in the post cache.

As for bulk, the implementation for parsing showthread/showpost references (e.g., Thread: Title extract... by CarCdr or Post: Title extract... by Dean C is probably 50 lines of code, a very small addition to the many thousands of lines run in a post/thread display cycle.

Cheers

Ahhh.... I never thought of FAQ references. :)

Oh, it's doable. Like I said, we are already testing on-site references for posts. The others are just very similar cases.

Ok so imagine the pseduo code:

I can't see a more efficient way of doing it other than having perhaps a cache of the FAQ entries, that'd be fine for that. But what happens with threads, you have 10 urls in a post, check in one of the caches you might be thinking? Ok, 10 urls to a calendar event, 10 queries?

The fact remains that when you are adding a thread there is going to be a lot of extra processing involved, and on large boards, it's not going to be worth it other than for the sake of a little extra SEO. Can you imagine how much extra server-processing would be involved on a site like OTC :)?

I do think your ideas are good, as the more and more useful your link descriptions are, then the more search-engine friendly they are. So, as long as it's an option and highlighted that it may not be suitable for large boards, then it'll work ok (on small boards).

Dean C, The implementation is simpler than you think...

I can not speak to the FAQ idea, as I have not looked into that one, but I can speak to thread and post links.

1. Late in the processing of the bbcode parser, all links are full (no relatives allowed). All one has to do to know if it is on-site content is check the prefix of the URL -- does it start with $vboptions[bburl]? (1 strpos call)

2. Now all one needs to do to know what type of link it is, is look at the script name. For example, a post link is either showthread or showpost.

3. For these post-type URL's, there must be a "postid" parameter. Simply pluck the id that follows the parameter. (2 and 3 are done with one preg_match call).

4. Now you can call verify_id to get the post/thread information.

5. Return the <a> tag. The original link itself is unchanged. All we are adding is a little text between <a> and </a>.

This only runs if the post is not in the post cache, since it runs at the same time that [ url] tags are processed. I assure you that the cost is insignificant for the normal case of a link in a post. Sure, if a post had many links in it, the processing could become significant.

The added PHP code is not even measurable next to the bbcode parser, which is very large and inefficient, both from a code and a mem allocation point of view.

ps: As for FAQ references, I would compromise and not go any further than taking the reference following '#' in the URL. This would be no overhead as it would only involved a simple string extraction from the URL. It would transform a link like this (spaces added below to avoid URL parse in this post):

[ url] h t t p://www. foo .com/faq.php?faq=vb_read_and_post#faq_vb_email_notifica tion[ /URL]

and transform it to a link that did not open a new window and looks like:

FAQ: vb_email_notification.

this would be SWEET!! https://vborg.vbsupport.ru/external/2011/01/19.gif