web541

Working on my end with the default template file. Pilots.php

Not sure which one he has used, but I have this one working on a 5.5.x version public function index() { $this->set('pilot_list', PilotData::getAllPilots()); $this->render('pilots_list.tpl'); } I believe the code is for the old .tpl version which still had the $allpilots variable whereas the 5.5.x version has the newer $pilot_list variable

<?php echo OperationsData::getAllAircraft('true'); ?> Specifying the 'true' inside the brackets will trigger the command to only allow $enabled aircraft to be returned in the query.

Try this foreach($rankai as $ran) { echo $ran->icao.','; }

Try this <td align="center"><a href="https://www.ivao.aero/Member.aspx?id=<?php echo PilotData::GetFieldValue($pilot->pilotid, 'value'); ?>" target="_blank"><?php echo PilotData::GetFieldValue($pilot->pilotid, 'value'); ?></a></td> Make sure to change 'value' to your field name for the IVAO ID in your database.

<?php if(SchedulesData::getBids(Auth::$userinfo->pilotid) > 0) { echo 'You have flights that need to be perfomed!'; } else { echo '<a href="'.SITE_URL.'/index.php/randomflights">Book Random Flights</a>'; } ?>

Yeah, but you still forgot the ?key= part, instead, you only specified the API Key itself What you've got <script async defer src="https://maps.googleapis.com/maps/api/js?YOUR_API_KEY&callback=initMap" type="text/javascript"></script> Try this <script async defer src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" type="text/javascript"></script> And replace YOUR_API_KEY with the API Key. Note the ?key=

Try changing your line to this <script async defer src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" type="text/javascript"></script> Looks like you forgot to add the "key" part which is probably what's driving that message

If that still doesn't show, try the fix here http://forum.phpvms.net/topic/22609-first-time-setup-of-phpvms-no-admin-settings-after-installation-solved/#entry120224

In your local.config.php, is your DB_NAME the correct one and have you imported the table from the old database now? Just need to clear some things up first.

Ok that's a start. Are the pilots showing in the admin center the correct pilots or the original? In regards to that code, If you have a skin on the newer version, place it in lib/skins/YOURSKINNAME/frontpage_main.php If you don't have a skin on the newer version, place it in core/templates/frontpage_main.php Please remove it after you see the results to make sure nothing weird happens in the future. At this point, also try clearing your cache.

Oh, I forgot to mention, go into core/logs/logs.txt and see if anything has been recorded. Are the pilots showing up in the admin center? Were they before you imported? If you open up the front page of you skin and for a test put this on it (you can remove it after) <?php $allpilots = PilotData::getAllPilots(); foreach($allpilots as $pilot) { echo $pilot->firstname.''.$pilot->lastname; } echo '<br />'; echo '<pre>'; print_r($allpilots); echo '</pre>'; ?>

Hmmm, can you check in your local.config.php that your database has been set right. While you're there, can you also check this: Find these Config::Set('DEBUG_MODE', false); Config::Set('DEBUG_LEVEL', 1); // 1 logs query errors, 2 logs all queries And change them to this Config::Set('DEBUG_MODE', true); Config::Set('DEBUG_LEVEL', 2); // 1 logs query errors, 2 logs all queries Once done, go to your pilots page and refresh the page to see if it's picking up any queries. Once that's done, you can go into your core/local.config.php file and change these back to the original Config::Set('DEBUG_MODE', false); Config::Set('DEBUG_LEVEL', 1); // 1 logs query errors, 2 logs all queries That should allow you to see if it is a query issue or not. I assume you just followed the procedure above, but just making sure, have you changed any tables or columns/fields?

hmmm, Using the new database (not the original) For the following, use phpMyAdmin 1. Export the pilots table 2. Go to the new database 3. Run this query in the SQL tab (near Import or Export, etc.) SET FOREIGN_KEY_CHECKS=0; TRUNCATE phpvms_pilots; This will effectively empty the new pilots table and reset the auto-increment 4. Import the data as usual See if that works, if it doesn't, post your errors again and see if in the .sql file contains the following -- -- Indexes for table `phpvms_pilots` -- ALTER TABLE `phpvms_pilots` ADD PRIMARY KEY (`pilotid`), ADD KEY `code` (`code`), ADD KEY `rank` (`rank`); If it does, this may be conflicting with the import, so remove it and anything below it and then try the steps again.

