XenForo 2.0 Discussion

[Dakota Storm]

Nothing is more important than good mobile access. Mobile skins are too clumsy and slow still.

There is never going to be a magical app that does everything, is compatible with existing addons and potential future addons, it's just not feasible.
That and it really isn't the devs place to provide one, you are of course welcome to provide the thousands of of dollars it will cost to have something half way decent, built.

 

[TheBigK]

The thing about mobile apps is that people really want them. They may just download apps but not use them EVER; but they keep asking for it. The only thing that's missing from the responsive design is that it doesn't push notifications - which our members want! If there's an alert - people want the notification on their mobile. I just hope Chrome and Firefox bring push notifications to mainstream.

I do not have the patience to go through the entire thread; but have I missed any information that's official?

 

[Dakota Storm]

The thing about mobile apps is that people really want them. They may just download apps but not use them EVER; but they keep asking for it. The only thing that's missing from the responsive design is that it doesn't push notifications - which our members want! If there's an alert - people want the notification on their mobile. I just hope Chrome and Firefox bring push notifications to mainstream.

I do not have the patience to go through the entire thread; but have I missed any information that's official?

Well, Google have opened up mobile push to specific websites like Facebook etc, so there is some hope for the future.

 

[n00bsaibot]

There is never going to be a magical app that does everything, is compatible with existing addons and potential future addons, it's just not feasible.

I get that. If certain features were feasible TT would've already implemented it. But there is still demand for a mobile app a forum owner can control.

That and it really isn't the devs place to provide one

The customer demand is there and it is their place to capitalize on it. They don't have to include it in the base but I think an official mobile app would outsell XFMG and XFRM.

 

[TPerry]

Oh, I wouldn't mind seeing them do one that supports all the OFFICIAL add-ons... but then you'd have this one and that one whining that they want it to support this special add-on or that special add on since it's "vital to their community", and then you want those that want it branded specifically to THEIR community and not be able to use on any other XenForo community.

 

[DroidOne]

Oh, I wouldn't mind seeing them do one that supports all the OFFICIAL add-ons... but then you'd have this one and that one whining that they want it to support this special add-on or that special add on since it's "vital to their community", and then you want those that want it branded specifically to THEIR community and not be able to use on any other XenForo community.

Vocal minority? A majority will be happy as long as users easily can:
A: Create threads
B: View and respond to threads

Tapatalk became popular for a reason and it's not because of their support for a broad array of features for each platform that's supported. It's a very basic, simple, fast and easy to use app with push support. Enough to generate between 5-10 million installs via Google Play alone.

Forum owners who want to support X and Y add-on or whatever will have to compromise or create their own application.

 

[TPerry]

Vocal minority? A majority will be happy as long as users easily can:
A: Create threads
B: View and respond to threads

Actually, if they are going to write one, it needs direct integration with the gallery also. Kind of stoopid to code one - and not have the gallery able to be used, especially now that you can upload your images in the gallery and re-use them as many times as you like in different posts without having to upload them again.
And you underestimate the vocal minority - they are firm believers in the squeaky wheel philosophy.

 

[click here]

Yes. I think almost everything will make it over from XF1 unscathed.

Okay cool, one more question... Currently I'm on XF1.5.2 and have paid upgrades via recurring subscriptions, will the recurring subscriptions be unaffected after upgrading to 2.0?

 

[Daniel Hood]

Okay cool, one more question... Currently I'm on XF1.5.2 and have paid upgrades via recurring subscriptions, will the recurring subscriptions be unaffected after upgrading to 2.0?

That seems like a safe assumption.

 

[Chris D]

It's actually hard to say as we've not implemented that system, yet, but generally speaking, yes, that would be the aim for everything.

 

[Gadget Maniac]

Hi Chris

Will 2.0 be more "accessible" to code for?

My Dev is a whizz at vBulletin but found Xenforo too "uphill going" (that's one of the reasons we haven't moved over yet. I am a customisation freak so I have a bazillion custom tweaks to replicate when I make the move.)

I get the feeling there is a small 'insider gang' that know how to code well for XF and they are all booked up / too busy / so in demand that they can jack their prices sky high.

Will be made easier for a wider group of people to work with?

I hope so.

Thanks

 

[Jake B.]

Hi Chris

Will 2.0 be more "accessible" to code for?

My Dev is a whizz at vBulletin but found Xenforo too "uphill going" (that's one of the reasons we haven't moved over yet. I am a customisation freak so I have a bazillion custom tweaks to replicate when I make the move.)

I get the feeling there is a small 'insider gang' that know how to code well for XF and they are all booked up / too busy / so in demand that they can jack their prices sky high.

Will be made easier for a wider group of people to work with?

I hope so.

Thanks

There's nothing hard about it now as long as you understand mvc. Any developer that doesn't understand mvc I'd going to have issues with any modern software

 

[HWS]

Will 2.0 be more "accessible" to code for?

XF 1 is much more "accessible" compared to vB. So this may not be the correct adjective

vB has a very direct, old style coding style. XF 1 uses MVC (Model - View - Controller) coding style which is much more efficient to code.

I think XF 2 will even be more modern in terms of coding standards, so even people familiar with XF 1 may have to learn for it. We already heard it will use less instead of css, so this alone will leave some people with only basic coding skills behind.

 

[Chris D]

Hi Chris

Will 2.0 be more "accessible" to code for?

My Dev is a whizz at vBulletin but found Xenforo too "uphill going" (that's one of the reasons we haven't moved over yet. I am a customisation freak so I have a bazillion custom tweaks to replicate when I make the move.)

I get the feeling there is a small 'insider gang' that know how to code well for XF and they are all booked up / too busy / so in demand that they can jack their prices sky high.

Will be made easier for a wider group of people to work with?

I hope so.

Thanks

There is a learning curve for XenForo development because it employs a MVC pattern and object oriented programming concepts. XenForo 2.0 is actually more object oriented than ever.

Some people find this development style and its concepts more complicated to get to grips with but ultimately, that is the nature of modern software and it is essential to build quality and flexible software.

There are some new concepts in XF 2.0 but I would say that if you start off being familiar with XF 1.0 then that will help to transfer those skills over to XF 2.0 when the time comes. But at the same time, I would say that a good developer should be able to pick up XF 2.0 from scratch, if they are familiar with modern programming principles.

There's no insider gang, just a reluctance from some to upgrade their skills from a more procedural approach to the more modern object oriented approach which most applications are built with today.

I think XF 2 will even be more modern in terms of coding standards, so even people familiar with XF 1 may have to learn for it. We already heard it will use less instead of css, so this alone will leave some people with only basic coding skills behind.

I disagree with this assertion. LESS is compiled into CSS and entirely optional. LESS will make your life easier, but you can still use CSS on its own if you prefer.

 

[Robust]

Thing is, your PHP requirements right now are PHP 5.3 minimally. PHP 5.4 introduces traits which could be very useful for XF, removing reused code and boilerplate. There's also short array syntax, making code look neater and more modern. Wouldn't PHP 5.4 be a better minimal PHP target? Especially since any host using PHP 5.3 is one to run away from, even hostgator has upgraded. Traits would be useful enough to make the increase worth it.

 

[Jake B.]

Thing is, your PHP requirements right now are PHP 5.3 minimally.

It's actually 5.2.7 I believe. Also I think I saw @Chris D mention that 5.4 was required for xf2. Though I may be wrong. What I really hope for is supporting autoloader composer packages without having to drag them into library and futs with them to get them to work

 

[Paul B]

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.

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.

 

[Gladius]

The only sensible thing to do, really.

 

[Chris D]

Really the move to 5.4 was a no brainer.

Although small, using the shorter array syntax is cool:

$viewParams = [
    'forum' => $forum
];

vs.

$viewParams = array(
    'forum' => $forum
);

Function array dereferencing has been useful:

if ($this->getSomething()['thing'])
{
    // do stuff
}

vs.

$something = $this->getSomething();
if ($something['thing'])
{
    // do stuff
}

But I think the main thing for us was being able to use '$this' inside closures:

$f = function() use($key)
{
    $value = $this->get($key);
}

vs.

$t = $this;
$f = function() use ($t, $key)
{
    $value = $t->get($key);
}

There's some nice stuff in 5.5, 5.6 and 7 but the above stuff was compelling enough itself to make the jump to 5.4.

Side note, my favourite thing about PHP 7 so far is the null coalesce operator:

$value = $foo['bar']  ?? 'no value';

vs.

$value = isset($foo['bar']) ? $foo['bar'] : 'no_value';

 

[TickTackk]

@Chris D Would the annoying 25 character limit be removed in 2.0 for places like content type names and permission ids? And if not, why is it 25 character limit to begin with?