XF 2.4 general discussion, feedback, complaints, random off topic posts, etc.

[James]

Interesting. If I use samsung keyboard I get a similar error. SwiftKey just inserts the url as text.

 

[Forsaken]

This started happening recently with Discord as well occasionally.

 

[Max Fridman]

I am happy that the Xenforo team has decided to listen to users and customers and change.

By communicating more, and updating the software more frequently avoiding long time gaps of abandonment that make things more complex for us.

I would like to ask if it would be possible, however, in these announcements to include previews of the areas of Xenforo that will be updated.

Let me explain further. If the Xenforo team announces 2.4 and tells me "The trophy system will be updated" or "We will take a look at the site statistics dashboard." I might for example not purchase addons related to these systems or commission them from third-party developers.

Currently, with this appreciated but extremely generic announcement system, I basically block anything I would like to develop or purchase until Xenforo is updated or all the new features of 2.4 are announced, but they will be announced "when they are ready," and this then blocks me for an indefinite period of time.

This can be a null issue, for most sites that being hobbyists or people not even interested in deep updates, do not have the need to know the future beyond mere curiosity.

On the other hand, for those who use Xenforo in a highly customized way and invest considerable amounts of money to make it a more complex platform, they need to know this information, even for developers I think it is useful to be aware of it.

So that we do not waste time developing something that will be integrated into the core software and made obsolete.

Do not take this remark of mine as yet another complaint. I would be content with a bulleted list, no need to go into details, leaving the publication of the HYS unchanged, with all the details of each implementation.

Just as we know that 3.0 will largely revolve around the theme and in 2.4 we will have the new editor.

I hope this change will be embraced. It would be the icing on the cake on the communication level.

I honestly prefer this than knowing for sure when an update is coming.

Otherwise, I am very curious to see what has been thought up by the Xenforo team

 

[vbresults]

It would be great to have some of the key enhancements from here for devs.

With IPS I can export add-ons from the admin area, while without that add-on, for XF I'd have to use the CLI.

 

[Paul B]

I would like to ask if it would be possible, however, in these announcements to include previews of the areas of Xenforo that will be updated.

Let me explain further. If the Xenforo team announces 2.4 and tells me "The trophy system will be updated" or "We will take a look at the site statistics dashboard." I might for example not purchase addons related to these systems or commission them from third-party developers.

Currently, with this appreciated but extremely generic announcement system, I basically block anything I would like to develop or purchase until Xenforo is updated or all the new features of 2.4 are announced, but they will be announced "when they are ready," and this then blocks me for an indefinite period of time.

That's what the HYS threads are for.

 

[Max Fridman]

That's what the HYS threads are for.

HYS posts from what I have read will be published as features are completed. Because it is not perfectly clear what will be included in 2.4.

That still forces us to wait for these posts to be published. Which we don't know when it will come. Blocking investment in our sites. Because if I spend 2000€ on an addon that is then included in the core or relies on a core feature that is being scrambled I've either thrown them away or I have to take on additional development costs.

Instead, my point was, when publishing an introductory post like the one linked in the first post of this discussion, include even just a bulleted list of parts of Xenforo that are going to be touched.

Then possibly delay publication until you have all the major features already decided, or include the most relevant ones, even if only with a bulleted list.

This would allow us to reduce uncertainty for our business.

It is like the municipality starting renovations in a neighborhood without giving a timeline in which the work will be done. When the power will be turned off, or a road will be closed. That is, we know that these works will indicatively end in Q1 2025, and that is perfectly fine with me. But it would be most useful to know what is being changed sooner rather than later so that we can keep working.

Then this is my feedback, I understand the issues related to this request of mine, it would reduce the flexibility that the team has maybe to slip a feature to a later version or other possible communication issues with people.

But we have companies that work with Xenforo, our issues are different from hobbyists.

Then to ask politely is courtesy, if it is not possible rest in peace. I will take note and grit my teeth waiting for HYS.

 

[Paul B]

You won't have to wait too long.

The release cycle is much shorter and HYS threads are going to be published during it, not at the end of it.

 

[Max Fridman]

You won't have to wait too long.

The release cycle is much shorter and HYS threads are going to be published during it, not at the end of it.

Oh okay, let's see how it goes then. It's a new method of all-around communication I'm glad you took this path to help us customers further.

Thank you again.

 

[Chris D]

HYS posts from what I have read will be published as features are completed. Because it is not perfectly clear what will be included in 2.4.

That still forces us to wait for these posts to be published. Which we don't know when it will come. Blocking investment in our sites. Because if I spend 2000€ on an addon that is then included in the core or relies on a core feature that is being scrambled I've either thrown them away or I have to take on additional development costs.

Instead, my point was, when publishing an introductory post like the one linked in the first post of this discussion, include even just a bulleted list of parts of Xenforo that are going to be touched.

Then possibly delay publication until you have all the major features already decided, or include the most relevant ones, even if only with a bulleted list.

This would allow us to reduce uncertainty for our business.

It is like the municipality starting renovations in a neighborhood without giving a timeline in which the work will be done. When the power will be turned off, or a road will be closed. That is, we know that these works will indicatively end in Q1 2025, and that is perfectly fine with me. But it would be most useful to know what is being changed sooner rather than later so that we can keep working.

