Decode HTML entities in excerpts #2257
Conversation
mr-vinn
changed the title
|
I think the other |
|
Thanks for starting a pull request. I think the HTML entities should probably be decoded before the text is stored in the DB, that way you won't have to alter every point that the text is used. |
I wasn't sure if anything else was relying on the stored content being encoded, but if you think that's safe then I'm all for it. I'll replace this commit with a change that stores decoded text in the database. |
Decode HTML entities in page text before saving it to the database.
mr-vinn
force-pushed
the
preview-entities
branch
from
e2c609e
to
311a12b
Compare
|
The new commit saves decoded text in the database for pages. This does affect search functionality, but I think the existing behavior is a bug. Currently you have to use the HTML entity reference in the search string to get the expected results:
This commit fixes the search behavior along with the excerpt rendering. However, the PR will need a database migration to decode existing text content that's already been saved—I'll work on that next. |
|
Hi @mr-vinn, I'd say don't worry about decoding existing content in a migration. This issue is mainly cosmetic and I'd prefer to not have a fairly heavy operation in the migrations to just solve a cosmetic issue. I always try to minimise risk in the migrations where possible. If a way to update all existing plain text content is really warranted I'd prefer a command to be added which a user could optionally run but I don't think it is. |
That works for me; in that case this PR is ready to merge. |
mr-vinn
changed the title
|
Thanks again @mr-vinn, Testing added to prevent regression & merged to be in the next release. |
Decode HTML entities in the text content before returning an excerpt. Fixes #2114.