XF 1.1 Thread Prefixes

An eagerly-awaited feature for XenForo 1.1, here is a first look at the new thread prefixes system, with a special guest appearance!

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
Yet to see, how imported (from VB) prefixes work. Because, we have several HTML prefixes with inline styling. :)

That can be tricky as people can create styles with vB prefixes in a few different ways. Perhaps it would be just easier to import the text and then have the user select their own styles. Otherwise the only thing I can think of would be some sort of "find function" that could look for inline styles (style=""), create a new class based off the CSS attributes within that inline style and then apply that class to the imported prefix. But perhaps I am over thinking this.

K&M are far more clever and better suited to problem solve this one.
 
On a particular forum I co-admin on, we use vb and have mini thread prefix icons...

I'm looking to move this over to XF as well, and wanted to know if the thread prefixes for 1.1 also support small images in some way for display?
 
That can be tricky as people can create styles with vB prefixes in a few different ways. Perhaps it would be just easier to import the text and then have the user select their own styles. Otherwise the only thing I can think of would be some sort of "find function" that could look for inline styles (style=""), create a new class based off the CSS attributes within that inline style and then apply that class to the imported prefix. But perhaps I am over thinking this.

K&M are far more clever and better suited to problem solve this one.

Ha ha ha ha..... You really do. :-)

In fact some of our prefixes are using <img> tag. I was thinking, if HTML prefixes can be imported as such and plain/custom styling option is applied (that will work without adding anything in the CSS in the first place.) later we can edit those manually to make it more XenForo-ish. :)
 
Yet to see, how imported (from VB) prefixes work. Because, we have several HTML prefixes with inline styling. :)
I have no handson or knowledge about the importing of vb prefixes to xf; Dislciamer.

I think the raw data can be imported as such and would afterwards need to be "updated" from ugly html4 with inline css to a one liner modern html5 css(3) line.

<table> with a row, and inline css to align text and color things.

Can simply be a prefix.myownone { this: that; and: another; } on top of the existing prefix data that it imported.
It will probably end up looking even better. As the video has demonstrated.

A great time too for site owners to rethink a) which ones they have. b) which ones they need and especially which ones they don't need, c) and if they want to tweak the ones they are going to be left over with to something that their members will go 'omg zoo much nicer'.
 
HTML prefixes from vBulletin will not be imported - we import only the text-based version of the prefix. However, most of the visual styling that would have been achieved with HTML can be achieved with CSS.
 
HTML prefixes from vBulletin will not be imported - we import only the text-based version of the prefix. However, most of the visual appearance that would have been achieved with HTML can be achieved with CSS.

That means, we better start working on modifying our existing prefixes and make them TEXT ONLY as a step forward to safely migrate all the thread prefixes to XenForo-1.1. Later we can apply existing or custom style to the imported prefixes in new system. That would be a bit of work though, but worth doing it. Because, I strongly believe in keeping Data in HTML and Presentation in CSS. :-)
 
That means, we better start working on modifying our existing prefixes and make them TEXT ONLY as a step forward to safely migrate all the thread prefixes to XenForo-1.1. Later we can apply existing or custom style to the imported prefixes in new system. That would be a bit of work though, but worth doing it. Because, I strongly believe in keeping Data in HTML and Presentation in CSS. :)

Why would you need to do that? I haven't used vB in a while but I believe you can supply text-based and HTML based prefixes. If you have been putting text-based prefixes in as well (which people should), you don't really need to do anything.
 
Why would you need to do that? I haven't used vB in a while but I believe you can supply text-based and HTML based prefixes. If you have been putting text-based prefixes in as well (which people should), you don't really need to do anything.

Usually, when you extract text from HTML content, only text nodes are fetched. All attributes on any HTML tag will be lost. That means, If we have a prefix like <img src="path/to/something.png" title="something", style="foo:bar;" /> then we are going to get nothing out of it. :-)
 
Usually, when you extract text from HTML content, only text nodes are fetched. All attributes on any HTML tag will be lost. That means, If we have a prefix like <img src="path/to/something.png" title="something", style="foo:bar;" /> then we are going to get nothing out of it. :)

Hmm, maybe I am missing something. But this should have nothing to do with the HTML prefix? Unless for some reason you posted the image tag into both the text-based and html-based prefix input fields in the vB backend. Which would be silly. Within vB I think there are a few fields (if my memory services me correctly):
  • Prefix Name
  • Text-based Prefix
  • HTML-based Prefix
  • Order
Now, I believe Kier is saying that when the importer goes through it's normal process of moving data over, it will only grab whatever you have put into your "Text-based Prefix" field. If nothing is there then nothing will be imported. So yes, if it's blank you have work to do, but it should have never been blank in the first place.
 
You guys rock so hard that i cant believe it, GREAT FEATURE, i can think of a thounsands wways lto use it, one being deals and shop forums for. Buy, sell prefixes
 
Hmm, maybe I am missing something. But this should have nothing to do with the HTML prefix? Unless for some reason you posted the image tag into both the text-based and html-based prefix input fields in the vB backend. Which would be silly. Within vB I think there are a few fields (if my memory services me correctly):
  • Prefix Name
  • Text-based Prefix
  • HTML-based Prefix
  • Order
Now, I believe Kier is saying that when the importer goes through it's normal process of moving data over, it will only grab whatever you have put into your "Text-based Prefix" field. If nothing is there then nothing will be imported. So yes, if it's blank you have work to do, but it should have never been blank in the first place.

Thanks for reminding me all that. Long back since we setup the prefixes, I did not have a chance to look at prefix manager in VB. Now, when you point out that the text based and HTML based tags always exist in parallel then I realize that (and confirmed in ACP as well). :-)

Aaaahhhh, Now I need to take a deep breath. Well, we will still modify our tag after migration, because our text based prefixes have [square brackets] around them, that is no more needed. :-)
 
Excellent addition. And I just saw that sweet new admin search drop down, so awesome!

Only thing that I would like to see added would be a select all|deselect all for the check boxes for user groups or make it a multi-select drop down. Other than that, great job guys! (y)
 
Mike, you blew my mind... not with the prefixes just with that quick thread edit. I've NEVER noticed that before... haha. But prefixes are pretty sweet. :)
 
That's why i hoped that we will be able to use more thread prefixes at once.

Then we could have "WIN 7" Prefix for the thread and once it's solved it would have "SOLVED" "WIN7".
So we would need to remove the existing WIN7 prefix and replace it with solved

Another way is to have the normal prefixes + create for every normal prefix a solved (for example:

win7 Problem
win7 Problem solved
win vista
win vista solved

but that's IMO to much copy & paste work + this would result in too many unnecessary prefixes:(

A while back when I was helping a gaming community we had a similar problem structuring our game discussion forums. The idea I came up with (but never implemented) was sort of a double prefix system where you could tie a primary set of prefixes to a secondary set. So for instance you could have "[[Windows] RTS] StarCraft II" and you could change Windows and RTS independently. So it would have been like using multiple prefixes, but there would be relationships between sets.

This would have the benefit of more specificity at a glance, prefixes wouldn't have to be exhaustively defined, and relationships could be set in place, for instance in a project management forum where "Fixed" wouldn't go well with "Feature Request" but it would with "Bug". Of course having never implemented this I couldn't tell you if it would have ever worked out or not. In some circumstances it makes sense, but in most others it would sort of defeat the premise of categories and forums.
 
Back
Top Bottom