Bug #5134

The handling of base64 encoding in the package XML is insane

Added by Kill Bill over 4 years ago. Updated over 4 years ago.

Package System
Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
Affected Architecture:


The XML is gonna happily swallow the <encoding>base64</encoding> tag for pretty much any field type [1] (even those where it makes absolutely no sense, such as checkbox), however, subsequently it will only decode the value for textarea tag [2]. As a result, when you use this in a package somewhere else than in textarea, the value gets base64-encoded on every save. Again, again, and again. It'd be kinda useful to be able to use for other things, such as, hmmmm... passwords that screw up the config.xml when people put special chars in there (which they frequently do).


Associated revisions

Revision 6e5cec8e (diff)
Added by Doktor Notor over 4 years ago

pkg_edit.php - base64 encoding/decoding fixes (Bug #5134)

Currently, the base64 is only usable for textarea fields - see Bug #5134 for details.

This adds base64_decode() to input and password field types if <encoding>base64</encoding> tag is set for those fields (also for rowhelpers) to prevent the values from getting perpetually re-encoded which makes it unusable for those field types.

Ideally, usage of the <encoding> tag should be prevented for fields type where it doesn't make any sense whatsoever, someone else needs to look into that, the packages.dtd XSD schema is a pathetic useless POS.


#1 Updated by Chris Buechler over 4 years ago

  • Status changed from New to Confirmed

#3 Updated by Steve Beaver over 4 years ago

  • Status changed from Confirmed to Feedback

Addressed by PR 2071 now merged.

#4 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Resolved
  • Target version set to 2.3

Also available in: Atom PDF