This is intended to be a debugging function. Ever wanted to do a print_r, but found that some of the values were "eaten" by your browser's parser because they had <> in them? Use this function instead. It runs htmlentities() on the output of print_r() AND as a bonus wraps the entire thing in <pre> and </pre> tags.
the comp_in_new works the same everywhere.
In this new function, make sure that comp_in_new still works when
JavaScript off.
When JavaScript off, do not output all kinds of JavaScript functions
which are never going to be called.
convert function names according to locales... bad php, but not much we can
do. Changed quoteIMAP to quoteimap to work around this for now. It's only
used during login as far as I can find.
faster. get_location already parsed php_self to get the url
e.g. /path/to/sqmail/src
So now, to make Locations compliant, you can either, call get_location if
you know the place you're redirecting to has the same url path you do
(src to src, for example), or check for 'sq_base_url' in the session vars,
call get_location to set it if it isn't there, and then use the
'sq_base_url' session var + base_uri from session + desired location to
redirect.
we split the streams to the new RC for 1.4.
check_sm_version performs similar function to check_php_version, and
will return true if version is >= what is specified.
For Thijs/Jonathan - the check_sm_version will return false if the
constant it checks against is not defined, making the function itself
safe for previous levels, should you want to roll it back to stable
to allow plugin developers to use the check_sm_version function to
test for 'new' elements like SM_PATH, etc. that are present in 1.3.x
and up.
More info (though not a ton, I'll admit) is in the sm2-planning module
in cvs: cvs co sm2-planning, then pull up sm2-planning/index.php in your
browser.
with a ? by SourceForge.net in your original log message, which follows:
Asunto: [SM-DEVEL] Bug in mime.php:decodeHeader()
De: Christian Schmidt <christian@ostenfeld.dk>
Fecha: S?b, 23 de Marzo de 2002, 14:48
Currently, the decodeHeader decodes headers containing several
encoded-words incorrectly. E.g. the header "=?iso-8859-1?Q?=C9?= and
=?iso-8859-1?Q?=E9?=" is decoded into "? and ?" and not into "? and ?"
as expected.
Also, it currently does not ignore white-space between consecutive
encoded-words as it should.
