2

This is a bit of a weird one, so please bear with me.

I'm trying to get Bugsnag up and running on our custom platform.

The boilerplate code looks like:

if ( !include_once($NP->settings->paths->external .'/Bugsnag/guzzle.phar') ) 
  exit('Failed to load ERROR: guzzle');
if ( !include_once($NP->settings->paths->external .'/Bugsnag/bugsnag.phar') ) 
  exit('Failed to load ERROR SYSTEM: bugsnag');

This unfortunately throws an exception:

Fatal error: require(): Failed opening required 'phar://guzzle.phar/autoloader.php'

However, if I attempt to load this outside of our platform, it seems to spin up just fine.

As I am not thoroughly familiar with the ins and outs of working with phar's, what could we be setting which would interfere with a phar's ability to reference inside it's own container?

Information:

Ubuntu 16.04.2 LTS
PHP 7.0.18-0ubuntu0.16.04.1 (Phar is native)

Phar EXT version: 2.0.2
Phar API version: 1.1.1
Phar-based phar archives: enabled
Tar-based phar archives: enabled
ZIP-based phar archives: enabled
gzip compression: enabled
bzip2 compression: disabled
Native OpenSSL support: enabled

phar.readonly: On
phar.require_hash: Off

Any assistance will be appreciated.

Thanks!

UPDATE: After doing some testing with a colleague, I noticed that even putting the boilerplate code at the very top of our primary platform boot script, still threw the error. The only thing we could think of which changes in that case is a directory change (as the boot script is in the include_path). After adding the external directory to php's include_path, it seemed to work. I am confused by this however, because it is my understanding that Phar files are self-contained to specifically not have issues like this. Why would a Phar file suddenly be unable to reference itself, after it has already be successfully included?

UPDATE: So, the above update is not an actual fix. The results are very strange. It will spin up fine one time, then fail the next few times. Again, this is when there is no other code loading before it. Something interesting: If we restart Apache, it loads on the first page load. Everything after that it fails.

Spot
  • 7,962
  • 9
  • 46
  • 55
  • if you restart Apache it works. Sounds familiar; do you by any chance have some kind of PHP op-cache installed? – LSerni Jun 21 '17 at 16:36

2 Answers2

0

Is guzzle.phar a symlink to a file with a different name?

Otherwise you can break internal linking in .phar files by setting a different alias when loading them through the Phar class:

new Phar('guzzle.phar, 0, 'differentalias.phar');
cweiske
  • 30,033
  • 14
  • 133
  • 194
  • No, this is not a symlink. Also, the updated solution in the OP is actually not working always. It's very weird. We are doing a direct include to the file, and then it just refuses to load correctly, throwing that error. If it's at the top of the _first_ script which apache is pulling it's fine, but the moment we put it in another script which is included (even if it is the first thing in the included script) it throws the error. – Spot Jun 21 '17 at 13:39
0

Not sure, but I think you cannot reference a PHAR from inside another PHAR.

Why not use a usual setup with Composer (to install all the deps) and then create a PHAR using Box project?

Alexey Shokov
  • 4,775
  • 1
  • 21
  • 22
  • We're not referencing from within a phar. It's general code trying to load a phar. :( – Spot Jun 21 '17 at 16:25
  • 1
    But you are using you deps as PHARs and you are trying to pack them in another PHAR. Or am I wrong? – Alexey Shokov Jun 21 '17 at 20:34
  • No, we're not packing them in another PHAR. It's just normal site code (no PHAR), and trying to get Bugsnag working which requires we load those two PHARs. We're not using Composer at the moment because the system is not setup for it, and this is a client, so I don't have full control over everything. ;) For reference, this is what we're doing: https://docs.bugsnag.com/platforms/php/other/#using-a-phar-package – Spot Jun 21 '17 at 22:16