Page 1 of 1

[Mod Portal] Mod Medata info.json partially-Escaped

Posted: Thu Jul 09, 2026 5:12 pm
by eugenekay
What did you do?
Visited Releases Editor in the mod Portal to review Metadata fields used in the info.json file.

What happened?
Screenshot 2026-07-09 130140.png
Screenshot 2026-07-09 130140.png (134.82 KiB) Viewed 168 times
What did you expect to happen instead? It might be obvious to you, but do it anyway!
info.json would be displayed as it exists in the mod.zip file, with no characters being escaped:

Code: Select all

{
    "name": "zzz-null-mod",
    "version": "4.2.0",
    "title": "Null Mod",
    "author": "eugenekay",
    "factorio_version": "2.0",
    "space_travel_required": false,
    "description": "Null Mod to test Mod Portal behavior",
    "dependencies": ["base >= 2.0.7"]
}
It also looks like the fields have been re-ordered and displayed alphabetically, indicating that this is the output of an output_json() style function, not the raw file from the mod. This is not really a bug, but it does indicate that the data is being parsed somewhere.

Does it happen always, once, or sometimes?

Only in the Mod Portal. Examining the file with a Hex editor shows the expected ASCII character value (Octal 076) in the position where the WebUI displays the escaped Unicode sequence \003e.

Thanks for reading!

Re: [Mod Portal] Mod Medata info.json partially-Escaped

Posted: Fri Jul 10, 2026 2:50 pm
by Sanqui
The mod portal parses the info.json and stores the contents in a document store - it needs to be queried like any other data. The escaped strings could be fixed for displaying, the key ordering probably won't be.

Re: [Mod Portal] Mod Medata info.json partially-Escaped

Posted: Fri Jul 10, 2026 3:24 pm
by eugenekay
Sanqui wrote: Fri Jul 10, 2026 2:50 pmThe escaped strings could be fixed for displaying, the key ordering probably won't be.
Thanks, I suspected this was a parse-then-display issue of some sort. Reordering the top-level elements is totally fine per the RFC as this is an “unordered list” using curly brackets.

I have not tested if the internal order of the “dependencies” field is maintained; as it is an “array” using square brackets it should be unchanged per the RFC.