Try out the XenForo 2.3.8 Preview!

[bzcomputers]

Technically speaking wouldn't this be a Release Candidate (RC) and not a Preview? Especially since it is just for final bug crushing and is feature complete and your intention is for a final release short term (within a week or so if all goes well). To me this screams RC and not Preview.

I always thought an RC cycle would benefit XenForo. It's not unusual for a inconvenient bug to show itself 24-48 hours after a release to the public. RC releases just cut down on the need for official patches, unofficial patches, and at times pushing unsuccessful bug fixes or newly created issues down the road months.

 

[Chris D]

It's just semantics. You're correct, but we wanted to distinguish this from the usual beta/rc/stable process we normally follow for major releases.

There also won't be a second, third, forth release candidate like there usually would be. There's usually a continual feedback loop for release candidates which isn't going to happen here.

 

[Mike Fara]

This is a bug in XenForo 2.3.8 Preview. The issue is on line 61 of WebhookSend.php:

$webhook->criteria[$this->data['content_type']],

The code assumes $webhook->criteria has a key for every content type (like "post"), but if the webhook was created before this criteria feature existed (or the criteria was never set for "post"), the array key doesn't exist.

Root Cause: Webhooks created before 2.3.8 (or those that weren't updated after upgrade) have an empty criteria array ([]), but the new code expects criteria['post'] to exist.

 

[Rene_V]

This is a bug in XenForo 2.3.8 Preview. The issue is on line 61 of WebhookSend.php:

$webhook->criteria[$this->data['content_type']],

The code assumes $webhook->criteria has a key for every content type (like "post"), but if the webhook was created before this criteria feature existed (or the criteria was never set for "post"), the array key doesn't exist.

Root Cause: Webhooks created before 2.3.8 (or those that weren't updated after upgrade) have an empty criteria array ([]), but the new code expects criteria['post'] to exist.

I think it would be better if you posted this at the Bug reports forum.

Bug reports

If you find an error or something that looks out of place in XenForo 2.x, please let us know here. A developer will look into your report as soon as possible. Please do not report bugs in add-ons here. Official add-ons have their own bug forums.

xenforo.com

 

[Ricsca]

What are the differences with this version?

 

[smallwheels]

What are the differences with this version?

Look further up this thread:

wish there was a bug list so we can check

A lot:
https://xenforo.com/community/forums/resolved-bugs/ pretty much goes back to page 7.

Given the massive amount of fixed issues it makes possibly sense to watch out for uncommon behavior in general - it is one thing to fix a bug check if the fix is working and another to find unexpected side effects of 100+ fixes anywhere in the product...

 

[PhineasD]

Running perfectly on one of my forums.

Let's go to the next one...

 

[frm]

Given the massive amount of fixed issues it makes possibly sense to watch out for uncommon behavior in general - it is one thing to fix a bug check if the fix is working and another to find unexpected side effects of 100+ fixes anywhere in the product...

Arguably, this is applicable to any 3rd point releases, and not only the preview.

 

[Chris D]

This is a bug in XenForo 2.3.8 Preview. The issue is on line 61 of WebhookSend.php:

$webhook->criteria[$this->data['content_type']],

The code assumes $webhook->criteria has a key for every content type (like "post"), but if the webhook was created before this criteria feature existed (or the criteria was never set for "post"), the array key doesn't exist.

Root Cause: Webhooks created before 2.3.8 (or those that weren't updated after upgrade) have an empty criteria array ([]), but the new code expects criteria['post'] to exist.

I think it would be better if you posted this at the Bug reports forum.

Bug reports

If you find an error or something that looks out of place in XenForo 2.x, please let us know here. A developer will look into your report as soon as possible. Please do not report bugs in add-ons here. Official add-ons have their own bug forums.

xenforo.com

That is correct, yes, but we've got this one sorted anyway. Thank you @Mike Fara!

 

[frm]

That is correct, yes, but we've got this one sorted anyway. Thank you @Mike Fara!

Is the preview going to continuously roll updates if something is found/fixed or will that be reserved for the 2.3.8 release only?

So far, there's only one(?) bug found. But if this is going to be an ongoing process (previews), it should be made clear that there's a Preview 2, Preview 3, etc. or all bugs found in the initial preview — the one and only — will be made with the version successor.

 

[Chris D]

This is implied in the first post but there will only be one Preview and it will not be updated.

The next release will be 2.3.8 stable.

 

[Suzanne O]

This is implied in the first post but there will only be one Preview and it will not be updated.

The next release will be 2.3.8 stable.

Good to know. Thanks mate

 

[Mendalla]

I have to say, I like the idea of doing previews for patch releases in principle. Not sure it is always needed but for one as full as this one, definitely worth letting the community have at it.

 

[frm]

This is implied in the first post but there will only be one Preview and it will not be updated.

Thanks for the clarification.

I like the preview situation you have come up with. A nice middle ground.

I was content with @XF Bug Bot posts, myself. Though, they often get bumped and forgotten about where users then come to the conclusion "nothing is being done".

Perhaps a suggestion would be to not only reply with the fix in the reported thread but also create a new thread with the fixes for that version id, and post the same thing as a reply there, too, to consolidate them for easy tracking . It'd be easier to see "progress" from a single "XenForo 2.3.8 reported and fixed bugs" thread, and possibly make the announcement thread easier to post with copy/paste from one thread; though, I would only assume you are tracking and formatting internally as you go already.

 

[Chris D]

Yeah the change log list we generate for release announcements is entirely generated automatically.

 

[frm]

Yeah the change log list we generate for release announcements is entirely generated automatically.

Alternative to the new thread consolidating them, you could start using the prefix "Fixed 2.3.8" or tagging the threads with the version release number, too. That way there's always a link to point users to all the work that's been done on a specific version vice telling someone to check @XF Bug Bot history or that "bug bot has been active". Tagging shouldn't be too hard over prefixes if you could automate the tag from the update — probably the simplest and cleanest way of doing it (as opposed to automating a prefix creation and then assigning that going forward).

Just food for thought.

 

[Lee]

Might be a good opportunity to implement multiple prefixes #wishfulthinking

 

[frm]

Might be a good opportunity to implement multiple prefixes #wishfulthinking

True. But there's the problem of prefixes then, in this specific case, as the first bot would need to create the prefix and choose "Fixed" and the newly created "2.3.8" secondary prefix to accompany it. I'm sure in 10 years, they won't want 100s of prefixes in the ACP to manage — or hit a "prefix limit" that creates a bug to fix on its own.

Tagging would be best in this case, as it is now, it's "hard" to track updates and fixes by just looking at the thread in a list: is it fixed for 2.3.7 or 2.3.8? You have to go thread by thread to see.

 

[Alpha1]

Cough, Search & Filter custom fields. Cough, cough.

 

[Chris D]