Then this is my feedback, I understand the issues related to this request of mine, it would reduce the flexibility that the team has maybe to slip a feature to a later version or other possible communication issues with people.

But we have companies that work with Xenforo, our issues are different from hobbyists.

Then to ask politely is courtesy, if it is not possible rest in peace. I will take note and grit my teeth waiting for HYS.

We discussed this and even planned initially to do this. To give an overview of everything we had planned (albeit not necessarily the detail).

The reason we decided against it is that going into development, particularly bigger features in a well established code base, there will always be a certain number of unknowns. We don’t want to announce features, run into major issues (such as an inability to maintain backwards compatibility) and then not be able to deliver those features.

We are trying to be careful in not promising something we can’t deliver.

Ironically this approach is more viable for a release with a longer development cycle. So that could be something that we do in the future, but that’s not the case here.

 

[Forsaken]

You won't have to wait too long.

The release cycle is much shorter and HYS threads are going to be published during it, not at the end of it.

Do you have nightmares about the whining you're still going to get?

 

[Chris D]

Nah. We know we can’t do anything right. We’ve accepted that.

 

[Max Fridman]

We discussed this and even planned initially to do this. To give an overview of everything we had planned (albeit not necessarily the detail).

The reason we decided against it is that going into development, particularly bigger features in a well established code base, there will always be a certain number of unknowns. We don’t want to announce features, run into major issues (such as an inability to maintain backwards compatibility) and then not be able to deliver those features.

We are trying to be careful in not promising something we can’t deliver.

Ironically this approach is more viable for a release with a longer development cycle. So that could be something that we do in the future, but that’s not the case here.

Yes I imagined, in fact I suspected it was not easy at all, it is definitely something that can backfire.

But at least you'll keep it in mind for other development cycles, though, that's important.

I am confident that you will do a great job.

 

[mjda]

Nah. We know we can’t do anything right. We’ve accepted that.

On the bright side, at least you're always pleasing half of the user base.

 

[Max Fridman]

On the bright side, at least you're always pleasing half of the user base.

Honestly when the bulk of the complaints come from users with 0 investment beyond a basic license and maybe a Cloud plan.

I don't think it makes sense to keep arguing or listening.

Everything that has been asked, in the right ways, has always been done honestly, within the limits of feasibility.

I don't think there are many platforms with this kind of philosophy.

 

[mjda]

Honestly when the bulk of the complaints come from users with 0 investment beyond a basic license and maybe a Cloud plan.

Those "basic" license holders, and cloud plan customers, are probably the only reason XF exists. I'd imagine those are the folks who make up a vast majority of the company's revenue. Admittedly, though, I really don't have a clue and I could be completely off-base. I'm just a lowly basic license holder myself.

I am curious, though, do you have something other than a basic license and/or cloud plan? If so, how'd you acquire that?

 

[Max Fridman]

Those "basic" license holders, and cloud plan customers, are probably the only reason XF exists. I'd imagine those are the folks who make up a vast majority of the company's revenue. Admittedly, though, I really don't have a clue and I could be completely off-base. I'm just a lowly basic license holder myself.

I am curious, though, do you have something other than a basic license and/or cloud plan? If so, how'd you acquire that?

This is probably also true. Certainly it is more the tens of thousands of small forums that do the bulk of the licensing.

I was referring to the fact that there are some big players who invest thousands each year on Xenforo, between custom feature development and addon renewals, and they ALWAYS renew licenses to have constant security updates, while most licenses are not renewed until Xenforo upgrades.

The license is that, we all have the same one, however the Cloud plan can scale up to Enterprise. Most of the big sites I think are on dedicated solutions though.

However we are all customers and any feedback is important of course, mine was just a provocation. I think everyone has to take into account that what they say has repercussions on a platform used by other companies as well.

Many users talk as if Xenforo is only used by sites with less than 100 users.

 

[Mike Fara]

In strong contrast to something someone else wrote in this thread awhile back, I strongly believe that XenForo should natively support full Markdown. This is easier said than done while also processing BBCode. I hope that this new editor might bring changes to the BBCode parser to also support full native Markdown processing and handle conflicts between BBCode and Markdown. This could bridge the long divide between these two content types, as in the end they are both converted to HTML.

 

[frm]

Instead, my point was, when publishing an introductory post like the one linked in the first post of this discussion, include even just a bulleted list of parts of Xenforo that are going to be touched.

I'm thoroughly confused now. Which is it?

The release cycle is much shorter and HYS threads are going to be published during it, not at the end of it.

We discussed this and even planned initially to do this. To give an overview of everything we had planned (albeit not necessarily the detail).

Fully developed HYS threads as we're accustomed to when a feature is completed or HYS threads with minimal information until it's completed?

 

[Chris D]

I think @Max Fridman was mostly asking about giving more information up front before development takes place as to what we’re planning to include.

HYS threads are still planned for feature completion.

 

[frm]

I think @Max Fridman was mostly asking about giving more information up front before development takes place as to what we’re planning to include.

How would this information be disseminated? Planning on another series beyond HYS for each planned, but not "committed to", feature?

I am just curious as to how to spread this information in a more logical way that is easily accessible and also is not jumbled together in a huge thread like this one.

Planned for Development Feature threads? Some PDFs as you will?