XenForo 2.0 Development Updates

[XenForo]

As XenForo 1.4 nears release, the time has come to shift our primary development focus to a brand new version, which will become XenForo 2.0.

While we aren't ready to go into very much detail about version 2.0 yet, we have a framework of principles and ideas that will dictate what we want to do with this version, including a host of structural changes that will improve developer productivity and code flexibility. We have already written some of the core code in order to test the viability of some of our architectural ideas, and we are excited by the progress we've made so far.

We continue to be proud of the work we have put into XenForo 1.x since we started developing it, but as we have continued to develop the code we have learned new and better ways of doing certain things, we have had new ideas and flashes of inspiration, and now we want to put all of that knowledge into code so that we can continue to deliver a great product for many years to come.

Even a quick glance at our Suggestion Forums will show that we've had bucket loads of feedback and suggestions from customers. Sometimes, implementing these suggestions requires seriously fundamental changes to the system, with ramifications for both our own code and that of add-ons, and we don't feel that a change with such far-reaching effects is appropriate for a x.X-level release (like 1.4).

However, a major version X.x-level release such as XenForo 2.0 gives us more latitude to make significant, sweeping changes, and changes of this magnitude should be expected throughout XenForo with the new version.

What Kind of Changes?

To take a specific example, let's look at navigation. There's been a lot of feedback relating to the XenForo 1.x navigation bar, which sits just below the header, ranging from the structure of its HTML/CSS building blocks to its ability to be customized for the needs of specific sites.

A navigation and menu manager is probably one of our most requested features. It's certainly something we've wanted to implement for ages, but we have been held back by the sheer scale of the feature and how much code would be altered to accommodate it, but XenForo 2.0 is the perfect opportunity to look at features like this. If we had implemented something like this for 1.4, there would have been an extensive list of serious backwards compatibility breaks and a lot of what would be done (by add-on developers and end users) likely would have been broken by further changes when 2.0 rolls around. While backwards compatibility issues like this have happened before, we have endeavoured to keep them to a minimum in x.X-level releases.

As development moves forward, we'll have plenty more to say about what's coming.

PHP Requirements

The PHP requirements of XenForo 2.0 will definitely be increasing, primarily because we want to take advantage of technologies that newer versions of PHP now offer. The current target is a minimum of PHP 5.4.

The Small Print...

(Please note that nothing mentioned regarding a future version should be construed as a guarantee of things to come. This message is based on thoughts and information available as of today.)

A Thank You

On behalf of each of us on the XenForo team, I would also like to take this opportunity to thank everyone that has supported us through tough times and has allowed us to get to where we are today. We certainly couldn't have made it through without your support.

Here's to many more years!



This thread was split off the original thread, which remains the location for general discussion: https://xenforo.com/community/threads/xenforo-2-0-discussion.79603/

 

[Mike]

(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.

 

[Mike]

(Originally posted here: https://xenforo.com/community/threads/xenforo-2-0-discussion.79603/page-58#post-994567)

First, I just want to couch this by saying that we're not at a point where we can really give previews, sneak peeks, etc. If you haven't read my previous post discussing some of the concepts and considerations with 2.0, it's worth reading before you go any further: https://xenforo.com/community/threads/whats-next-for-xenforo.79603/page-38#post-889527 There are some specific bits that will have changed since then, but on the whole, it's still valid.

Fundamentally, XenForo 2.0 is still XenForo. We're not intending on going down a completely different path. You should expect the concepts and approaches you've learned from XenForo 1.x to still be relevant. To give a specific example, the code is fundamentally different, but the permissions concept is basically unchanged. Sure, there will be some UI changes and hopefully some other improvements, but we aren't necessarily coming in with the explicit notion of blowing things up for the sake of it. The most significant part of XenForo 2.0 development is reaching rough feature parity with 1.x. While there may be some smaller features or options that will be changed or removed, most features you use should still exist in some form.

From an end user standpoint, there will be UI changes. In some cases, it might be pretty much as is; in other cases, changes are certainly needed. I couldn't give any specific examples here yet. XenForo's UI is still based on approaches taken when we started developing it (and keep in mind the first beta was released over 5 years ago now). The way people interact with a website is vastly different today. But it's still XenForo. We'd anticipate the overall user flow to be similar to what it is now, though maybe we'll bring some other approaches in as options. Don't expect XenForo 2.0 to be a fundamentally different style of software from 1.x.

If you're questioning converting now or later, it's going to be hard for me to make a comment because most of that is down to your personal circumstances. I don't think I could tell you to convert or not convert based on 2.0; it's a project as a whole so no one would really be able to make that decision until they actually play with it (as a user and and admin). I appreciate that it isn't that helpful as we're not ready to show it off at this point, but there's always going to be a point in a project where that happens (unless there's no mention of it, but then that's just less information overall). Even once we show off some of the initial builds, there will still be an extended period of testing before we declare it stable. Essentially, it's still going to take a while for 2.0 to be ready. To be clearer, I wouldn't anticipate seeing that preview/alpha/beta/stable process until some time in 2016.

I understand it's a hard decision. I would say make decisions based on the state of things right now. No one can really guarantee whether a future release of any software is going to be great. That includes XenForo, but of course we'll do our best to make sure it is great.

 

[Mike]

While we don't have a lot of details we're ready to share today, I wanted to give a few more ideas of where we are with the development of XenForo 2.0.

At a high level, we are making good progress. A significant amount of the backend systems have been updated to the new concepts. In some cases, these systems function similarly to XenForo 1.x, but there are other cases where we have reapproached them to ensure we have more solid structure for us and the add-on ecosystem to build on. As a specific example, both prefixes and custom fields are ideas used in multiple content types and add-ons. Previously, each required effectively duplicating whole files of code with minor changes. These are now built on a generic framework that can be reused for the core functionality, while simultaneously being extendable so specific features can be added where needed.

To give an example using a new system, we're currently spending time building a generic payment framework. This is designed not only to allow different payment processors (not just PayPal) but also to be a framework to make it easy for new "purchasable" elements to be added easily (not just user upgrades). A system like this benefits the core system, but also enables new add-ons to be developed more easily. Without this, developers may discount an idea that requires payment processing because of the extra legwork required.

In terms of the interface, we have a lot of the core building blocks in place, but there is still a lot of adjustment happening. Because there's still so much changing here, we're not ready to show off screenshots yet. From a code (HTML/CSS) standpoint, we're trying to make the structure more straightforward and consistent with a focus on modularity and clearer CSS application. Many style authors will appreciate that I'm sure!

While XenForo 1.5 is responsive, we are very aware that there are still challenges using it on touch devices. In many cases, this comes from a UI that wasn't designed with touch in mind. This is simply not an option today and we are doing our best to keep phones and touch in mind.

Overall, to reiterate something I said in a previous post, XenForo 2.0 is still XenForo. We aren't trying to change fundamental concepts of XenForo unless we have specific reasons to. There are reasons to change some things and we're taking this opportunity to do so.

All that being said, let's give a sneak peak of some bits of code to give an idea of some of the changes we're making...

First, we have a general service concept. Services vary significantly between them, but they represent a good example of improved flexibility. This specific example uses the thread mover service within the inline moderation system:

/** @var \XF\Service\Thread\Mover $mover */
$mover = $this->app()->service('XF:Thread\Mover', $thread);

if ($options['alert'])
{
    $mover->setSendAlert(true, $options['alert_reason']);
}

if ($options['notify_watchers'])
{
    $mover->setNotifyWatchers();
}

if ($options['redirect'])
{
    $mover->setRedirect(true, $options['redirect_length']);
}

if ($options['prefix_id'] !== null)
{
    $mover->setPrefix($options['prefix_id']);
}

$mover->move($targetForum);

XenForo 1.5's inline moderation thread moving has significant amounts of duplicated code from elsewhere. By organizing code into services with minimal external dependencies you get significant reduction in duplication and improvements in flexibility. There are a wide range of services, from creating attachments to merging users. These have various points where add-ons can hook in and extend functionality, much more easily than was possible in XenForo 1.

Data access is much easier and more flexible:

$finder = $this->em()->finder('XF:Post')
    ->where('thread_id', 123)
    ->with('Thread')
    ->onPage(2)
    ->orderByDate();
$post = $finder->fetchOne();
$thread = $post->Thread; // this was fetched with the query
$forum = $thread->Forum; // this is silently fetched as needed
if ($forum->canView()) { /* ... */ }
if ($forum->isUnread()) { /* ... */ }

This makes it much easier to access the data you need and much less time worrying about writing SQL manually.

Finally, here's some example template HTML/syntax:

<xf:textboxrow label="{{ phrase('title') }}" name="title" value="{{ $trophy.trophy_id ? $trophy.MasterTitle.phrase_text : '' }}" />

<xf:textboxrow label="{{ phrase('trophy_points') }}" name="trophy_points" value="{$trophy.trophy_points}" type="number" min="0" size="8">
    <xf:explain>{{ phrase('points_can_be_used_track_progression_and_change_title') }}</xf:explain>
</xf:textboxrow>

<xf:textarearow label="{{ phrase('description') }}" name="description" value="{{ $trophy.trophy_id ? $trophy.MasterDescription.phrase_text : '' }}">
    <xf:hint>{{ phrase('you_may_use_html') }}</xf:hint>
    <xf:explain>{{ phrase('optionally_describe_trophy_and_criteria_user_needs_to_award') }}</xf:explain>
</xf:textarearow>

<xf:macro template="helper_criteria" name="user_panes"
    arg-criteria="{{ $userCriteria.getCriteriaForTemplate() }}"
    arg-data="{{ $userCriteria.getExtraTemplateData() }}"
/>

The syntax should look fairly similar, but you'll notice some differences. More significantly, there's a lot more power available in templates including method calls (which can load data) and macros which allow you to create reusable blocks that can function independently from the current template's state. We have created a tool that can help convert the old template syntax to the new one, though further changes are still likely to be needed.

We still have a lot to get on with and we'll keep plugging away until we get there. We are absolutely not resting on our laurels. We are pushing hard to make sure that XenForo 2.0 is better than 1.5. When we're ready to show more, we hope you'll agree.

 

[Mike]

It's been a while since our last formal XenForo 2.0 development update, but we're excited to show you the progress we've made recently.

To start, let's look at some of the first XenForo 2.0 screenshots. Our aim with the design has been to be familiar but updated. We've previously said that XenForo 2.0 is still XenForo and this applies in the design. That said, these screenshots represent a work in progress and changes are still being made many times a day; there may be elements in these screenshots that change over time.

First up, we have the forum list page:



Here's what a simple thread looks like:



Finally, let's focus on one of the many forms in the control panel. Let's see navigation entry editing:



Aside from the updated look and feel, there are a few other new features shown here:

• The navigation manager which allows you to control the individual parts of the header navigation area. You might have noticed that navigation entries can come from the node tree and be their own tab.
• Widgets powering the sidebar of the forum list. We've mimicked XenForo 1 here, but they are powered by a new widget system which lets you control what is displayed in various locations. And if you want to insert a widget in a custom location, you can do this with a special template tag.
• Dynamic letter-based avatars for users without a custom avatar. These users will now receive an avatar based off the first letter of their username, with a background color generated from their name.

We'll go into these in more detail in the future.

Since we're showing screenshots, let's talk a little more about the HTML/CSS structure XenForo 2.0 uses. On the whole, the HTML and CSS is organized around the Block-Element-Modifier (BEM) approach. Let's start with a specific example:

<div class="block">
    <div class="block-container">
        <xf:if is="$trophies is not empty">
            <ol class="block-body">
                <xf:foreach loop="$trophies" value="$trophy">
                    <li class="block-row block-row--separated">
                        <div class="figureRow">
                            <span class="figureRow-figure figureRow-figure--text figureRow-figure--fixedSmall">{$trophy.Trophy.trophy_points}</span>
                            <div class="figureRow-main">
                                <span class="figureRow-extra"><xf:date time="{$trophy.award_date}" /></span>
                                <h2 class="figureRow-header">{$trophy.Trophy.title}</h2>
                                <div class="figureRow-minor">{$trophy.Trophy.description|raw}</div>
                            </div>
                        </div>
                    </li>
                </xf:foreach>
            </ol>
        <xf:else />
            <div class="block-body block-row">{{ phrase('x_has_not_been_awarded_any_trophies_yet', {'name': $user.username}) }}</div>
        </xf:if>
        <div class="block-footer">
            <span class="u-pullLeft">{{ phrase('total_points') }}: {{ number($user.trophy_points) }}</span>
            <span class="u-pullRight"><a href="{{ link('help', {'page_name': 'trophies'}) }}" class="button">{{ phrase('view_all_available_trophies') }}</a></span>
        </div>
    </div>
</div>

Starting from the outside, you'll see our block system. With BEM, "block" is the, well, Block; "block-container", "block-row" and so on are Elements; and "block-row--separated" is the "separated" Modifier of the block row. This approach makes organization much easier and makes the styling process much clearer. Our convention is a single "-" for Elements and a double "--" for Modifiers and then using camel case within.

Within the block, you'll see "figureRow", which is our generic system for laying out an icon or figure to the left of the corresponding content. This is unrelated to blocks and can function entirely independently if you wish. Under BEM, "figureRow" is it's own Block, "figureRow-figure" an Element and "figureRow-figure--text" a Modifier.

If you look within the block-footer element, you'll also see "u-pullLeft" and "u-pullRight" elements. Strictly speaking, these probably shouldn't be used here if possible, but they serve as a good example of utility classes. These get prefixed with "u-" to indicate that they don't necessarily follow the general BEM pattern but provide useful tools to use in a pinch. A few other examples include "u-muted" for less emphasized text and "u-srOnly" to visually hide something (but keep it for screen readers).

It's worth mentioning that while the default style has clearly emphasized "boxes", you can downplay this easily by simply removing the background color and adjusting the borders to suit your needs. By building off this system, it makes our layout much more consistent and thus easier to customized consistently.

What's next?

At this point, the absolute vast majority of the functionality has been added. There are still some smaller pages and functions here or there that we need to support, but the core functionality is basically all there. That said, our todo list is far from empty. As any developer will tell you, you check off one thing and add two more. We're still working hard, but we're making very good progress.

When we feel it has reached that point, the first step will be to create a separate demo installation so that everyone can start playing with XenForo 2.0 as an end user. We'll be gathering feedback, making changes, fixing bugs, and working on things in the background that you won't see.

The next step would be what could be considered an alpha or a developer preview. This will be the first time that customers will be able to try out XenForo 2.0 on their own server and work with the code/templates. We do not intend on limiting this to selected developers. However, you will not be able to upgrade into this version and you are unlikely to be able to upgrade out of it. You will likely also have to do installation using the command line and taking some manual steps. This preview is specifically designed to start getting initial feedback from developers (and stylers) and keen enthusiasts.

Following that, XenForo 2.0 will go through the usual beta process, like any other 1.x release. However, this process may be longer due to the scope of the changes made and to allow us further time complete additional tasks, such as updates to our official add-ons.

When's this going to happen?

Each step of the process is dependent on how the previous one goes. Therefore, it would be very hard for us to suggest when a stable version--or even the beta--version will be released. However, our goal is to begin gathering feedback via the demo installation in autumn 2016.

We're excited about what's to come!

 

[Mike]

We previously posted an official announcement about the XenForo 2.0 demo site. Since the demo has gone live, we've made a lot of changes. Many of these have been detailed in a new development update thread on the demo site.

If you haven't seen it, we've also covered a high-level list of what's new in XenForo 2.0.

Keep an eye on the demo site for the latest changes we're making.