2

On our office Mac, we have a local Apache server running through the software AMPPS. Prior to updating to Mojave, everything was working correctly. Now, after updating, there is an issue with using PHP include or require.

Our system uses an object for storing settings, and one of these is the document root path. This value is usually the same as $_SERVER['DOCUMENT_ROOT'], however using that is not an option for various reasons.

An example of the issue that is occurring:

include settings::$documentRoot . '/fileToInclude.php';

This will resolve to the path "/Applications/AMPPS/www/fileToInclude.php" and will fail with the standard 'not found' error:

Failed to open stream: No such file or directory

However, if I change the include line to the following:

include $_SERVER['DOCUMENT_ROOT'] . '/fileToInclude.php';

which resolves to the path "/Applications/AMPPS/www/fileToInclude.php" it will work without a problem.

As you can see, both include statements resolve to the exact same path, but only one works. I have done testing to confirm that both paths match exactly using a strict equality check (===).

Does anyone have any idea why this would happen in Mojave? As I mentioned, it was working perfectly fine in High Sierra, and it works fine on all our Windows machines.

EDIT: The server error logs output the following when trying to use the failing include.

PHP Warning: include(/Applications\xe2\x81\xa9/AMPPS\xe2\x81\xa9/www/fileToInclude.php): failed to open stream: No such file or directory in /Applications/AMPPS/www/index.php on line 14
Improve this question
8
  • Are you looking for an answer like upgrading that package to be compatible with Mojave or using a tool like homebrew to install a more traditional /usr/local place to host web includes instead of /Applications?
    – bmike ♦
    Jun 11, 2019 at 3:39
  • @bmike I'm looking to resolve the issue in our current setup. If that means code updates or config updates, that is fine. If there really is no solution, I can move out of AMPPS. That's more of a last resort thing. There's no guarantee it would change anything either as we may just run into the same issue.
    – Gherkin
    Jun 11, 2019 at 3:45
  • Sounds good. Any chance you could pastebin the 20 messages before and after in the server logs? Relative file names might be a decent workaround u less you’ve already implemented that.
    – bmike ♦
    Jun 11, 2019 at 3:52
  • @bmike I have had a look at the error logs and added the only noteworthy thing to the question body.
    – Gherkin
    Jun 11, 2019 at 5:17
  • @JacinTattersall It looks like there are some weird characters in that include, but since you did a strict equality check with what works, I wonder if they're actually significant?
    – Dev
    Jun 11, 2019 at 5:25

1 Answer 1

Reset to default
1

I would sanitize your input files for non printable Unicode characters. This appears to be something common when crossing platforms or using code editors that don’t show you this clearly.

What's happening looks to be different handling of text encoding - the log statement is hiding characters that the program is passing as a legitimate path in the filesystem.

It’s lucky this worked before on older OS, but the error is pointing out that you don't have /Applications\xe2\x81\xa9/AMPPS as a path and instead need your web code / framework to be looking at /Applications/AMPPS

It would be curious if all of these come from copying and pasting from the get info box and then the text editor where those values are pasting take the styled text and not the plain text version of the clipboard contents.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .