web541

Oops I must have skimmed over that, I just took it from the lines that the error was occurring and just assumed. Ahh yeah that's definitely a phpVMS error and not a PHP one (even though there were PHP ones that you stated) which could indicate a problem with your database. Are you sure? Line 153 here https://github.com/DavidJClark/phpvms_5.5.x/blob/master/core/common/StatsData.class.php#L153 looks like this: $year = date('Y', $start); # Get the months which is very similar. I think it is probably an issue with your database or at least one of the tables, have you installed recently or have you been running it for a while? That line and the non-numeric error is saying that it cannot find the date your VA started (or it cannot interpret it), and when it can't do that it will try and get the date of the first PIREP submitted. Have you had access to the admin panel before this or did it just pop up? And just to check, the timezone issue is now gone?

What version of phpVMS are you using? I think you are using v2 so go to this line: https://github.com/phpvms/phpvms_v2/blob/master/core/common/StatsData.class.php#L137 and before it, put this: date_default_timezone_set("Europe/Paris"); and see if that makes any difference. Was this writing red by and chance? I think it may be referring to the admin panel's permissions if it's thrown an exception. You could setting 777 to the cache folder only but I don't think it's related.

Definitely a possibility but in this case I've taken code from Jeffery's original module and changed the template rendering in the module, so the module logic itself remains untouched. I haven't heard anyone else having issues with it so far so I can only assume it could be a schedules issue or a conflict with the schedules module being used.

As long as you pass in a pilot id as the first parameter of PilotData::GetFieldValue() it shouldn't matter where you put it or if you use it in a loop. I have checked your code, you have provided this: <!-- Here i would like to show VATSIM or IVAO ID using the following code --> l <?php echo PilotData::GetFieldValue($pilot->pilotid, 'VATSIM CID or IVAO VID'); ?> As I stated above, if you want it to work inside of your pireps page ($pireps loop as you provided) then you will need to swap that line for this one (as I already provided above): <?php echo PilotData::GetFieldValue($pirep->pilotid, 'VATSIM CID'); ?> where VATSIM CID is the name of your custom field. Note the change from $pilot to $pirep. If this isn't what you are after then please give further explanation/code so we can help you out.

Nope no idea. Are you using the default schedules module? The only other things are making sure that the airline is enabled and that the pilot's rank is less than the rank set on the schedule.

Are you sure you tried that exact line? Note the difference between $pilot and $pirep.

Have you tried this? <?php echo PilotData::GetFieldValue($pirep->pilotid, 'VATSIM CID'); ?>

How are you handling the form data in your create() method? Are you using $request->all() by any chance? If you are then that would be why the _token is showing as it's part of the request (as you already know). From my understanding, if you are going to use $request->all() you should specify your fields/column names that you will be using as part of your $fillable property on your model. Like this https://github.com/nabeelio/phpvms/blob/dev/app/Models/Airline.php#L34 That way (at least from my understanding), by using $request->all() you are only allowing the fields you have specified in $fillable to be modified in your database, so you are protected from anyone adding a hidden input field into your form for example. This will also allow you to use it without getting that '_token column not found' error as it's not specified in your $fillable property. But @Nabeel can confirm this.

No, the _token is the CSRF token so that's not stored in the database at all. Just realised that the CSRF token has been disabled (not sure why), so if you have anything to do with @csrf or _token in your form just remove it for now.

Are you using a separate booking/schedules module by any chance? I thought that the default one within phpVMS should do this by default.

Hmm yeah it could be related. Although what you have there looks right to me.

The 'method' => 'patch', part of the Form::model(...) means you would have to declare it as a PATCH instead of a POST. So does something like this work (obviously change airport to whatever you are using)? Route::patch('staff/update/{id}', 'AdminController@update')->name('update'); {{ Form::model($airport, [ 'route' => ['YOURMODULEPREFIX.update', $airport->id], 'method' => 'patch', 'id' => 'airportForm']) }} The name('update') bit is what the route() uses to get the name, so by default it should be MODULENAME.update or (::) but it might not be working right now because of the issue.

What's your routes that you have put in Routes/web.php (or AppServiceProvider)? Edit: Just saw you posted at the same time haha. It could be related to the module issue on github, but what routes have you defined? Also, did it throw any errors or just a "Page Not Found"?

