Your data. Anywhere you go.

New Relic for iOS or Android


Download on the App Store    Android App on Google play


New Relic Insights App for iOS


Download on the App Store


Learn more

Close icon

Php agent breaks Laravel 5.2

laravel

#7

I wanted to let everyone experiencing this know that we are gathering information on this while we investigate possible fixes. We really appreciate everyone’s reports as well as the extra information. We have made sure to get eyes from the engineering team about this.

Thank you for being heroes and bringing this up right away.


#8

Hi, i made monkey patch for this problem.

newrelic patch for laravel5.2

It works fine in my environment.


#9

Thanks for posting that, @migrs! We’re looking into an official solution but if this is able to help out the community in the interim then you’re a real hero


#10

Great, that patch seems to work in the meantime while we wait for an official update


#11

This patch appears to help me, but does not fully solve the problem. Artisan CLI commands are still failing (trying to run config:cache).

It’s worth noting that I’m running php 7 with the New Relic beta agent. I hope that when this gets fixed that the beta agent will receive this update as well.

I have unfortunately had to disable New Relic for the time being.


#12

Hi @danwall

Each new beta release is rebased against the existing PHP Agent release, so if a new version of PHP Agent comes out fixing this issue and another version of our PHP 7 Agent beta comes out after, it will likely be merged with that fresh beta run.

It looks like this issue is a case of moved cheese, 5.2 is a brand new release, they have removed some functions our agent uses for framework detection and transaction naming, as such our developers will be investigating optimal replacement functions to tie to going forward. It’s hard to know if a CMS update will break our integrations so while we understand the need and want to upgrade to new versions of software, it’s always a good idea to test nothing breaks before pushing out a major CMS change.

Hopefully we’ll have 5.2 supported soon and you guys can plough ahead with both NR and Laravel as desired.


#13

Just keep us posted as SOON as it happens!

Cheers


#14

@mr.not4sale

Will do my best of course :slightly_smiling:

I’d suggest bookmarking https://docs.newrelic.com/docs/release-notes/agent-release-notes/php-release-notes

You can’t miss it if you check it periodically to see what changes came as part of new releases.


#15

Any updates, by chance?


#16

Hi @vpcheney not yet. Our developers are aware and looking to get a solution out soon. I don’t have a timeline on this at the moment.

@migrs put together a small patch that seems to work to help work around the problem for the moment.

Migrs Laravel 5.2 Patch

Have you tried this patch to get you working until we get a release out that adds support for Laravel 5.2?


#17

Hi

Unfortunately it seems that the provided patch doesn’t work anymore… We noticed that last Friday. Any updates when this is going to be resolved?


#18

Hi again

The patch is working but not with routes caching (php artisan route:cache). So try to put “Route::macro…” part somewhere else (not in routes.php) if you are using route caching.


#19

Hi @skera

I don’t have any update yet. Our developers are working on trying to get something out for this in an upcoming release.

If the patch stops being a functional solution, instrumentation can be done manually using the newrelic_name_transaction(), the most convenience place to do such if the patch isn’t an option is in the Controller/Route section to name transactions based on its routing.

To disable automatic instrumentation (the reason you’re seeing an error with Laravel 5.2 is because this new version moves the location of files we use to instrument transactions and entry points to requests, so if you set in your newrelic.ini

newrelic.framework = "none"

This will stop our agent from detecting Laravel 5.2 temporarily, the error thrown for not found file will go away, but so will automatic naming. The above API function used in the right place passing the right values could solve the problem too.

Best place to keep an eye for a new agent release and if it contains a fix for the 5.2 issue is to keep an eye on our PHP Agent Release Notes.


#20

I am having the same issue running:
Disabling the php extension while updating did work.


#21

Thanks! I’m not sure to understand: what will I loose if I disable the framework?
In the ini file, there is no documentation about “none” value for framework (only “no_framework”), should I use “none” anyway?

PS: I’m using the last beta for PHP 7 and Laravel 5.2


#22

@raphael1 none or no_framework will have the same effect, neither are a real framework so the agent doesn’t try instrument.

What you lose is the automatic naming of transactions. When our agent detects Laravel it uses known framework internals to help name transactions as you would normally expect.

If it can’t detect the framework, it will likely fallback to naming the transaction based on the requesting URI, so if all transactions start at index.php before being routed to the right code, it will likely leave all transactions reporting in as index.php unless you use the newrelic_name_transaction function to tell us to name them differently.


#23

Did yesterday’s release fix this issue?


#24

Unfortunately not :unamused:


#25

Actually with newrelic.framework = “none” it still auto detects my app as using laravel. I have to use newrelic.framework = “no_framework” to make sure it doesn’t.

newrelic-php5 5.5.0.154


#26

@buildingbridges actually apologies, it looks like that value changed and I hadn’t brought myself up to speed and I can actually see on environments where I was testing and using it, none isn’t achieving the goal anymore and no_framework is the correct value.

newrelic.framework = "no_framework"

Is the correct value to use here. Apologies if anyone was using none based on my suggestion and not achieving success.