No Code Attached Yet bug
avatar klucon
klucon
29 May 2020

Steps to reproduce the issue

  1. Download test modul from https://build.klucon.cz/mod_kluconholiday_1_2_0.zip (only Czech lang, but it is not problem)
  2. Go to Administrator -> System -> Extensions and search word "klucon" and open it
  3. Click to version number and compare with the file changelog_mod_kluconholiday.xml
  4. In the file is only 3 lines, but in the changelog is 6 lines
  5. For the all files I was use UTF-8 without BOM

Expected result

Actual result

System information (as much as possible)

I was tested on last Night Build from citate: "These packages were last built: Friday, 29 May 2020 02:00:24 UTC"

Additional comments

avatar klucon klucon - open - 29 May 2020
avatar joomla-cms-bot joomla-cms-bot - change - 29 May 2020
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 29 May 2020
avatar klucon klucon - change - 29 May 2020
Title
Changelog Bugs with diacritics
[4.0] Changelog Bugs with diacritics
avatar klucon klucon - edited - 29 May 2020
avatar ReLater
ReLater - comment - 29 May 2020

Confirmed.

I don't know if it should work in a different way but I would enclose the lines with CDATA comments

<fix>
		<item><![CDATA[
			Oprava položky u data 15-12
		]]></item>
</fix>

30-05-_2020_00-31-54

avatar klucon
klucon - comment - 29 May 2020

Thank you ReLater,

when I used CDATA, it is OK.

avatar ReLater
ReLater - comment - 29 May 2020

Yes, but I couldn't find a reason why it doesn't work without CDATA. Tried a lot to enforce UTF-8 while parsing... checked encoding of your file... added <?xml version="1.0" encoding="UTF-8"?> ...

avatar richard67
richard67 - comment - 30 May 2020

Maybe encoding of the webserver itself is still not utf-8 (just to be sure)?

avatar richard67
richard67 - comment - 30 May 2020

If all is set up for utf-8 it should not need the CDATA in my opinion, but I might be wrong.

avatar ReLater
ReLater - comment - 30 May 2020

I've tested it also with my custom site (and a custom changelogurl on it) that runs with utf-8 for sure.

Maybe the httpRequest (I don't know how it's called correctly) gets the wrong encoding ? The wrapped lines happen very early in the PHP parser logic.

I've found a very old comment yesterday https://www.php.net/manual/en/function.xml-parser-create.php#100099

The original parser sometimes wrapped the text before the first diacritics appearance.

avatar richard67
richard67 - comment - 30 May 2020

@ReLater The comment after that one reads also interesting, encoding ... even if 15 years old it could still be relevant.

avatar ReLater
ReLater - comment - 30 May 2020

I didn't try with UTF-8 plus BOM because that wouldn't be practicable for devs. Perhaps @klucon wants to try? Just for the sake of clarity.

avatar klucon
klucon - comment - 30 May 2020

Hello,
now I have converted all the files to UTF-8 with BOM and the same problem.

Here is a UTF-8 ZIP file with BOM:

https://build.klucon.cz/mod_kluconholiday_with_bom.zip

If I use CDATA, everything is alright

Maybe encoding of the webserver itself is still not utf-8 (just to be sure)?

I am testing on the XAMPP (compiled Jun 5th 2019) and Windows 10
Apache/2.4.41 (Win64) OpenSSL/1.1.1c PHP/7.3.12

Yes, but I couldn't find a reason why it doesn't work without CDATA. Tried a lot to enforce UTF-8 while parsing... checked encoding of your file... added <?xml version="1.0" encoding="UTF-8"?>

when I added <? xml version = "1.0" encoding = "UTF-8"?>, no change took effect

avatar ReLater
ReLater - comment - 30 May 2020

@klucon
Thank you for testing!

avatar brianteeman
brianteeman - comment - 20 May 2021

tested with and without bom - no change :(

avatar Hackwar Hackwar - change - 20 Feb 2023
Labels Added: No Code Attached Yet bug
Removed: ?
avatar Hackwar Hackwar - labeled - 20 Feb 2023

Add a Comment

Login with GitHub to post a comment