I'm trying to get it to match on "INBOX" or INBOX but nothing afterwards,
but some IMAP servers are returning an extra char or two on the end, so
a direct match is messing up, so I've tried something a little different
and told it to do a full match, but fail it if the next char after INBOX is
a delimiter (do we have a full list of possibilities?).
Tested on uw, courier, exchange, and cyrus, and the list builds nicely now.
uw still has some odd behaviours when you have a default folder prefix, but
the others seem a lot better... got to do some minor tweaks, and I think this
can go for full testing.
the default_folder_prefix area, also they return NIL for the delimiter which
means the previous regex would always fail as it is looking for a 1 char
delimiter between ""
link, which isn't good. Some weird stuff happens when using the default
folder prefix check, so removed... fixes courier and uw for having INBOXes,
now just have to make uw's inbox really work now.
prefix. INBOX was being added to the tree twice (was already the
root), and then because it was root, the link (with proper nesting)
wasn't being displayed.
Also corrected setting 'noselect' for INBOX (now tree root) -
was being errantly set as 'flag' which was causing errors about
not havign noselect set...
Also removed the places where it was checking whether or not
noselect was set for a mailbox - given the structure, noselect should
always be set - and we should get an error if it isn't (for boxlist
formed from LSUB).
Marc pointed out that \HasChildren is an extension, not part of IMAP4rev1.
Got the effect I needed from already existing code.
Summary: Display purge link for trash in all cases, this time done in accordance with RFC 2060. (Eliminates an extra IMAP call, too.)
Options for how folder selection list is displayed is on Folder Options page
Folder lists on Search, Folders, and Folder Options Pages, as well
as Folder selection lists used by the Message Index and the
Delete_move_next plugin all modified to use new Option list
creation method in imap_mailbox.
stuff in plugins.
Then I moved some files:
src/validate.php -> include/validate.php
src/load_prefs.php -> include/load_prefs.php
src/options_personal.php -> include/options/personal.php
src/options_display.php -> include/options/display.php
src/options_folder.php -> include/options/folder.php
Basically, the concept here is that src/ should ONLY contain files that
actually get called from the web browser as a php script directly. All
of these files do not really contain functions or anything (so the
functions/ directory did not really make sense), but were more strictly
include files.
Of course, the name functions for a directory is bad organization, IMHO,
anyhow. I guess class would fall in the same category. Oh well, some of
that might get fixed someday.
So, new rule. Only put it in src/ if it gets called directly.
That was really sort of an unwritten rule before. However, since it was
never really enforced or officialized, things got sloppy.
I think I have everything fixed in the CORE with this traumatic moves. I
am sure all of the plugins will be broken. Oh well, the error messages
should be pretty loud and easy enough to fix.
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.
