Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHP 8.x incompatibility #56

Open
sig-critchie opened this issue May 11, 2023 · 4 comments
Open

PHP 8.x incompatibility #56

sig-critchie opened this issue May 11, 2023 · 4 comments

Comments

@sig-critchie
Copy link

Currently, this module does not support any version of PHP 8, due to the reasons documented below.
I have done some work to resolve these issues and tested them in a production system. I would like to create a pull request, so my fixes can be used as the basis of version 1.7 of this module. I do not think they should be merged into 1.6, as one of these fixes only works with 8.1 and above.

Can a 1.7 branch please be created, so I can create a pull request (I did not want to create one against 1 branch, as this does not seem to align with your workflow).

FYI @GuySartorelli

zend-ldap

Since PHP 8.1, LDAP related functions return an object instead of a resource, causing various is_resource() checks to error.
The module needs to be migrated to laminas/ldap equivalent to resolve this issue.
See #36

ldap_control_* functions

The current implementation of pagination relies on ldap_control_paged_result() and ldap_control_paged_result_response() functions to request multiple pages of data from LDAP as needed. As of PHP 8, both functions have been deprecated in favor of passing control parameters to ldap_search(). The call to ldap_search() updates the control parameters with a cookie which can be passed to subsequent calls to get further result sets.
See #35

method_exists()

LDAPService passes null to method_exists() while iterating through LDAP field mappings.

@GuySartorelli
Copy link
Member

GuySartorelli commented May 11, 2023

Hiya,

Thank you for this. Please raise the PR against the 1 branch for now - we don't create minor branches (e.g. 1.7) until we're ready to release a new minor version - that means everything targetting 1 will automatically be targetting a new minor release in the 1.x release chain. And regardless of which branch is initially targetted, we can always retarget it later after reviewing the PR if we feel that is appropriate.

@sig-critchie
Copy link
Author

Sounds good to me.

@GuySartorelli
Copy link
Member

@sig-critchie Heya,
Just wondering if you've had a chance to look at creating a PR for this?

@forsdahl
Copy link

@GuySartorelli have you had time to look at the PR for this? This is currently a blocker for us on some sites for upgrading to Silverstripe 5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants