Okay.. is there any info that you could give us for a developer to 
reproduce the problem, perhaps?

Actually it doesn't appear to deal with ticket #7117 as this isn't 
procmail nor maildrop related. I use IMAP. It may be 
IMAP_Search/IMAP_Search_Query related.

Sounds to me like followup is needed in #7117 and that this can be 
closed, then. Thanks for all of your tracing!

Scratch that. I have the changes as per ticket #7117 and ingo and 
horde/imp still have issues with "Destination"-based filter rules.

AHA! It turns out I had rules that were broken due to ticket #7117 and 
this broke ingo to the point where loading those rules later would not 
work AND even affected its ability to filter upon login THUS affecting 
Horde's ability to show up at all!



I see you guys fixed it JUST the other day. I hope. Close please.

Ok. That's probably where they were. I added them all back and it 
broke again. So I deleted them again and it loads again. I'm going to 
add them one by one and see if any in particular break it.

It depends how you set up Ingo. I think the default is in user preferences.

Welp I didn't WANT to do this w/o looking at data but I fixed it. For 
now, atleast. I deleted all of my filters and I was able to get in 
just fine. I'll see later on if filters will break it or if it was 
just something bad about an old filter.



I couldn't seem to find it though. Are filters stored in the datatree?

Already ahead of you there and JUST found something deeper. It seems 
to be happening upon filtering on login. It doesn't get past this in 
the loginTasks:



$imp_filter->filter('INBOX');



I DID just recently notice I was behind on the SQL for ingo. None of 
the "shares" tables were in there, so I added all of the related 
lines. Still no changes in this issue though even after going in and 
logging out and logging back in.

Okay... can you dig into that function then? This isn't a general 
problem right now - no developer that I know of is having it - so we 
really need as specific a diagnosis as possible to try and help you. 
Thanks!

Aha, seems to fail whenever it calls:

IMP_Session::loginTasks();

You need to run a debugger or put in some echo statements to see where 
it's breaking, then.

"Doesn't load" as in it's blank. It doesn't get past redirect.php on 
its own upon loading after login, and if I just give it /horde, the 
left frame is blank. And /horde/imp is blank. Same for dimp and mimp. 
Other modules are fine.



And yeah my first thought was a segfault, but I didn't find anything 
in the apache error logs.

What do you mean by "doesn't load"? Have you checked your httpd logs 
for segfaults or other errors? And what changed when this started?

For atleast the past month I've had issues loading IMP. The main horde 
page does not load unless I change the url to just /horde/ from the 
default /horde/imp/redirect.php, and the left side frame doesn't load. 
All other modules load just fine.



I would figure out what was wrong on my own, but the debug log doesn't 
say much:



Oct 28 20:17:58 HORDE [debug] [imp] Hook 
_prefs_change_hook_last_maintenance in application horde not called. 
[pid 17185 on line 1686 of "/usr/share/php/Horde.php"]

Oct 28 20:17:58 HORDE [debug] [ingo] Max memory usage: 2097152 bytes 
[pid 17185 on line 339 of "/usr/share/php/Horde/Registry.php"]

Oct 28 20:17:58 HORDE [debug] [ingo] SQL Query by Prefs_sql::store(): 
SELECT 1 FROM horde_prefs WHERE pref_uid = ? AND pref_name = ? AND 
pref_scope = ?, values: jouva@moufette.com, last_maintenance, horde 
[pid 17185 on line 210 of "/usr/share/php/Horde/Prefs/sql.php"]

Oct 28 20:17:58 HORDE [debug] [ingo] SQL Query by Prefs_sql::store(): 
UPDATE horde_prefs SET pref_value = ? WHERE pref_uid = ? AND pref_name 
= ? AND pref_scope = ?, values: 1225239478, jouva@moufette.com, 
last_maintenance, horde [pid 17185 on line 244 of 
"/usr/share/php/Horde/Prefs/sql.php"]





And there are no apache errors related to this. Is there a SQL update 
for imp I might not be aware of? Or any other pieces I need to be 
aware of?