php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #64593 Enchant fails to load any backends.
Submitted: 2013-04-05 19:41 UTC Modified: 2013-04-09 16:46 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: wschalle at gmail dot com Assigned: ab (profile)
Status: Closed Package: Enchant related
PHP Version: 5.3.23 OS: Windows 7, Windows Server 2008R2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
26 - 1 = ?
Subscribe to this entry?

 
 [2013-04-05 19:41 UTC] wschalle at gmail dot com
Description:
------------
This bug was introduced in 5.3.23. It also exists in 5.4.13. Both the CLI and 
CGI 
SAPIs are affected.

When the enchant broker is initialized, it seems to silently fail to load the 
backends. Enchant_broker_get_error returns false, and nothing is logged to the 
php 
error log or the system event viewer. 

I tested this with the public win32 VC9 NTS zips of PHP. I verified that 5.3.22 
works as expected, with enchant_broker_describe listing both ISPELL and MYSPELL 
backends.

Looking at the diffs from 5.3.22 to 5.3.23, the most likely culprit seems to be 
either the win32 registry.c change, or maybe the directory changes. Either way, 
downgrading to 5.3.22 is currently still a viable workaround.

Test script:
---------------
$broker = enchant_broker_init();
enchant_broker_set_dict_path($broker, ENCHANT_MYSPELL, __DIR__);
var_dump(enchant_broker_describe($broker));
var_dump(enchant_broker_get_error($broker));

Expected result:
----------------
array(2) {
  [0]=>
  array(3) {
    ["name"]=>
    string(6) "ispell"
    ["desc"]=>
    string(15) "Ispell Provider"
    ["file"]=>
    string(35) "C:\PHP-5.3.x\libenchant_ispell.dll"
  }
  [1]=>
  array(3) {
    ["name"]=>
    string(7) "myspell"
    ["desc"]=>
    string(16) "Myspell Provider"
    ["file"]=>
    string(36) "C:\PHP-5.3.x\libenchant_myspell.dll"
  }
}
bool(false)

Actual result:
--------------
NULL
bool(false)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-04-09 13:07 UTC] ab@php.net
Put the plugin dlls should load if you put them into <php dir>\lib\enchant.
 [2013-04-09 13:07 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2013-04-09 13:40 UTC] wschalle at gmail dot com
Putting the DLLs in <php_dir>\lib\enchant works.
 [2013-04-09 13:40 UTC] wschalle at gmail dot com
-Status: Feedback +Status: Open
 [2013-04-09 14:01 UTC] ab@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: ab
 [2013-04-09 14:01 UTC] ab@php.net
Great, thanks for checking.

With the dicts you could also use the enchant_broker_set_dict_path() or just put the dicts into  <php dir>share\myspell\dicts.
 [2013-04-09 15:05 UTC] wschalle at gmail dot com
Any idea why this broke between 5.3.22 and 5.3.23?

We tend to put dict files in the app, because some instances use different 
dictionaries.
 [2013-04-09 15:26 UTC] ab@php.net
libenchant loads all the *.dll it can find in the plugin dir and discards those being not a plugin. That's why one could see some startup warnings in previous versions, as it was <php dir>. Now it loads from a separate path where only the plugins should be. I'd see it more like an improvement. That should be documented though, mood for that? :)
 [2013-04-09 16:46 UTC] wschalle at gmail dot com
That makes sense, but where was this change even made? Public releases of PHP 
should have the libs in the right places when you unzip them...
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Apr 01 12:01:22 2020 UTC