As we stabilize the 1.8 branch for future support with development eventually switching focus to 1.9, we’d like to draw your attention to the following advisories.

CAPTCHA Bug

Version 1.8.27 has introduced a bug affecting two of MyBB’s supported CAPTCHA mechanisms: reCAPTCHA v3 and hCaptcha invisible. For those, the CAPTCHA may appear broken, and the verification can reject or accept attempts incorrectly.

If your forum uses those systems, we advise to either:

• temporarily switch to another mechanism using the CAPTCHA Images for Registration & Posting setting (ACP: Configuration → Settings → General Configuration), or
• applying the upcoming changes to source code files manually.

This problem will be resolved in the next maintenance release.

Parser Output Validation

The upcoming maintenance release enforces validation of XHTML code generated by the MyCode parser in order to improve security.

MyBB 1.8.27 included this feature in report-only mode, meaning that any problems are already being saved to the configured error log. After upgrading, validation errors will continue to be logged, but messages with problematic MyCode will not be displayed to prevent potential XSS attacks against your forums.

Forum administrators should verify that their error logging is configured properly, and monitor the log for errors that may indicate necessary changes to their customizations like custom MyCodes, theme templates, username styles, and plugins. These errors can be triggered when forum content that uses MyCode is viewed.

We created a relevant Docs section that details pinpointing the origin, debugging using a dedicated tool, and disabling the validation requirement for boards that are not yet ready for this change.

Examples of Fixed Validation Errors

To help demonstrate what actions may need to be taken, let’s take a look at some validation failures that turned up so far:

• Case 1: Attributes Without Value in Default Templates

  MyBB’s default theme included HTML attributes without values. These caused validation errors such as:

  • Specification mandates value for attribute
  • attributes construct error

  To fix this, we simply added ="true" fragments where needed.

• Case 2: Redundant Tags in Username Style

  In a support thread, unnecessary HTML in a customized username style, present in a forum post, resulted in a logged failure that mentioned:

  • Opening and ending tag mismatch

  • Extra content at the end of the document

  This could be resolved by cleaning up the HTML code in the Username Style field for the problematic user group by removing stray closing tags.

• Case 3: Self-Closing Tags in Custom MyCode

  In another support thread, a custom MyCode included an unclosed <hr> HTML tag, which resulted in a validation failure that mentioned:

  • Opening and ending tag mismatch

  • EndTag: '</' not found

  For correct XHTML validation, tags that don't have an equivalent closing tag should include a forward slash: <hr />.

• Case 4: Invalid Placeholder Format

  A plugin that inserted invisible markers in the <example#0> format resulted in errors referring to attribute parsing and missing end tags. This format was changed to <example id="0" /> to pass the validation.

If you have trouble resolving validation failures, visit our support platforms and include the full logged error.

PHP Compatibility

MyBB aims to support most recent versions of web browsers, servers, database systems, and PHP interpreters. Due to significant changes in PHP 8.0, however, we recommended using PHP up to 7.4 while the code was being adjusted.

The upcoming MyBB release includes another batch of such adjustments, and removes some unnecessary side-effects of version-related PHP Warnings. We also pay attention to PHP 8.1, which is not expected to cause major problems after these updates.

Even though more issues may still be discovered when running MyBB on latest versions of PHP, we encourage administrators and extension developers to verify the stability of their forums and extensions on PHP 8, and to watch out for any errors that may appear in the error log, starting with the next maintenance release. Numerous web hosts already support switching to PHP 8.0, and MyBB can easily be tested locally using Docker.

Any suspected issues related to compatibility, as usual, can be reported on our support platforms.

With the continuous Community effort to improve the quality of our stable branch in the background, the work on remaining features of MyBB 1.9 moves on.

One of the completed changes that will make its way into MyBB 1.9’s highlights — other than the theme system — is the introduction of modern password hashing. The md5-based hash function, used in MyBB since its very beginning, will be replaced by bcrypt, making it much more difficult to obtain original passwords basing on new hash values in case of a data breach.

The current blocking task for other areas is rebasing the 1.9 branch on top of the 1.8 branch. Due to the way that Git (the tool we use to manage development) works, 1.9 is worked on in a separate branch whilst 1.8 development progresses. As the 1.8 branch moves forward, the 1.9 branch slowly goes out of sync, missing the recent changes from 1.8.

At the current moment, the 1.9 branch is in line with MyBB 1.8.17, leaving us with 4 versions’ worth of changes that we need to merge into 1.9. This, unfortunately, is not an easy process due to the nature of code changes in 1.9 and there are a lot of conflicts which need to be resolved manually. To ease this process we have decided to rebase one version at a time. Some MyBB 1.8 releases contain a smaller amount of changes than others, and these are considerably easier to rebase too.

Once the re-base is complete, there are still a couple of other tasks for 1.9 before we can release our first Alpha and Beta releases. Some of these issues include:

• Implementing a new email system. The current MyBB email system causes no end of support threads due to its limited support for slight variations in the way email servers “speak” the SMTP protocol. We’re proposing that we adopt an existing well tested and support email sending library to manage the sending of emails. From a core point of view, this should be relatively simple since almost every email sent uses a single standard function (my_mail()).

  We’re proposing that we adopt the new symfony/mailer library which provides easy ways to send email via SMTP as well as various email APIs such as Postmark.

• Reviewing any missed templates from the Twig conversion. During the rebase effort, we’ve noticed some lingering uses of the old template system within the core. These need to be rounded up and eliminated to ensure the template system usage throughout is consistent.

• Updating the ACP to allow editing of Twig template files. So far, the Team have all been editing Twig templates directly through their respective files. While this is a great way to work (who doesn’t want to use their own editor of choice?), being able to edit templates easily within the Admin Control Panel is a useful feature that needs updating to work with the new template system. There is some discussion about looking at the JavaScript code editor that we use when editing templates to see if there are any better options on the market. An often requested feature has been the ability to edit multiple templates within tabs at the same time, an enhancement which would be very handy when working with new templates.

  We’re also looking at the possibility of leaving certain level of support for the old template format to reduce the number of changes required in MyBB 1.8-based plugins to work with MyBB 1.9.

  Open the 1.9 Theme System Issue issue to see what design problems we’ll be aiming to solve, and to participate in the discussion, whether you’re an Extension guru or have previously noticed friction when dealing with themes in MyBB.

  

We will also be starting to update and introduce documentation for 1.9. If there are any documentation pages that you would like to see updated or improved, now would be a great time to bring them to our attention!