Reason:
Having genericly named variable $id in nested loops makes code unreadable.
Replacing generic name '$id' with '$ENTITIY_id' format removes all ambiguity.
Two reasons:
- provide it to plugin backend functions that use 'contacts_autocomplete_after' hook
- provide it to frontend
Why to frontend?
If plugin JS adds an 'autocomplete_insert' hook we need to provide it with exact
autocomplete data. Providing it with name and email address only, without pinpointing
exact origin of this autocomplete result, will severely limit learning capabilities of
potential future autocomplete implementations.
Before the search worked only in Addressbook, not also in Compose.
The point of the change is also to align group searches with contact searches
in that it now uses the same set of attributes. Previously groups
in Compose were searched by name only.
Conflicts:
program/lib/Roundcube/rcube_addressbook.php
program/lib/Roundcube/rcube_contacts.php
program/steps/mail/search_contacts.inc
After last change to file `rcube_ldap.php`, my roundcube instance was getting this error:
```
PHP Fatal error: Cannot use object of type Net_LDAP3_Result as array in ...
```
In
```php
protected function extended_search($count = false)
```
`$result = $this->ldap->search()` returns a LDAP object (whatever package we use).
If the search returns no results (and if `$is_extended_search` is false), then it gets to line 971 trying to do a `usort()` and then a `count()` on an object, instead of an array.
A failure to load PEAR consistutes a fatal PHP error, and @-loading it prevents that error from being logged, making debugging problems with loading the PEAR class really difficult. It should therefore be loaded without the @ sign, allowing the fatal error to end up in the logs, if it occurs.
Symptom
=======
When using roundcube with mailboxes with over 60k messages, list
view was way faster than viewing in threaded view.
Mailbox index view timing: ~360 ms
Mailbox threaded view timing: ~800 ms
Resolution
==========
Use native PHP array manipulation functions instead of rolling custom
string data reversal implementation using strpos() and substr() in a
'while' loop.
This optimization is already present in index view handler, but was missing
from threaded view.
Results after optimization
==========================
Both average out around ~360 ms response time.
Aleksander Machniak