XenForo 2.0 Discussion
- Thread starter XenForo
- Start date
- Status
This is not how software works.
XF 2 may have deep architectural changes, and significant parts modified. But one thing I can state with confidence is; It will not be a complete rewrite.
Otherwise, XF 2 isn't going to be released for years and years. I would be surprised if a usable product came out inside 2-3 years if XF was being fully rewritten.
Writing a new product unencumbered by existing code is a very different game to changing an existing product. Plus, it took quite some time for XF to get a number of 'must have' features which where blockers for a number of forums to convert.
Time to get a 1.0 release out the door isn't what I'm comparing to. It is the time to reach feature parity and polish.
Lone Wolf
Well-known member
I think you'll be surprised how fast XF 2.0 comes out
I'm guessing at between May and August of this year.
Yoskaldyr
Well-known member
@Mike, May be backbone or stapes.js only for data model events will be used?
And one or two way data-view bindings will be applied manually by XenForo javascript code?
Data model events works ideally for widgets, ajax changed data or any notification data (like ajaxData._visitor_alertsUnread and ajaxData._visitor_conversationsUnread).
And this data can be received not only by ajax requests, but by localStorage/postMessage (cross-tab communication), longpoll/websockets (permanent connection with server for pub/sub).
No matter how this data has been received, but data events will fire updates of the view.
And one or two way data-view bindings will be applied manually by XenForo javascript code?
Data model events works ideally for widgets, ajax changed data or any notification data (like ajaxData._visitor_alertsUnread and ajaxData._visitor_conversationsUnread).
And this data can be received not only by ajax requests, but by localStorage/postMessage (cross-tab communication), longpoll/websockets (permanent connection with server for pub/sub).
No matter how this data has been received, but data events will fire updates of the view.
Last edited:
guiltar
Well-known member
Agree with @Yoskaldyr, extending current JS is very difficult, not even close to extending PHP.
s.molinari
Well-known member
Thanks for that answer Mike. Some more curiosity, but what parts of Symfony do you plan to use?
Scott
Moshe1010
Well-known member
How would XF 2.0 prevent you from using your current board or make your forum to loss functionality? If you're happy with your current configuration/functionality/features of the forum that you've built throughout the years, then I don't understand how XF 2.0 would change this situation for you. Yes, you will not get add-on upgrades, but you said you have many custom ones anyway, so extend those if you wish. Most developers of their current add-ons would update their add-ons to XF 2.0, so I can't really see the logic in your argument. It's not like XF 2.0 disables/affects negatively on your current add-ons, including their features. If you don't want to move forward, nobody is pushing you to do so.
I'll give an example: Many users are still using Internet Explorer version 8.0, which is dead long time ago. Does it prevent these people from surfing the web? Nope. Would they get a benefit from upgrading to a newer version? for the sake of the argument (Because IE by itself is crap), they will since IE 11.0 would be faster and support more elements on a single website, but they would still be able to surf the web as anybody else.
You gave some examples like Vista to Windows 7, but you forgot to give the example of Windows 98/2000 to windows Vista (Windows Me is not really Microsoft's product, it was a huge mistake sponsored by Microsoft) - it was a complete rewrite by Microsoft, and most stuff from Windows 98/2000 wouldn't work on Vista and beyond.
This is a small change from what we were originally aiming for, but ultimately it's the right decision.
I'm aware some people would prefer us to bump this up to PHP 5.6. Though, realistically, doing that as an arbitrary requirement really isn't going to benefit the code all that much. However, PHP 5.3 and PHP 5.4 both add features which we can benefit from. It is, however, worth noting that from a performance and security perspective, you are likely to be better off running PHP 5.5 or PHP 5.6.
Teapot
Well-known member
Personally, I think this is a good call. 5.3 is EOL and, truthfully, I think clinging to old technologies to try and appease as many people as possible has made a lot of trouble for a lot of projects, including (and especially) major commercial ones. It's not worth bloating the codebase and being prohibited from using the (very useful) new features in 5.4.
Kuma
Active member
Raising requirements to php 5.6 is not likely to go well. The glacial rate at which webhosts adopt newer versions of php is very scary. There are still webhosts who offer php 4 support, and some that only support php 5.2. It took GoDaddy until mid-last year to stop offering php 5.2 by default. Even a minimum of 5.3 or 5.4 will still cause some headaches, but not like 5.6 would.
- Status
Similar threads
- Suggestion
