Skip to content

Conversation

@sveneld
Copy link

@sveneld sveneld commented Nov 14, 2025

Rename filename from config.php to Config.php and add new line between namespace and use

@LanaJ11
Copy link

LanaJ11 commented Dec 3, 2025

@sveneld
Hi! Thanks so much for taking the time to look into this and submit the PR!

We’ve just released an updated SDK version that includes a fix for the issue. Instead of renaming the file directly (which could impact existing integrations), we applied a fix that avoids breaking changes for current users. After upgrading to the latest release, the “Class telesign\sdk\Config not found” error should no longer occur.

If anything else comes up, we’re always happy to help, thanks again for raising this!

@sveneld
Copy link
Author

sveneld commented Dec 3, 2025

@LanaJ11 can you explain how existing integration can work before your fix?

@LanaJ11
Copy link

LanaJ11 commented Dec 8, 2025

@sveneld If I understood your question correctly, you’re asking how some integrations were working before the fix.

The issue only affected Linux environments, because Linux is case-sensitive when resolving file names. On macOS and Windows, file systems are case-insensitive, so config.php and Config.php were treated as the same file, which is why integrations on those systems worked without errors. On Linux, the mismatch caused the “Class not found” error you ran into.

Our fix ensures that the SDK now works consistently across all operating systems, without requiring users to rename files manually or introduce breaking changes.

If you have any other questions, or if I didn’t fully answer what you meant, just let me know!

@sveneld
Copy link
Author

sveneld commented Dec 8, 2025

@LanaJ11 From a cross-platform perspective, the most reliable fix would actually be to rename the file to use an uppercase first letter.

On Windows the code worked only because the filesystem is case-insensitive, so the autoloader resolved the file regardless of the case mismatch. By bringing the filename to uppercase, Windows would continue to behave exactly as before, while on Linux this would properly align with PSR-4 requirements and avoid autoloading errors.

This approach keeps the behaviour consistent across both environments and follows the standard.

@LanaJ11
Copy link

LanaJ11 commented Dec 8, 2025

@sveneld We totally agree that renaming the file to match PSR-4 is the best long-term solution, and it’s something we absolutely plan to do.

The reason we didn’t release it right away is that changing the filename could potentially break some existing integrations in a few cases. For example, if someone is referencing config.php manually, relying on the exact lowercase name, or using custom autoloading setups, a sudden rename could introduce unexpected issues. Because of that, we need to follow our internal process for any changes that might introduce breaking behavior.

For now, the goal was to unblock Linux users as quickly as possible, so we applied the safest short-term fix. But we’re fully aligned on the long-term approach, and renaming the file properly is definitely planned.

Thanks again for your input and for helping us improve the SDK!

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants