An eagerly-awaited feature for XenForo 1.1, here is a first look at the new thread prefixes system, with a special guest appearance!
It automatically indexes all settings, from add-ons and the core. The system is also completely open, so any data at all can be added to Admin CP search.This. I hate looking for stuff in the options. I'm preying that this has some method of indexing AddOn settings as well, pretty please!
Yet to see, how imported (from VB) prefixes work. Because, we have several HTML prefixes with inline styling.![]()
Yup, same.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.
I have no handson or knowledge about the importing of vb prefixes to xf; Dislciamer.Yet to see, how imported (from VB) prefixes work. Because, we have several HTML prefixes with inline styling.![]()
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.![]()
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.![]()
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):
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.
- Prefix Name
- Text-based Prefix
- HTML-based Prefix
- Order
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![]()
We use essential cookies to make this site work, and optional cookies to enhance your experience.