Don't decode before encoding for new installations #3171
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Derkades
force-pushed
the
fix/remove-decode-before-encode
branch
from
ade2a36 to
51ccc62
Compare
partydragen
requested changes
Feb 4, 2023
samerton
approved these changes
Apr 14, 2023
partydragen
approved these changes
Apr 14, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NamelessMC used to HTML-encode posts before saving them to the database. It no longer does. When this change was made, there was never a database migration to decode all encoded content. The reasoning for this was that this migration would be too slow.
Currently, before being encoded, content is always decoded first. This improves compatibility with content that was stored in encoded form, preventing it from being encoded twice. However, it also causes various issues for new content that is stored in non-encoded form.
Code snippets and more complex usage of special characters do not work properly.
With this change, the compatibility decoding has been made configurable. It is enabled by default for websites that upgrade from a previous version, and disabled (as it should always should be) for new installations.
Ideally it would only be enabled for websites that have upgraded from pr12, but I don't think there's any way to detect that?