ah ok, it's a foreign key constraint failure, try opening the SQL file and place this before the CREATE_TABLE... or even running this before you import SET FOREIGN_KEY_CHECKS=0;

try exporting the pilots table out of the original database and importing it into the new one and then if it gives you errors, post them here so we can take a look.

Yeah, the links you provided have been tested with php 5.5, however I've installed it on php 5.4 in the past with no real problems. In case you're wondering, phpvms 5.5.x has also been tested with php 7.0 in a development environment (here) Are you installing a fresh version or wanting to port your current (.tpl) version over? I say this because, there is no real "easy" way to port it all over as many (many) things have changed from the .tpl version to the .php version including what you've stated, the table structure. As far as I know, this was the current up-to-date phpvms version as of a while ago until it got removed from github. What you could do is export lets say the aircraft, airlines, airports, hubs, pilots, pireps, ranks and schedules table (as they have had minor changes) and then install the newer phpvms version into a different folder in your public_html, connect it to a different database (so technically you'd have two version running simultaneously with no conflict) and then import the tables above. No guarantees it will work, but theoretically it should import the data into the columns specified and I believe none have been removed, only added during the upgrade. Remember to BACKUP first if you try this though.

Go into core/common/TimetableData.class.php And replace the first function with this one public function get_schedules($offset) { $query = "SELECT * FROM ".TABLE_PREFIX."schedules WHERE code <> 'CH' ORDER BY depicao ASC LIMIT 30 OFFSET $offset"; return DB::get_results($query); }

http://forum.phpvms....ir/#entry105255 and this one http://forum.phpvms....ir/#entry105334 EDIT: Just realised you wanted aircraft not airline

Try and change these <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script> <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.0/jquery-ui.min.js"></script> <script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=true"></script> To this <?php echo $page_htmlhead; ?> If that doesn't work, check your browser console.

From the documentation... http://forum.phpvms.net/page/index.html/_/developers-guides/vacentral-documentation-r29 * flightime - the flight time (HH.MM format)

No worries, feel free to use my code on your side, I purely gave it to you as an example As per your issue above, this should solve the error <?php $pirep = PIREPData::getRecentReportsByCount(1); if(!$pirep) { echo 'THERE IS NO FLIGHTS'; } else { foreach($pirep as $p) { echo ' '.$p->depicao.' <img src="/lib/skins/vdelta3/img/airplaneicon.png" alt=""> '.$p->arricao.' FLIGHT: '.$p->code . $p->flightnum.' AIRCRAFT: '.$p->aircraft.' SUBMITTED: '.date(DATE_FORMAT, $p->submitdate).' '; } } ?>

can't remember what type of field the "submitdate" is, but you could try <?php echo $report->depicao; ?> <img src="/airplaneicon.png" alt=""> <?php echo $report->arricao; ?> FLIGHT: <?php echo $report->code . $report->flightnum; ?> AIRCRAFT: <?php echo $report->aircraft; ?> DATE SUBMITTED: <?php echo date(DATE_FORMAT, strtotime($report->submitdate)); ?> or if that doesn't work, do a <?php echo print_r($report); ?> And post what you have for the field [submitdate] => What I use

Yeah, it's phpvms 5.5.x by Simpilot found here but that shouldn't be an issue (thought I do recommend upgrading for the future as most people have ported over) Can you go into your core/local.config.php file and find these Config::Set('DEBUG_MODE', false); Config::Set('DEBUG_LEVEL', 1); // 1 logs query errors, 2 logs all queries And change them to this Config::Set('DEBUG_MODE', true); Config::Set('DEBUG_LEVEL', 2); // 1 logs query errors, 2 logs all queries Once done, go to your admin panel, add a new hub as normal and then open up core/logs/log.txt and post what you have in there. (NOTE: it may take a few goes to get it to log) Once that's done, you can go into your core/local.config.php file and change these back to the original Config::Set('DEBUG_MODE', false); Config::Set('DEBUG_LEVEL', 1); // 1 logs query errors, 2 logs all queries That should allow you to see if it is a query issue or not. Also (I know it's already been suggested) but do check to see if you have the correct files in the correct places.

He's stated here that he's using .tpl files and not all of your code has the ".TABLE_PREFIX." code in it.