V1.10 beta - Vendor & Ldap issue

[riverco]

Hi,

I don't know if this is the right place , if not sorry please move it i just wanted to give the feedback?

using roundcube on a testinstall with scenario of upgrading existing 1.03 to 1.10.

LDAP address book searches fail after enabling debugging discovered it was searching for NET_LDAPV3. apparently this now has become a kolab plugin and the installer seemed not to have copied the vendor directory over to the roundcube directory after manually copying the vendor directory everything works.
Questions :
- Did something else have to be executed that might not have happened ?
- Why is the LDAP search for the addressbook now a kolab plugin ? Can we be ensured this does not jeopardize  for the future, roundcube deployments ? We do not use kolab we do use ldap servers. We favored roundcube during our evaluations of strategies time ago and decided that kolab is not an option at all (just our choice) can you assure us that the ldap functionality is also a roundcube initiative and that whatever happens will remain ?
Roundcube always worked fine with the LDAP servers without the sudden need to use kolab plugins.

great update further.

Regards,

[alec]

Net_LDAP3 is a library we use now. No kolab plugin is required. Maybe the problem is in the fact that ldap libs are "suggested" in composer.json, I don't know.

[bepi]

Hello alec,

try this update:

Code: [Select]

/roundcubemail-1.1-beta# ./bin/installto.sh /var/www/

Code: [Select]

PHP Fatal error:  Class 'Net_LDAP3' not found in /var/www/program/lib/Roundcube/rcube_ldap_generic.php on line 31
I confirm what said by riverco, to fix I had to perform a

Code: [Select]

/roundcubemail-1.1-beta# cp -a vendor /var/www/
the installer not have directives for the directory vendor

[riverco]

hi,
Like bepi confirmed about the installer, the issue is :

- The installer FORGETS (thus fails actually to properly upgrade our systems) to copy the entire vendor folder over during upgrade. Without this folder and the plugins in it roundcube is broken and will not function this the install script needs some revision doesn't it ?

The other issue i mentioned i will clarify a little :

- the REQUIRED ldap plugin is inside the vendor/KOLAB folder thus in my opinion now marked as Kolab (else what is i doing in the 3rdparty vendors Kolab folder ? ). Without it the adressbook does not work. I would be nice to hear from the roundcube team that this plugin despite being now marked as a kolab (vendor) plugin remains work of the roundcube team and/or will not suddenly become something proprietary. (just to remove a worry).

- Why are we worried ? We see some patches and modification being done that are there to benefit or kolab or other plugin vendors but aren't really documented (yet) and thus are obscure. example : there is now the feature to have a advanced setting but there is no explanation whatsoever as what variables should be put in that array (hoping these items all get documented), this is very unusual as the round-cube team always documented everything and would not do quick-fixes to accommodate others. (ie its a roundcube product not someone else and lets hope it stays that way). (just a worry nothing else no need to even answer)

Regards,

[ABerglund]

I agree with the confusion on the vendor/kolab folder, I still don't have LDAP working properly on my test server. (Although, to be fair, I'm running it on a different server than I have ever tried before due to the new PHP requirements - my production server, soon to be replaced, is on 5.3.3.)

Regarding the Advanced prefs option, that has been around for a couple of releases now. I can't remember if there was any description of it when released or not. But it seems intuitive enough to me. Just like the 'dont_override' array, you should be able to put almost any preference param in the 'advanced_prefs' array. For example, mine is pretty minimal:

Code: [Select]

$config['advanced_prefs'] = array(
        'reply_all_mode',
        'standard_windows'
);


[alec]

vendor/kolab is not a plugin. It is a library we use now (just like some PEAR libs), it is GPLv3-licensed. The library contains code that was previously included in Roundcube Framework (program/lib/Roundcube), now it is an external dependency.

[ABerglund]

If the kolab code is now a required dependency, should it not be included in the distribution package? Rather than depending on Composer or other methods?

[alec]

It is included in the package package marked as "Complete". "Dependent" package does not include external dependencies.

[ABerglund]

I always pull Complete, but didn't get that directory with the beta. I'll try it again, maybe the beta on the first day wasn't 100% together.

[riverco]

hi,

i get it now. So as of now we mandatory must always run composer regularly to make sure roundcube works and doesn't cease working (changes in functions depending on new features in the outside third-party plugs) ?

It would be good to clearly warn everybody about it (if it was done sorry missed it as i had no clue whatsoever about composer in fact never used it though use allot someone else pluginmanager . Because i never used composer and didn't realize we MUST use it the ldap issue occurred for me and i copied manually vendor directory , nobody even mentioned : no, not the way to do, you must use composer so there seems to be come confusion, good to know and learned something.
running composer now

Regards,