-
This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Random Questions Answered
- Thread starter Kier
- Start date
- Status
A: For the simplest answer, turn off Javascript and refresh the forum list. You'll see that the forum descriptions start off right where they normally are on a forum, right under the title. It is Javascript that operates when the DOM is complete that moves the descriptions into a tooltip, so search engines should find the forum descriptions right where they expect to find them.
HTML:
<div class="nodeText">
<h3 class="nodeTitle"><a href="forums/announcements.2/" data-description="#nodeDescription-2">Announcements</a></h3>
<blockquote class="nodeDescription baseHtml" id="nodeDescription-2">If XenForo customers need to know something, it will be posted in here.</blockquote>
<div class="nodeStats pairsInline">
<dl>
<dt>Discussions:</dt> <dd>1</dd>
<dt>Messages:</dt> <dd>2</dd>
</dl>
</div>
</div>A: No. XenForo is able to use multiple password and authentication schemes and these can be defined on a per-user basis. If you import from a system that uses md5(md5(password) . salt) as its password hashing scheme, XenForo will allow that user to authenticate using that scheme.
A: http://xenforo.com/community/threads/importers.221/#post-2073
A: We are using the following conventions:
We use camelcase for PHP variables and functions, and underscores for class names and tables and fields in the database, so it's easy to see in the code what you are dealing with.
Variables: $myVariableName
Functions / methods: myFunctionName()
Classes: My_Class_Name
Database fields: my_database_field
Example:
PHP:
My_Toaster::makeYummyToast($hungryUsers, $availableCondiments['peanut_butter']);A: I think it is absolutely vital to have that confirmation dialog - clicking that link by accident can do major damage to your browsing session if you are trying to ensure that you have paid attention to all threads.
http://xenforo.com/community/thread...ll-forums-read-really-needed.2626/#post-38305
A: Everything in XenForo is designed to encourage posting and participation, even to the point of styling the quick reply area to look as though you have already started to play a part in the discussion.
http://xenforo.com/community/thread...ar-next-to-quick-reply.2459/page-2#post-36973
A: There isn't really a 'My Account' page as such, it's just a wrapper we place around a bunch of functionality that is available to registered members only.
To access the 'My Account' area, use the [Your Username] menu on the right of the navigation bar - Pretty much any of the links under the username menu are entry points to 'My Account', and clicking your username again with the menu open will also take you to 'My Account'.
http://xenforo.com/community/threads/no-obvious-way-to-access-your-account.2646/#post-38301
A: If you are a guest, it does.
If you are a registered member however, it makes use of the read-marking system that keeps track of threads you have read and will take you to the first unread post within that thread. It works identically to the 'Go to first unread' button in both vBulletin and IPB.
If you want to access the first post in a thread, regardless of its read state, simply click on the start date.
The thinking behind this behaviour is that for the majority of people, it makes sense to jump to your first unread post. Given that this is the most commonly-intended action, it follows that this should be the primary link in the thread list, rather than a small button that is more difficult to click.
Edit: Aug 24, 2010
Note:
If the system considers that an entire thread has been read, clicking the thread title will open the thread from the beginning.
A: In connection with the feature described above, XenForo maintains records in the database to keep track of the threads and forums you have read, allowing us to direct you accurately to new, unread posts in threads. However, tracking this information requires a record in the database for every thread that you read, and when you multiply the number of threads on a board by its number of users, this can grow very large.
To work around this, XenForo utilises a cut-off period, after which all content is considered to be read, whether you have actually seen it or not. This allows the amount of stored read marking data to be kept at a manageable level, but it does come at the price of old threads being marked as read without actually having been read. In normal operation this is rarely a problem.
Q: Can I increase the read marking data lifetime on my own board?
A: On a very busy board with a high turnover of content, setting a high limit could result in very large quantities of data and a possible performance penalty - however on these kind of boards there tends to be less thread necromancy, so the problem is mitigated and a smaller timeout is less of an issue.
On a small to medium board that has plenty of disk space and doesn't tax its server, you could easily set a timeout of a few months without a problem.
Q: Why does the XenForo thread preview require a request back to the server, and why not use a standard browser tooltip?
A: Here is our reasoning:
- Using a standard browser tooltip means that even rudimentary formatting such as line breaks can not be reliably reflected in the tooltip. Text formatting such as emboldening and italicising is completely out. With our implementation as it is now, it is a relatively straight forward template edit to dramatically change the way that the tooltip looks.
- Fetching the post snippets with the page would require that they are output to the browser regardless of whether or not they are going to be viewed, resulting in potentially much larger amounts of data being output to the browser, affecting both bandwidth usage and page loading speed. This however is insignificant when compared to...
- If first post snippets are to be fetched along with the list of threads, it requires joining the post table to the thread table in the SQL query that grabs the list of threads. This has a major performance penalty and we decided not to do it for the sake of thread previews that are often not going to be seen.
A: At the risk of simply stating what has been said before, consider our situation.
Right now, we have our base product at its alpha stage. We have made no sales so far, and have no accurate means of estimating what our sales will look like. I could tell you that a CMS is coming within a year of the forum going gold, but it would be a meaningless statement.
There are simply too many variables. For example, if we sell hundreds of licenses every day as soon as sales begin, we will be looking to hire staff in a hurry to deal with demand, and we could see a significantly larger development team at work and a CMS being worked on very soon. On the other hand, if sales are slow we will not be in a position to expand, and if they are very slow we may not even be in a position to continue development. (I'm confident we won't be in that position though.)
I'm also reluctant to say 'of course we will produce a CMS' because as we have discussed previously, one person's idea of a CMS can differ wildly from another person's requirements. It will requireextremely careful consultation with existing customers to establish exactly what we should build before we can even say if producing such a product falls within our circle of expertise.
I'm sorry if you find this frustrating, but our determination is to produce a highly polished forum product before we start to work on anything else. That may well mean that some people will not be able to adopt XenForo right away, and that's something we have to accept. We would rather have one great product than a handful of mediocre products.
A: It's safe to say that XenForo makes use of vastly more modern and advanced programming techniques than people might expect to see in forum software, depending on where they have come from, so there will be a greater learning curve for the novice programmer. However, documentation and tutorials will help people to cut through what they don't need to know and see how easy it is to extend and modify XenForo with our APIs.
A: Originally, we did link to the absolute post URL, but in the spirit of optimising for the most common case, we changed it to use a link relative to the thread in which it resides. Why?
Firstly, in most cases, posts won't be moved.
Secondly, and more importantly, if you viewing the page threads/permalink-related-question.3417and a post contains a permalink to threads/permalink-related-question.3417/#post-51426, a search engine spidering your site will recognise that this is not a link to independent content, and will not follow that link. However, with posts/51426, the search engine can not know that, and you've wasted dozens of spider visits for every thread the search engine hits.
On balance, we felt that the second reason was far more important than the possibility of losing a post due to a merge or move.
- Status