I have a project with a fairly standard Dev-on-Homestead to Staging to Production workflow. All are using Laravel 7.2.2/Ubuntu 18.04/PHP 7.4.3
This cropped up today with some form requests.
Symfony\Component\ErrorHandler\Error\FatalError
Type of App\Http\Requests\CreateHighlight::$errorBag must be string (as in class Illuminate\Foundation\Http\FormRequest)
This is a named $errorBag that we've been using since 5.4 or so?
I changed the $errorBag to protected string $errorBag='highlightCreate'; and proceeded to test and deploy.
That same code kicked this back from the staging error logs:
staging.ERROR: Type of App\Http\Requests\CreateHighlight::$errorBag must not be defined (as in class Illuminate\Foundation\Http\FormRequest)
I have checked and rechecked and checked a fourth, fifth, sixth time. Everything appears to be identical between the two environments, yet I cannot for the life of me understand why this is happening. They're the same error except they're contradicting each other.
Based on FormRequest it clearly seems like errorBag is not defined as a string. This clearly seems like it is something with your local file there is wrong. Never the less the errorBag should not be defined as a string.
Related
I have a console task ran through:
$schedule->command('process:job')
->cron('* * * * *')
->withoutOverlapping();
The task is run, it can invoke different services, everything is fine in the world. However I have one specific tasks invoking a different class where the configuration is not loaded.
For specific reasons I wish to read my configuration in $_ENV (it allows me to do some key value iteration and process some keys specifically based on a pattern). But here $_ENV remains empty, I can read configuration through config() or env().
This never happens through HTTP calls nor through some command lines call (I haven't been able to understand the difference in the scheduler call and command line invocation).
Laravel 5.6
EDIT: this question is kept here because I didn't manage to find the existing relevant one Why is my $_ENV empty?
Found my solution here: Why is my $_ENV empty?
Basically $_ENV is not populated on a systematic basis but only if the flag E is in your variables_order ini variable. So if you stumble one the same problem, I suggest a quick check.
var_dump(ini_get('variables_order'));
The fix is obviously to fix your ini file.
The update to Laravel 5.5 seems to be creating a few oddities for me. Probably something I've screwed up, but these issues only broke with the new version - this same code has not failed in 5.4, 5.3, etc. The bigger problem is that the error is not consistent on the same model - it fails on update, but works on store.
I have a date field called 'decom_date' on a 'prog' model with the $dates field on the model overridden to include 'decom_date'. A user can fill out a form for a new 'prog', and skip the 'decom_date' field. The model saves with no error. If the user edits the same prog model with the exact same form, and leaves the 'decom_date' field blank, the following error occurs in Laravel 5.5 only:
message "Data missing"
exception "InvalidArgumentException"
file "/var/www/ipfast/vendor/nesbot/carbon/src/Carbon/Carbon.php"
line 582
IE Carbon is now expecting a format instead of an empty string upon updates only. I can work around this with a mutator on the model like so:
public function setDecomDateAttribute($value)
{
$this->attributes['decom_date'] = $value ?: null;
}
No problem - this works, and I think will stop the new breaking 100%... but I worry when things suddenly break, especially as it doesn't seem consistent across the saves. This pattern fails consistently across every model I have with dates, and these were not broken before update.
Anyone able to shed some light on this - or maybe just something dumb I've done?
I can't confirm this behaviour. If your date is an empty string it always fails with your posted error, no matter if it is during update or create.
Normally in Laravel 5.4 and 5.5 the global middleware stack contains:
\Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
You can check this in app\Http\Kernel.php
With this middleware emptry strings shoul automatically be converted to a NULL value which Carbons handles properly.
What I can imagine is, that your decom_date field is not even present in the request data when you 'skip' this field during create ( Just check it with dd($request) all on top of your store method.
And if you leave the field 'blank' during your update method, the result is an empty string ( In case the middleware mentioned above is missing ... )
I beat myself up for two days as I built a Ruby on Rails application that manages users in LDAP. While fine-tuning the inclusion and formatting of various attributes, I would frequently have ldap.add() fail with little feedback other than possibly an exception raised. I usually knew it was a data validation error, such as a missing required attribute or poorly formatted attribute values -- but I could not find anything on the server (Apache DS) or client end that would indicate which field failed, or why it was failing.
So...how do you see the reason why an LDAP add (or replace, delete, open...) failed?
Then I stumbled across ldap.get_operation_result, I had a real facepalm moment. I've intentionally recreated several of the issues I painfully solved through careful inspection with get_operation_result in my arsenal, and each time it described exactly what the problem was.
This function is useful in the case of rescuing an exception, or if add(), modify(), delete(), etc. simply returns false.
ldap.add(dn: dn, attributes: attributes)
Rails.logger.info("ldap.add: #{ldap.get_operation_result}")
The snippet above saved my sanity, not to mention hours of tedious hunt-and-peck testing.
For example, here is just one part of an error message it revealed that I did not provide the required sn attribute:
ERR_279 Required attributes [sn(2.5.4.4)] not found within entry uid=david,o=users,dc=example,dc=com"
It will also show messages related to bad server connection credentials, etc.
HTH
Hello guys,
I'm making an API using Laravel. In one of my scripts, I make an update on a field, like this :
user::where('uuid', $uuid)->update(['date' => $date]);
I noticed that the primary key increments when doing this. My obvious conclusion is that Eloquent makes a delete - insert in place of a regular MySQL update.
And so the question is, why ?
Thanks ahead.
It's not possible that this line of code will update id your records. Whenever you thing something strange happens in your application (not only in Laravel), you should:
analyse what exactly code is running that causes this problem (for example you think the error is in this line but you execute also some other custom function where error might occur)
verify if there are no extra framework dependant code launched - in this case events for user model
verify if there are no triggers in Database (that will automatically update/insert/delete records)
I have an application which has been running successfully for over a year on both the production server and my development machine (both running IIS without any pretty URLs). Yesterday I moved the latest in a series of (until now successful) updates from development to production, and since then many of the routes have been failing on the production server, even though they work fine on dev. I've verified that the exact same application and route files are present on both machines, I've confirmed that php artisan routes produce the same output on both machines, I've confirmed that their autoload_classmap.php files are identical, and I've verified that both servers are running Laravel 4.1.23 .
After some testing it appears that, for example, the URL https://localhost/EPHY/index.php/child/3958/edit, which triggers the ChildController::edit() RESTful method on dev, triggers ChildController::create() on production, which then crashes because it can't find the familyId parameter it's expecting. Here's the applicable line in routes.php on both servers:
Route::resource( 'child', 'ChildController', array(
'create' => 'child.create',
'store' => 'child.store',
'show' => 'child.show',
'edit' => 'child.edit',
'update' => 'child.update',
'destroy' => 'child.destroy'
));
I should note that Family, another RESTful resource, works successfully on both servers, but others don't. After doing some more testing, it actually seems like any routes relating to models that have an Eloquent relationship with Family are failing, and all the others are working fine. That's just weird...
Can anybody suggest what may be causing this, or at least where I can look? I'm happy to post additional information.
UPDATE: I continue to poke at this problem, and it's becoming apparent that this is definitely only affecting routes related to models with an Eloquent relationship to the Family model; all other routes in the application appear to be working correctly.
Ok, I figured this out, and it's lame. As I noted above, this was only affecting models which had an Eloquent relationship with Family. What that means in practice is that all of the ::create() methods of the associated Controllers needed the Family::id value. So, here's the code I was checking the determine whether I needed that value from Input::get() or Input::old():
$familyId = ( empty( Input::old() ) )? Input::get('familyId') : Input::old('family_id');
Anybody see the problem? empty() can't take a function call as a parameter. Everything worked fine as soon as I changed the code to:
$familyId = ( Input::old() )? Input::old('family_id') : Input::get('familyId') ;
Now, how did I figure this out? Well, after spending a day and a half assuming I knew what "Can't use function return value in write context" meant, I FINALLY CHECKED THE DAMN ERROR MESSAGE ON GOOGLE! Let this be a lesson to the newbs and a reminder to the veterans, never assume you understand what an error means without double-checking with the groupmind...
I'm so ashamed...