Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fatal function declaration errors in a WordPress environment caused by dual usage of Safe by both third party plugins and first party theme #660

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

Open
SebastianAwatramani opened this issue May 6, 2025 · 1 comment

Comments

@SebastianAwatramani
Copy link

SebastianAwatramani commented May 6, 2025

This is similar to #422 but I want to raise the issue because it seems to be an inherent issue with the architecture of the package that potentially prohibits its use in platforms that use third party plugins.

The basic issue is caused by the fact that this package's internal composer's files autoloads a series of files any time that a function from the package is used. In my case, our theme use's Safe's json_encode, and a third party plugin uses Safe's hex2bin, mb_str_split, openssl_decrypt, and openssl_encrypt (see EDIT2 below).

The fatal error, however, is triggered by attempting to redeclare Safe's mysqli_get_client_stats. But as neither the plugin nor the theme use this function, I surmised that it was the simple inclusion of those files from files that actually triggers the error.

That said, strictly speaking, even if Safe was re-architected such that it didn't include all those files automatically, it would not solve the issue in toto. I.e. while it would allow two independent usages of the package, I believe it would still trigger errors if the same function was used by (in my case) the theme and a plugin.

While on the one hand, the solution in my case might be to simply not use the package in my theme, on the other hand this has the potential to lead to a much bigger issue within certain platforms. Namely, Safe is becoming popular (which it should because it's an awesome package), which means it might become common for multiple third party plugins to utilize it, which would then lead to a situation in which various plugins become incompatible simply because they use this package, which after a lot of annoyance for a lot of developers, would turn them off from using it, which would be a shame because, I reiterate, this package is awesome.

My first thought was that perhaps the easiest fix would be to wrap your function definitions in if(!function_exists('Safe\function_name)) {...} but I'm not sure if there are things about that solution that I'm not considering?

At any rate, thanks for you work so far. I think my current problem will probably have to be solved by removing Safe from my base project and hoping that another plugin does not include it.

EDIT: originally linked to wrong similar issue, changed #253 -> #422

EDIT2: reading through some older issues, I see why files is necessary, so really the only potentially actionable solution in my post regards checking if the function_exists (if that's feasible).

EDIT3: verbiage

@shish
Copy link
Collaborator

shish commented May 6, 2025

Do you have a minimal example of failing code so we can see what you're trying to do?

As far as I understand composer's autoload mechanism, files listed in files should be loaded once at startup, and not a second time after that (no matter how many different packages or plugins reference Safe, it should only ever be loaded once). If you're seeing errors about functions being redeclared, that means that something somewhere is bypassing the autoloader and attempting to manually include Safe's files multiple times, which is something one shouldn't do (and if I'm understanding the problem, any library would fail in this manner if it were loaded in this manner, nothing Safe-specific about it).

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

No branches or pull requests

2 participants