XenForo 2.0 Discussion

[Allan]

The current language file (French, German etc ..) will be completely redone or do you think about the possibility of a simplified update existing translation?

Because starting from scratch will represent months of work!

 

[Chris D]

Currently the language/phrase system should be compatible but we wouldn't necessarily let compatibility hold us back if it meant being able to make changes we needed. If we're going to break stuff like that it pretty much has to be done in a major first point release (you'd thank us even less if it was done in a second point release!)

 

[Alpha1]

I hope the language system in XF2.0 will be much more comprehensive, open, dynamic, less static and friendly to multilingual communities. Rather a localizations system than a phrases system. I think that XF can gain a lot in this aspect.

 

[CyberAP]

I like it how they've done localization in wordpress: https://codex.wordpress.org/I18n_for_WordPress_Developers

 

[erich37]

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)

- could you please give examples as to which "Payment Processors" will be implemented ?
- is there a chance you are going to implement Alipay ?

Many thanks!

 

[Chris D]

We actually have quite a list which we're considering, but I suspect we won't necessarily implement them all.

Even if we don't implement your favourite provider, we've put a lot of thought into designing a framework that will make it easier than ever for developers to implement new providers.

If you have specific suggestions, ensure they are posted and supported in the Suggestions forum.

 

[Xon]

Pretty much all my add-ons will require a rewrite, as most of them are designed to extend or change fundamental workflow bits.

We have split off the main "official" updates into a separate thread. This thread should still be used for discussion.

I have just posted a separate update with some code examples if you're interested: https://xenforo.com/community/threads/xenforo-2-0-development-updates.113262/#post-1044323

I for one much appreciate this sort of system. How add-ons are required to expend SQL queries with joins is fragile, and very easy to get wrong.

 

[ManagerJosh]

I have been monitoring this thread for the better part of since its inception and I would like to go on the record with this statement:

I completely trust @Kier, @Mike, @Chris D, and @Ashley to make decisions that are in our best interest. If you need any proof, look at XenForo 1.0. We are here because Kier, Mike, Ashley set off to build something fresh, and clean. They have never given any reason for us to doubt them. They have never given any reason for us to second guess their decision making.

I for one have complete confidence that when XenForo 2.0 rolls out, XenForo will continue to be the gold standard in this industry.

 

[Alpha1]

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.

Could you explain this some more? Its clear that a generic framework will make it easier to reuse existing custom fields functions. But many addon developers need more than the custom fields currently available in XF1.
How does this affect addon developers that need advanced custom fields? As it is he intention of XF2 to make development easier and more flexible, could you please explain:
Will it be easier for developers to create advanced custom fields in XF2, than it is in XF1?

 

[Chris D]

Can you give an example of what you would define as an "advanced custom field"?

 

[Alpha1]

Can you give an example of what you would define as an "advanced custom field"?

Some advanced fields from popular addons:

• Star Rating selection
• Date Picker selection
• Upload file
  
• Address autocomplete with Google MAPS
  
• Pros & cons

Often its possible to select the primary and secondary display location. (under/below content, sidebar, item listing, etc)
With some addons its possible to group fields so that its easy to attribute large numbers of fields to nodes.

 

[Chris D]

Some advanced fields from popular addons:

• Star Rating selection
• Date Picker selection
• Upload file
  
• Address autocomplete with Google MAPS
  
• Pros & cons

I wouldn't necessarily say these are difficult to implement now. Certainly it should be possible to add similar stuff in XF2.

Often its possible to select the primary and secondary display location. (under/below content, sidebar, item listing, etc)
With some addons its possible to group fields so that its easy to attribute large numbers of fields to nodes.

Display locations for user fields are still currently only a single selection. Grouping fields to be used in different nodes sounds to me like something that would be type dependent. As does multiple display locations, actually. I would say that it would be fairly simple to add these things for different custom field types.

For the most part, a lot of the things you've mentioned here are not difficult to do in XF1. They should be equally simple to do in XF2, if not easier.

However, the biggest benefit is going to remain that to implement new custom field systems, it is no longer the case that you need to effectively copy hundreds or thousands of lines of code to replicate the basic user field system; instead it is done by extending and re-using the "base" templates, controlllers and entities, etc.

As a rather vague example, most admin controllers in XF1 and XF2 will have Index, Add/Edit, Save and Delete actions at a minimum. The admin controller for user fields in XF2 technically has none of these because the code for listing fields, adding/editing, saving and deleting is all shared via the abstract version of the field controller. All that's in this controller is a few methods that define some very small type specific things. The pattern is similar across the rest of the custom field code (and prefixes too).

