Bad file mapping to URL causes open_basedir error

Could you clarify, what the issue do you have? How some Query Monitor message breaks your site? The file is accessible from frontend (see https://terageek.org/wp-content/plugins/hcaptcha-for-forms-and-more/assets/images/hcaptcha-div-logo.svg), and it is needed on frontend only.

The code you provided is not relevant and does not belong to our plugin.

If you want to fix open_basedir message (but why?), you should reach your hosting provider and show them this.

I will be happy to help with any real problem on your site. Please show me the form where hCaptcha does not work.

Thank you.

Hi,

Thank you for your response. I appreciate the quick reply, but I believe there may be some misunderstanding here. I’d like to clarify that the issue isn’t related to an open_basedir configuration but rather an inconsistency in the plugin code itself.

Query Monitor, which I’m using, is a debugging and optimization tool for WordPress. It’s not causing the issue; it’s simply revealing it. If you try it yourself, you’ll see it can be an invaluable resource for identifying hidden issues.

I manually re-downloaded the plugin to verify, and I can confirm it contains this file path:

hcaptcha-for-forms-and-more/vendors/matthiasmullie/minify/src/Minify.php

So, the code snippet I shared – particularly line 439 – is indeed relevant here. While this code may be from a third-party library, it’s embedded within your plugin, which makes it part of the plugin’s functionality and potential issues.

From what I can see, it appears that the plugin may be incorrectly interpreting URLs as file paths. The incorrect path format (/https://...) doesn’t exist and will never resolve, causing the open_basedir error. This isn’t an issue with the server configuration but with the plugin attempting to access a non-existent path, which inherently triggers the open_basedir restriction.

I hope this clarifies the matter and assists in refining the plugin for future versions.

Best regards

Thank you for clarifications.

Of course, I know what is Query Monitor (QM) and use it from time to time for more that 10 years already.

I have reproduced the messages in the Query Monitor by setting open_basedir="some root for sites" in the php.ini file on my local machine. Here is the screenshot.

The image in question is this shown below, appearing for a very short time during page loading as a placeholder.

To make this screenshot, I have activated EventListener breakpoint on DOMContentLoaded in browser. As you can see, despite the warning reported by the QM, the image is still in place – things work well.

To reproduce this problem, it is needed to set open_basedir to something in the php.ini. This cannot be fixed anyhow on the PHP code side. This setting can be edited by hosting provider only.

What happens here? The matthiasmullie library used in the plugin to minify CSS code, has minor issues. The code you mentioned above is in its Minify.php file. It tries to interpret absolutely valid CSS code as having internal file hcaptcha-div-logo.svg inside.

.h-captcha::before {
		content: '';
		display: block;
		position: absolute;
		top: 0;
		left: 0;
		background: url( https://test.test/wp-content/plugins/hcaptcha-wordpress-plugin/assets/images/hcaptcha-div-logo.svg ) no-repeat;
		border: 1px solid transparent;
		border-radius: 4px;
	}

Here, cannot be an internal file, otherwise CSS won’t work. Nevertheless, the matthiasmullie library does its work as requested – CSS is properly minified.

So, we have the “issue” which does not affect plugin functionality anyhow.

If you can fix it anyway, you may open issue in the library repository on GitHub. I hope the library author can help.

Thank you.

Thank you for the detailed explanation and for confirming that the issue stems from the minification library within the plugin.

I understand that this may not directly impact functionality for all users, but for those of us using servers with open_basedir restrictions enabled, these errors can clutter our logs and error notifications and lead to potential issues with site maintenance. Properly configured servers with open_basedir are increasingly common, and error-free operation is essential for ensuring compatibility and minimizing disruptions.

As an end-user, I’m reporting this because it affects my site setup and may affect others in a similar configuration. While I could open an issue with the minification library, I’m not a PHP developer myself and could not properly explain the cause and solution to the issue. It seems like something the plugin team that used this library should track to improve the plugin and prevent errors.

If this isn’t feasible, I understand, and I’ll explore alternative solutions. Thanks again for your time and support with this.

This warning does not appear in the debug.log file, as is_file warnings are suppressed by the error control sign @. To reveal this error, a special error handler must be set, and this is what Query Monitor does.

In other words, you can see this warning in the Query Monitor log window only and nowhere else.

The minification works as expected with or without Query Monitor.

Log files are clean on the production (and even development) sites.

Query Monitor does its job: it reveals underlying issues that might otherwise go unnoticed.

We both know this doesn’t break functionality. But just because these warnings are suppressed doesn’t mean they should be ignored; hiding them is like sweeping dust under the carpet, which can only cause harm in the long run.

Anyone using hCaptcha for WP and checking their setup with Query Monitor will see this big red error constantly. For those of us monitoring our sites closely, this constant background noise makes it harder to spot and report genuine issues. When you see the same red error on every page, either you disable Query Monitor and stop checking altogether, or you become desensitized to actual problems because it’s all buried under this one persistent error.

In the bigger picture, ignoring errors because “it still works” sets a bad precedent. If this becomes common practice, WordPress could become so cluttered with errors that no one takes them seriously anymore. This reasoning is, ultimately, harmful.

Beyond that, I don’t want my server trying to access nonexistent files on every single page load, and I think anyone who cares about performance or just loves attention to detail would feel the same.

I hope this clarifies why this issue should be addressed. This is my last attempt at reasoning with you; if nothing changes, I’ll simply look for another plugin.

Good luck

As you may guess, I have no capacity to fork and maintain a third-party minification library, and it looked impossible to fix the issue in our plugin.

I spent half a day trying to find a trick for fixing a library issue without touching the library code. Finally, I did it. The fix is included in v4.7.0, which will be released next week.

So far, on your development site, you can use define('SCRIPT_DEBUG', true); in the wp-config.php to turn off minification and avoid getting warnings in the Query Monitor console.

• This reply was modified 2 weeks, 5 days ago by kaggdesign.

Thank you for your time and effort, and congratulations for finding a fix! I’m sorry to learn this was so tough to find. But relived that this can be fixed!

If this third party library is not properly maintained (eg. doesn’t accept PRs or doesn’t handle reported issues), you may want to use another one in the long run.

Otherwise, since many people rely on cache plugins for minification anyway, having the plugin managing minification is maybe not essential. You may also:

• Add a checkbox to enable/disable minification at plugin level, so people disturbed by it or already using another minification tool can disable the plugin’s one
• Remove embedded minification altogether

In my case the error occurs on prod websites, so I can’t really enable debug. But that is no issue at all, I can wait a week for the next release. The most important is that the error doesn’t stay there for too long (eg. months), preventing noticing newer ones in the meantime. And a release next week is perfect!

I’ll try to feedback after the release to confirm this works as expected in my environment too.

Many thanks!