6.0.0-beta1
7/4/25

[#14228] Driver "Ingo_Script_I" cannot be loaded due to variable type confusion
Summary Driver "Ingo_Script_I" cannot be loaded due to variable type confusion
Queue Ingo
Queue Version 3.2.7
Type Bug
State Not A Bug
Priority 2. Medium
Owners
Requester max.grobecker (at) ml (dot) grobecker (dot) info
Created 01/24/2016 (3449 days ago)
Due
Updated 01/25/2016 (3448 days ago)
Assigned
Resolved 01/25/2016 (3448 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
01/25/2016 12:59:51 PM Jan Schneider Comment #2
State ⇒ Not A Bug
Reply to this comment
You didn't follow the upgrade instructions. 
http://www.horde.org/apps/ingo/docs/UPGRADING

This is a support question, not a bug report.

Please use the mailing lists to ask for support.

http://www.horde.org/mail/ contains a list of all available mailing lists.
01/24/2016 02:55:29 AM max (dot) grobecker (at) ml (dot) grobecker (dot) info Comment #1
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Driver "Ingo_Script_I" cannot be loaded due to variable type confusion
Queue ⇒ Ingo
Milestone ⇒
Patch ⇒ No
Reply to this comment
Hello,

After upgrading to Horde 5.2.11 from 5.1.x Ingo stopped working at 
several points.
One of these points is, that I can't add new filter rules by clicking 
on an e-mail address in a received mail and create a filter of it.
It appears an error message that the driver "Ingo_Script_I" cannot be loaded.

The most likely reason seems to be that in 
/ingo/lib/Factory/Script.php seems to be some confusion of variable 
contents.
It seems to be expected, that $scripts needs to be an array:

---------------
    public function create($rule)
    {
           ......

         if ($rule != Ingo::RULE_ALL && isset($scripts[$rule])) {
             $script = $scripts[$rule];
             $skip = array_diff(
                 array(Ingo::RULE_FILTER, Ingo::RULE_BLACKLIST,
                       Ingo::RULE_WHITELIST, Ingo::RULE_VACATION,
                       Ingo::RULE_FORWARD, Ingo::RULE_SPAM),
                 array($rule)
             );
         } else {
             $script = $scripts[Ingo::RULE_ALL];
             $skip = array_keys($scripts);
         }
---------------

But in my case, $scripts has the value (string) "sieve".

Since (const) Ingo::RULE_ALL has the value (int) 1
$script gets assigned the value "i", which later gets converted to 
uppercase and is then used as part of a class name.

I don't know if this is something that happened during an error while 
upgrading - but this file has the same mtime timestamp as all other 
PHP files in my installation, so I assume it got touched during the 
upgrade.

Saved Queries