So even if it is the same amount of work to implement these advanced fields in XF2, by the time you get to adding them you've already saved yourself potentially hours of duplicating existing code.

 

[Alpha1]

Grouping fields to be used in different nodes sounds to me like something that would be type dependent. As does multiple display locations, actually. I would say that it would be fairly simple to add these things for different custom field types.

The common use case is that admins create the fields that they need, which are mostly different field types and re-use this group to apply it to different nodes.

 

[Alpha1]

I wouldn't necessarily say these are difficult to implement now. Certainly it should be possible to add similar stuff in XF2.

A few more examples:

• Relational fields
• Calculated fields
• Conditional Fields
• Yes/No Radio buttons
• Rating scales / likert

 

[wedgar]

Such a poor understanding.. no, the customer is NOT king. And no.. the customer isn't always right. In fact, in some cases it's cheaper to tell a customer to "hit the door" than keep putting up with their unrealistic demands/expectations (from a business aspect) as they cost WAY more than what they bring in.

Yep, there are times it is necessary to fire the customer.

 

[AndrewSimm]

Yep, there are times it is necessary to fire the customer.

The satisfaction rate of your product to the industry it resides is the best method to understand what direction a business is going. Sure you can't make them all happy but you can sure the hell try and that is what any good business would do. In a previous life I worked for a company that had a lot of large contracts with fortune 500 companies. I heard the phrase fire the customer on more than a few occasion. Since leaving that company and joining a company that has some dealing with that company I realized while my previous company may have had good reasons to fire companies the ultimate issue was they couldn't adapt their business model to make it work for both. The term "fire the customer" is bad because it implies you made the right decision for your business but in fact in most cases a solution could have been where the customer would still be a customer. Customers can be difficult but the pay you to find solutions and while you may never satisfy all their needs you may satisfy enough to keep them as your customer.

 

[TPerry]

Customers can be difficult but the pay you to find solutions and while you may never satisfy all their needs you may satisfy enough to keep them as your customer.

And then you have those customers that are very rarely satisfied - as they want it exactly the way THEY want it to work and believe that the world should bend to their needs. Those are the type of customers that are not "cost efficient" and are the ones that need to be shown the door. It's not an inability to "adapt to their business model" but the inability of the user to realize that , as Spock said, "The needs of the many outweigh the needs of the few ...... or the one".

I've got another script I use (just for a while, I'm going to be converting that script soon) - now, if you want to talk arrogant developers.

 

[AndrewSimm]

And then you have those customers that are very rarely satisfied - as they want it exactly the way THEY want it to work and believe that the world should bend to their needs. Those are the type of customers that are not "cost efficient" and are the ones that need to be shown the door. It's not an inability to "adapt to their business model" but the inability of the user to realize that , as Spock said, "The needs of the many outweigh the needs of the few ...... or the one".

You provide the customer the best solution you can to address their need and if that solution is better than the competition then you keep the customer, they came to you because they thought you can provide the solution they were wanting. It isn't the customers job to design your business to be profitable but rather their business. Small business fail largely in part because they don't understand they aren't the only business that matters in a deal.

What has made Xenforo largely successful is they created a product that appeals to the forum community and then they built a community of developers which helps them address needs not necessarily addressed by their software. In short XF doesn't have the money or staff to build a perfect solution for everyone so instead they built a platform and RM designed to allow developers which cost them nothing to contribute and provide solutions.

If I came here and posted what I had to have in a mod to be successful I wouldn't be told XF doesn't support that and GLHF, but rather I would be told to put in a suggestion where I can get feedback and possible solutions others have come up with that maybe I haven't.

 

[TPerry]

If I came here and posted what I had to have in a mod to be successful I wouldn't be told XF doesn't support that and GLHF, but rather I would be told to put in a suggestion where I can get feedback and possible solutions others have come up with that maybe I haven't.

In an ideal world this works... but a review of previous history of some (pretty sure ex now) licensees - their demands (and yes, I said demands) were a "tad" outrageous. As I said in my earlier post - the type of user that believes the world revolves around them are frequently not "cost efficient" to keep as a customer.

 

[Gladius]

I've been wondering for the last few pages if this thread still has anything to do with XF vs. some people's ideas on client management... Or is the message supposed to be that XF also has a lot of clients that it wants to get rid of?

The irony of some of the responses here given the source is really killing me.