Random Questions Answered
- Thread starter Kier
- Start date
- Status
Q: I wonder how SEO is going to be with forum descriptions now in tooltip.
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.
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>Q: If I import from [insert forum solution name here], will my members need to reset their passwords?
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: 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.
Q: What importers will be available?
A: http://xenforo.com/community/threads/importers.221/#post-2073
A: http://xenforo.com/community/threads/importers.221/#post-2073
Q: How are variables, classes etc. named in the code?
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:
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']);Q: Why is there a confirmation dialog on 'Mark (all) forums read'?
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: 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
Q: Why is the visitor's avatar shown next to the quick reply editor?
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: 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
Q: Why isn't there a direct link to 'My Account' any more?
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: 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
Q: Why doesn't the clicking on the thread title take me to the first post in a thread?
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: 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.
Q: What is the 'Read Marking Data Lifetime ' configuration setting?
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.
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.
When your mouse hovers over a thread title in the list of threads, after a brief delay we pop open a large tooltip that displays a snippet of content from the first post in that thread. It fetches this information from the server, as requested.
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:
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.
Q: Why can't you say something more concrete about a XenForo CMS?
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: 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.
Q: How will the average programmer be able to make code changes?
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: 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.
Q: Why do post permalinks use the thread URL instead of the absolute post URL? Doesn't this mean that post permalinks won't work if i move posts or merge threads?
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.
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