I’m not sure of a running list of plugins, but since I use Bedrock for development and work on plugins for my day job, I’ve definitely run into issues where I find code that doesn’t support Bedrock and fixing it usually isn’t too difficult.
I think the biggest issue in plugins could be using
site_url() instead of
home_url(). In Bedrock, the former will include
/wp/ in the URL (e.g.
https://example.com/wp/) since that’s “where the WordPress application files…are accessible,” while the latter won’t include
https://example.com). For plugins that are using
site_url() as a convention for URLs, supporting Bedrock might be as easy as simply using
home_url() instead. I’ve been able to ensure stuff I’ve worked on supports Bedrock this way. There are appropriate use cases for
site_url(), so one can’t just blindly find and replace every reference. Still, it doesn’t take long for a plugin developer to fix this mistake.
So, if you want one tool to check if a plugin might have issues with Bedrock, run the following in the directory for the plugin’s source code:
# This will find uses of site_url() and the related get_site_url()
grep -En '\b(get_)?site_url\(' **/*.php
# -E = extended regex
# -n = show line numbers
# \b = word boundary
# (get_)? optional capture for get_site_url()
# \( = escape opening round bracket
If you see these functions in use for what looks like public facing URLs, then that’s problematic. If you see it in use for stuff like
/wp-admin/admin-ajax.php, then it’s fine since those are WordPress application files (in fact, it is almost more compatible with Bedrock since it doesn’t rely on rewrites for
If the plugin’s source is accessible for issues, you can make an issue with the list of what needs to be fixed. You can even go ahead and make a pull request, fixing the ones you can yourself.