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 |
State ⇒ Not A Bug
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.
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
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.