(Originally posted here:
https://xenforo.com/community/threads/xenforo-2-0-discussion.79603/page-38#post-889527)
I'm hoping to address a few things in this post.
Why announce that you're switching to XenForo 2.0 development so early?
There was a bit of "rock and a hard place" thinking here. When developing 1.4, we had plans for 2.0 in the back of our minds and this influenced what was included in 1.4. Features that may required significant changes to add-ons or features whose data may have had to be redone for 2.0 were not ones we targeted. The menu/navigation manager is a good example of a feature that hits both those points. Conversely, this feature is also the most requested suggestion (by likes) and every time we posted a HYS, it would somehow come up in the comments. As such, we felt that it was important to let people understand our thinking and that meant explaining where we wanted to go next.
I admit it was very early to mention 2.0 and that is something we debated about. Ultimately, we thought it was better to let people know the plans than to hold off on mentioning it until sometime around now (when people may have been expecting 1.5).
When will we see 2.0 released? What's happening?
While we have some internal goals, I'm not yet happy to say any specifics. It's definitely not "close" by any stretch. Don't expect any releases or demos any time soon.
Our first and foremost goal is to reach rough feature parity with XenForo 1.4 while using the new ideas and concepts (see below). This is a very significant task; it's amazing how much functionality there is for what outwardly might appear to be a simple application. While ideas for new features and changes will influence code that's written, in most cases, our focus is on getting the old functionality working on the new base.
It sometimes feels counterintuitive to post updates when you don't feel that you have anything groundbreaking or new to say, but we will certainly do our best to keep people informed.
What are the goals of 2.0?
A major goal of 2.0 is one that is technical in nature: improve developer efficiency. While this might not be a new feature itself, it benefits all development going forward.
If you develop with XenForo 1.x for a while, you begin to see how much boiler plate and repetition there is. You begin to see that it's a pain to get access to data or even know if you have the necessary data available where you need it. And if you don't have that data, things just don't work as expected. Fixing this is a very important part of 2.0 and it involves fundamental changes to some of the lowest level code in XenForo, notably models and data writers.
Further, there are significant changes to code organization to improve code reuse (or reusability) and to help add-on developers apply additional changes to existing code more easily. There are plenty of examples of developers struggling to get new fields in existing forms to save properly due to the code organization of XenForo 1.x (specifically the controllers). This has now been re-approached to remove these problems in as many cases as possible.
Complex processes have been reorganized into distinct objects, improving readability and extendability, while also allowing the code to be used in more contexts than before.
So even though these may not be new features directly, these changes are necessary to ensure that speedy development can continue in the future and that add-on developers can make the changes they need with minimal interference from the core.
How about some more technical details?
Some assorted changes:
- While you can still write CSS directly, LESS is now the primary language for styling. If you're not familiar with LESS, it's effectively CSS that's more powerful, including things like nesting selectors, mixins, and color manipulation functions. You can read more here: http://lesscss.org/
- The template syntax has changed to some degree to provide more flexibility. This includes a more powerful function syntax, more direct math/operator access, the ability to create values with specific types (including arrays) in templates, support for macros (callable/reusable templates) with recursion, and support for calling functions on an object.
- The base unit for working with data is no longer a bare array. It is now an object that represents the specific type, giving you access to call methods on that object or access other data related to it trivially (getting the forum from a thread from a post).
- While you can still write SQL directly, most data access is done through a builder object. The builder can control what related data is fetched, what conditions are applied (including against related data) and the order of the results. This can be done in any order.
- We are not explicitly building on top of a particular framework. However, we are bringing in libraries to help with common tasks. This might be a component from Symfony and another one from Zend Framework and another from an unrelated project. It's mostly down to what we feel fits our needs.
While the XenForo 2.0 code we have developed up until this point has been compatible with PHP 5.3, we are currently strongly considering increasing the requirements to PHP 5.4. This would have a number of benefits technically (to us and add-on developers). As PHP 5.3 has been unsupported since August 2014, users should be transitioning off when possible it to ensure that they remain secure.
Regarding feature suggestions and implementing them
We do certainly read each post in the suggestions forum and bear them in mind. We will be looking at taking a more active role in the forum to give more feedback about suggestions. We do also keep suggestions in mind if they're not posted directly in the suggestion forum, but we do use likes on a suggestion as one signal of popularity.
The "lack of interest" prefix is applied programmatically when a suggestion hasn't received a reply in a year and has 3 or fewer likes in total. It is not a comment on our opinion of the feature. If a lot of the "lack of interest" suggestions are important to you, that may indicate that your requirements are fairly specific or unique.
Suggestions are also considered based on technical requirements, overhead they would require (especially when disabled or unused), the size of the potential benefit and, of course, our internal thoughts on the feature/product.
Some suggestions are just plain massive. A good example is the CMS suggestion. This isn't a feature suggestion; this is a product suggestion, a potentially very complex product suggestion. While XenForo is a framework, it is primarily based around the forum software; that is presumably why you're all here. That is likely to be our primary product for the foreseeable future. While it may be worthwhile for us to create a CMS, this would have a knock on effect on everything else we do so this (or any new product) is not something we could take on lightly. In my opinion, it's unfair to cite the lack of a CMS as a failing of a forum software package. It may be something that you need and it may be provided by others, but it's still separate from a forum and our primary product. If you need a CMS that is natively integrated with your forum, unless there's an add-on that you're comfortable with, XenForo is unlikely to fit that and I'm not in a position to say if or when it would fit that.
Regarding "buying" XenForo 2.0
As it stands, we have no plans to change the licensing scheme. If you have a license now and it still has active support/upgrades when XenForo 2.0 is released, you will be able to download it; if your license expires, you can simply purchase an extension to get access to 2.0 (and any other releases that may happen).
If you're unsure about 2.0 or our progress, you're free to hold off extending your license until you see 2.0 in person. License expiration does not affect your access to the forums.