Really? I thought he was using the LaravelCollective HTML linked above? Here's his airports example. 1. https://github.com/nabeelio/phpvms/blob/dev/app/Http/Controllers/Admin/AirportController.php#L125 << Fetches the airport, sets the variable for use in the view and shows the view. 2. https://github.com/nabeelio/phpvms/blob/dev/resources/views/admin/airports/edit.blade.php#L6 << In the view, he defines the model binding (note the $airport) which should fill in the fields and match up the fieldname with the column name in the database. 3. https://github.com/nabeelio/phpvms/blob/dev/resources/views/admin/airports/fields.blade.php << His fields are defined here. Does that help a bit more?

As in filling the inputs in your form at URL.com/.../edit? You should be able to do something like this: <div class="form-group"> {{ Form::label('FIELDNAME', 'FIELDNAME TEXT TO DISPLAY:') }} <span class="required">*</span> {{ Form::text('FIELDNAME', null, ['class' => 'form-control']) }} <p class="text-danger">{{ $errors->first('FIELDNAME') }}</p> </div> and it should auto-fill the values based on the model data (e.g. $users) you have, provided you have setup the Form::model().. binding before this. For more info, checkout how Nabeel does it in the admin area (airports for example), or view the Collective HTML docs here. If you wanted to make it more traditional, you could also do something like this: <form action="{{ route('/users', $user->id) }}" method="post"> @csrf @method('PUT') OR PATCH <div class="form-group"> <label for="...">FIELDNAME TO DISPLAY</label> <input type="text" name="FIELDNAME" id="..." class="form-control" value="{{ old('FIELDNAME', DEFAULT VALUE) }}" /> OLD will display the last data the user has entered if it fails validation. @errors fields... </div> </form>

I would get the form values from the submission using a Request (or App\Requests\Request...) $request, then I would validate it using $request->validate([...]) (although it might be done automatically), then call $this->REPO->create([..]) to insert it. Not sure what you mean here, if it's where the code actually is, it should be here https://github.com/nabeelio/phpvms/blob/dev/app/Contracts/Repository.php#L19

You mean when you go to install, you click "Importing from a legacy install"? I thought that was fixed now (or at least in its prelim stages). Which part of it didn't work and were there any errors? Yeah you could do it the way @LeonardIGO4036 suggested, but the installer should be the easiest way of doing it.

Not sure if it's the right way of doing it, but I've had success doing it like this: private $userRepo; /** * @param UserRepository $userRepo */ public function __construct(UserRepository $userRepo) { $this->userRepo = $userRepo; } /** * Display a listing of the resource. */ public function index() { $where = []; if (setting('pilots.hide_inactive')) { $where['state'] = UserState::ACTIVE; } try { $users = $this->userRepo ->with(['airline', 'current_airport']) ->orderBy('pilot_id', 'desc') ->findWhere($where); } catch (RepositoryException $e) { Log::emergency($e); } return view('staff::admin.index', [ 'users' => $users, ]); } Also, not sure what you plan on doing but I would usually keep any $request for its own method other than index unless there's a reason to keep it in.

I think he was referring to the /update route on his site. I've posted an issue on Github and the updater is getting some updates (ironic haha) so it's likely you will have to wait until a beta 5 and manually install it before the auto updates will work again. Still being tested.

What is line 125 of the lib/skins/blueIce/frontpage_main.php for you? Is this BlueIce v2 or v1? If it's v2, then you might change to the phpVMS 5.5.2.72 version here Or otherwise @flyalaska might be able to assist.

See this thread, it should help you out

If the live data isn't being shown when you converted to Leaflet/OSM and you do have active flights (pilots using ACARS) then there's something wrong. When they are connected through ACARS, do you see any data in your phpvms_acars table in your database? Also, check your browser console for any errors as it may show something if it's Leaflet related.

It's in the Import module on the admin side: https://github.com/DavidJClark/phpvms_5.5.x/blob/master/admin/modules/Import/Import.php#L287 You could do the same and clean it up a little and probably get away with using PilotData::getAllPilots() and looping that through, or querying PilotData::findPilots() with your params/columns.

That's weird, are you using the latest beta release? It seems to be failing as it can't correctly pick up/store the latest version number. It could be a permissions issue on the storage folder, if you refresh the admin do you have a kvp.json file in the Storage\app directory?

What phpVMS, PHP & MySQL versions are you running? I remember having the same issue a while back when I was testing, but I never got around to finding the issue. Potentially check that the versions are exactly the same in your new host to your old host as even a slight change could cause something like this to happen. Also, check your DB details are correct in your local.config.php file, but I suspect you already have as the Tour bids are going through and the site isn't blowing up with errors. And check your browser console for any JS errors, as some of the bidding logic (buttons) is done via JS.