WMDE-leszek added a comment.

I don't claim to understand all details on how MediaInfo is implemented, but if I understood the problem, and I were to "fix" it, I would see three steps:

  1. Make Special:SetDescriptions and relevant API actions really only work with items and properties (unless already done in all places, description of this task suggests it might not be the case yet).
  2. Adjust the code turning the PHP object into JSON object for storage, and the opposite when loading JSON object from the database, so it ignores anything which claims to be a description. E.g. skip "descriptions" key etc. This would prevent storing any "description" data even if it somehow made up to the storage layer, and also unexpected leaking of incorrect data should it be already stored in historical revisions etc.
  3. Adjust the code turning the loaded the PHP object for JSON output, e.g. in API results. This code should be able to control what data is used for presentation, e.g. what "elements" of the MediaInfo object to display. This would prevent exposing any "descriptions" even if they for whatever reason ended up to be stored in the database.

Re points 2 and 3. It has seemed to be the case that "serialization/deserialization" in the storage layer, and "serialization/deserialization" in the presentation layer have been using the same logic, i.e. whatever was stored in DB was basically directly presented to the user. I would not consider this the best idea, and would suggest considering separating those two "serialization/deserialization" processes both conceptually, and also in terms of code.

I am not sure if this helps, should I be more specific (there have been quite exact class names being referred to in above comments etc), please request so.


TASK DETAIL
https://phabricator.wikimedia.org/T214692

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jdforrester-WMF, WMDE-leszek
Cc: WMDE-leszek, gerritbot, daniel, Jdforrester-WMF, Ramsey-WMF, Aklapper, Bugreporter, CucyNoiD, Nandana, NebulousIris, JKSTNK, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Cparle, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, V4switch, LawExplorer, Lewizho99, Maathavan, Silverfish, _jensen, Susannaanas, Wong128hk, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Matanya, Mbch331
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to