XenForo 2.0 Discussion

[euantor]

There are lots of discussions/debate about which CSS pre-processor to use and for good reasons my personal favorite is SASS. One big concern I have seen in this regard that people are afraid of the Ruby dependency of the SASS. On the other hand LESS also requires external dependency of NodeJS, unless one is willing to use client side less.js library (which is only recommended in development mode). Another argument is about the syntax, LESS gives a syntax which is very close to the existing CSS, on the other hand SASS supports two syntaxes, SASS and SCSS where first one is full-featured preferred syntax and the later is the fallback which is very compatible with the existing CSS syntax and a good way to refactor the existing CSS code incrementally.

+1 for SASS+Compass please!

It's worth noting that LESS used to (not sure if it still does, haven't investigated in a while) have a PHP based parser that converts LESS, while SASS does not. That's probably the reason LESS is being used.

 

[ibnesayeed]

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

Awesome! Let me smell the soothing fragrance of Object Relational Mapping that abstracts the complications of SQL and complex JOIN queries away and lets the developer live in the friendly Object world.

 

[ibnesayeed]

It's worth noting that LESS used to (not sure if it still does, haven't investigated in a while) have a PHP based parser that converts LESS, while SASS does not. That's probably the reason LESS is being used.

Oh! If that's the case then LESS is certainly the winner here in terms of not having one more dependency in the development stack. When I Googled it, I found that there are third-party efforts for writing compilers of both in PHP though.

 

[sbj]

Addons don't seem like they're going to require a complete rewrite due to the fact XenForo isn't switching frameworks or anything.

But this was what I was afraid of. The only thing I heard from here was "2.0 will be a complete rewrite". So that meant to me that we have to start from ground zero again. But now the last response took my concern away.
Yeah, but you developers will need to match the new style standards. This is what you can't prevent I think.

 

[Mike]

Of course this won't mean that all add-ons will be compatible or won't need any code changes, but it seems that most of the add-ons won't need complete rewrites. Just basic adjusting.

I would definitely not say "basic adjusting", at least not if they want to do things "the new way". There are some tools to help legacy conversions, but if you're trying to actually use the new approaches, you may not want to use them (just use the old code as a guide but move things around). I certainly wouldn't expect a drop in replacement for the PHP code and certainly not for the HTML/CSS.

It's worth noting that LESS used to (not sure if it still does, haven't investigated in a while) have a PHP based parser that converts LESS, while SASS does not. That's probably the reason LESS is being used.

Yes, there is a less.php project which is basically less.js in PHP which means it is easier (for the developers of the project) to maintain parity.

But this was what I was afraid of. The only thing I heard from here was "2.0 will be a complete rewrite". So that meant to me that we have to start from ground zeri again. But now the last response took my concern away.
Yeah, but you developers will need to match the new style standards. This is what you can't prevent I think.

There are concepts that are maintained, but I would expect everything to have to be redone. 2.0 is effectively a rewrite; changing how the entire application interacts with data will change a lot of code.

 

[sbj]

I would definitely not say "basic adjusting", at least not if they want to do things "the new way". There are some tools to help legacy conversions, but if you're trying to actually use the new approaches, you may not want to use them (just use the old code as a guide but move things around). I certainly wouldn't expect a drop in replacement for the PHP code and certainly not for the HTML/CSS.

There are concepts that are maintained, but I would expect everything to have to be redone. 2.0 is effectively a rewrite; changing how the entire application interacts with data will change a lot of code.

Ok, now I'm concerned. 4 years of add-on works will be wiped away? You expect everything to have to be redone?
In other words, can you explain me how this is going to be an improvement/progress for me as an admin? For all simple admins out there?

Besides that, do you have a plan of extending the core functions massively? So maybe many add-ons won't need to be redone because they will already be implemented? How many appox.? 0-10? 10-30? 30++ new functions?

 

[Paul B]

You can continue to use XF1 if you prefer, it's not compulsory to upgrade.

 

[Jeremy]

At some point, starting fresh is the only way to go forward. It isn't always feasible to refactor or add to accomplish newer designs without destroying some work. This is standard in software development in fairly everything I've ever dealt with.

My first professional job spent 3 years developing a framework for use in their sites. It wasn't super efficient, worked, but was limited. They tossed out that work and rebuilt from the ground up and could rapidly deploy new sites because the structure was new and increased efficiency. Its a cycle of improvement, and change for change is useless. What Mike has explained isn't change for the fact they want change. The changes allow necessary movement forward.

 

