Is there a running list anywhere of WordPress plugins that are “unfriendly” to Bedrock because they don’t follow WordPress coding standards? Would love to know anyones experiences with plugins that caused frustration so I can avoid them, or if plugins are mostly unfriendly but have workarounds for getting them up and running (I’ve come across times where an htaccess entry would fix plugins using direct paths instead of wordpress methods for getting plugin directory, etc.)
Would love to know if anyone has sort of a running tally to save me from future headaches on my next project.
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 /wp/ (e.g. 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
# Flags:
# -E = extended regex
# -n = show line numbers
# Pattern:
# \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-cron.php, or /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 /wp-admin to /wp/wp-admin).
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.
Thanks for the useful command, @knowler. I ran this through my small list of plugins and apparently only Jetpack contains a bunch of site_url() references… mostly in the CLI-related class, but also in a handful of other files, including the main plugin class. It’s surprising, given that I have recently updated Jetpack to the latest version.
Like I said, there are legitimate uses and advantages of site_url() over home_url(), so each usage needs to be taken in context. Jetpack powers WordPress.com, so they are probably using it in a way that works when it runs in their own closed system. Since Jetpack isn’t designed for just running in that closed system, it likely has the proper fallbacks in place for non-WordPress.com sites. So, there’s no need to be too concerned.
That command is less so a “litmus test” as I previously described it, since it doesn’t provide decisive conclusions on its own, but more like one tool to help you find potential problems. I’ll update my previous comment to be more clear on this point.
Sure thing, I haven’t investigated Jetpack files in detail, nor studied the difference between both methods… just pointed out the fact, perhaps shouldve omitted the surprise part
