PHP namespacing issue (again)

  • Resolved Timo

    (@worschtebrot)


    2 months, 3 weeks ago

    Hi,

    I reported a similar case a long time ago. After nothing had changed for months, I no longer use BackWPup for my projects.

    Now a user of one of my plugins reports the following error when loading an admin page of my plugin:

    Cannot redeclare GuzzleHttp\Psr7\str() (previously declared in …/wp-content/plugins/backwpup/vendor/guzzlehttp/psr7/src/functions.php:19)

    It’s not against the law to use PHP composer packages in plugins, but it has always been and continues to be a problem in the WordPress plugin cosmos when several plugins use the same sources. This almost always leads to conflicts.

    Solutions are:

    • Wrap the Composer packages used in their own namespace (I have good experiences with https://php-prefixer.com/)
    • Or – and this would already help in my case – you only load the Composer packages when your own plugin really needs them, i.e. when it is currently executing an action.

    Because when the admin pages of my plugin are loading, in the best case your GuzzleHttp\Psr7 should not be loaded at all, unless it is because of some WP Cron action or similar, but that is not the case. I haven’t even set up a backup job yet, I’ve just activated BackWpUp. This is a question of code design. Sources should only be loaded when they are needed.

    I’m writing this in such detail because it annoys me a little that after a few years I keep coming across these cases with your plugin and I now have to come up with a short-term solution for my code, which has to be much more extensive than the suggested adjustments in your plugin would be.

    There is some other GuzzleHttp and PHP namespacing feedback here in the forum and I hope that you will give the issue appropriate attention.

Viewing 1 replies (of 1 total)
  • Plugin Support BWU Support

    (@saranshwpm)

    Hi,

    Thank you for your detailed feedback. We understand the concerns you’ve raised about the GuzzleHttp\Psr7 conflict and the broader issue of Composer package collisions. These conflicts can indeed disrupt plugin functionality, and we are committed to addressing them.

    Please be assured that we are aware of the GuzzleHttp-related issue, and it has been internally reported. We have started initial testing, but fixing these dependencies is complex and will take some time. We are exploring solutions such as using unique namespaces or loading packages only when needed to minimize conflicts.

    We appreciate your patience as we work on this. Your feedback is invaluable, and we are taking it seriously to improve the experience for all users and developers. If you have more suggestions or questions, please let us know.

    Best regards,

Viewing 1 replies (of 1 total)
  • You must be logged in to reply to this topic.