[Slavik]

Ok, now I'm concerned. 4 years of add-on works will be wiped away? You expect everything to have to be redone?
In other words, can you explain me how this is going to be an improvement/progress for me as an admin? For all simple admins out there?

Besides that, do you have a plan of extending the core functions massively? So maybe many add-ons won't need to be redone because they will already be implemented? How many appox.? 0-10? 10-30? 30++ new functions?

As per any software, a first point upgrade is usually sweeping changes from the most basic level upwards.

Simply wait until addon authors have released the XF 2.0 addons.

 

[sbj]

You can continue to use XF1 if you prefer, it's not compulsory to upgrade.

In all respects, no offence, but isn't this the most cheap way of avoiding customers concerns?
You say basically to my face that you don't care, I don't need to upgrade.
Yeah sure, I don't. While everyone around will offer add-ons/styles/adjustments/support compatible for the newest version, I will be the misfit who "didn't have to upgrade". That is really good news for me. Yay. 2.0 is coming... or not... Thanks.

 

[Mike]

(I've been beaten here, but I'll continue anyway.)

The change of the first number is designed to note potential for significant compatibility breaks. At some point, big breaks are needed to ensure that the product can still move forward. We are incorporating things we have learned developing XenForo over the years to do that. The goal is to allow further improvements to come.

We will be adding features over time. Will 2.0 add a whole bunch? I couldn't tell you right now; it will certainly add some. Once 2.0 is out though, 2.1, 2.2, 2.3, etc would be dedicated to new features like 1.1 through 1.4 have been.

Inevitably, there will be add-ons that don't update to support 2.0. If they are fundamental to your site, then they will tie you to 1.x unless you find an alternative. That can even happen within the 1.x series as there are sometimes compatibility breaks within it.

1.x won't stop working with the release of 2.0 and we would maintain it for bug fixes for a period of time after 2.0 is released.

 

[sbj]

Simply wait until addon authors have released the XF 2.0 addons.

That was my strategy obviously. But I expect some kind of way that you guys of Xenforo also look out for us poor souls here, who can't code or do simple adjustment stuff and rely on add-ons. Do I ask for too much?

 

[Deebs]

In all respects, no offence, but isn't this the most cheap way of avoiding customers concerns?
You say basically to my face that you don't care, I don't need to upgrade.
Yeah sure, I don't. While everyone around will offer add-ons/styles/adjustments/support compatible for the newest version, I will be the misfit who "didn't have to upgrade". That is really good news for me. Yay. 2.0 is coming... or not... Thanks.

How is what is happening with XenForo 2.x any different from server/desktop/mobile operating systems enforcing developers to update their applications to be compatible. It happens all the time in the software industry, XenForo is being no different.

 

[Amaury]

I'm just curious here: Whenever XenForo 2.0 is released, will there be new bug and suggestion forums (as well as other similar forums) created to keep the XenForo 1.x bugs and suggestions separate from the XenForo 2.0 bugs and suggestions or will the same forums be used?

 

[Chris D]

That hasn't really been decided, yet. There will need to be some separation. That could mean separate forums or at least separate prefixes.

 

[Mike]

Do I ask for too much?

To be honest, yes, unless we stayed on 1.x forever, though I imagine many add-ons written for 1.0 won't work with 1.4 anyway. The transition is the same that happens with the changes within the 1.x branch, but much larger. Eventually there need to be significant changes that break compatibility; when that happens, the first number gets changed.

Because of the amount of customizability that XF offers, add-ons can hook in anywhere and do a lot of custom or unexpected things. As such, it's simply not possible to maintain the level of backwards compatibility to allow old code to work, particularly if it integrates into core code.

 

[Allan]

I didn't understand, will it be possible to create styles with CSS or will he use less?

 

[Naz]

I didn't understand, will it be possible to create styles with CSS or will he use less?

As stated, CSS can be used. LESS will just be the primary language for styling in XF2.

 

[SneakyDave]

I realize this should go to the suggestions forum, but please update the transmogrifier. Mine's been broken for a number of versions.

 

[Allan]

As stated, CSS can be used. LESS will just be the primary language for styling in XF2.

Ok, concretely, for the creators of style, thus it will change nothing?