web541

If you want to add a skin that you've already found, it should be as simple as downloading it and uploading it to a new folder in your lib/skins directory. After, just select this skin in the admin panel's settings. There may be some issues along the way (compatibility, modules, file extensions, etc.) but most are a simple fix if you search/post to this forum. If you want to create a new skin, there's an old thread here that will help (in simple terms): In terms of ACARS setup, the setup depends on which ACARS software you plan on using. Otherwise this post may serve better in the Paid Services forum if you are finding someone else to do it for you.

Nice job! I was going to suggest checking the $entry and $exit variables as they were the last things that could possibly be changed.

By this do you mean it's running but not going backwards, or not running at all?

Hmm, that could be a start. Is there a pattern to it or is it truely random? And does the order stay the same if you run the same function twice or do the waypoints keep jumbling up? Was the first dump taken before this line: $navpoint_list_details = self::getNavDetails($navpoint_list); or earlier in the function? If that's the case then it's probably an issue within the loops somewhere as anything further than this line is just pulling waypoint info from your DB and ordering it (which seems to be working from your dumps).

I would change this: <select id="depicao" name="depicao"> <option value="">Select All</option> <?php if(!$depairports) $depairports = array(); foreach($depairports as $airport) { echo '<option value="'.$airport->icao.'">'.$airport->icao .' ('.$airport->name.')</option>'; } ?> </select> to this: <input type="text" name="depicao" id="depicao" placeholder="Enter Departure ICAO..." /> and do the same for the arrival airport as well, just change all the depicao to arricao in the new input. Hope that helps.

This is fine for the location column, but the airline column should not be NULL at any point. If it is, then you need to re-install the module correctly as you may be missing some admin files otherwise it will not work as expected.

You can try using this code: Make sure that the 'core/codon.config.php' inside the require() is set to the relative path of your phpvms folder/core/codon.config.php file.

It depends what sort of hosting you go for (e.g. shared) but generally all you need to do is ensure the correct PHP and MySQL versions are supported by your host and you've selected them properly. Then I would upload a fresh download of phpVMS, go to the /install url and follow the prompts. When that's done, you'll have a fresh database, so depending on how much you have altered your localhost install, you could either upload your skin(s) and modules individually to the new install OR delete the new phpVMS installation, drag and drop your localhost installation into your hosting and change the details at the top of your core/local.config.php file. No guarantees there won't be issues though, so be prepared to fix a few if you come across them. In regards to the airport fetching, you can now check this post out and give it a try: Although since you are using phpVMS 2.x then the files may be slightly different so it's possible that you'll need to manually import the changes to your own install.

Is there a reason you are wanting to upgrade versions (e.g. host forces a higher PHP version?), because otherwise if you have a working install then I wouldn't touch it too much. With the actual upgrade, from phpVMS 2.x to phpVMS 5.5.x (or 5.5.2.72) it's pretty much just getting it to install with minimal errors and then changing your skin's template files from .tpl to .php. And inside any data classes in core/common (mostly any modules you have installed, the default files should already have this), making sure that the syntax is public static function instead of just public function. This is a known issue (and has been for years since VACentral got changed), there isn't a preferred way to fix it right now. I think most people are still finding them manually and importing them via .csv. There's a bunch of forum posts about this. What PHP version and MySQL/MariaDB version are you running? This sounds like a database issue. Yep that's another known issue (since Google changed their mapping API terms). The link to change to OSM maps on Nabeel's github is useful and people have had success with that method. The full discussion is here: Unfortunately not, you'd have to make the same changes to the map files in whichever phpVMS version you use. But the process is the same for all of them, just with slight changes to the files and file extension (.tpl vs .php). If you are planning on starting from scratch then ProAvia's repo is a good start especially if you are on a high php version. See here. I addressed this at the start, it's drag and drop but then you would have to change your file extension and watch out for any errors and fix them as they pop up.

Sounds like some sort of logic error to me. Here's a couple of guesses: if ($entry < $exit) { # Go forwards through the list adding each one for ($l = $entry; $l <= $exit; $l++) { $allpoints[$airways[$name][$l]->name] = $airways[$name][$l]; } } elseif ($entry > $exit) { # Go backwards through the list for ($l = $exit; $l >= $entry; $l--) { $point_name = self::cleanName($airways[$name][$l]->name); $allpoints[$point_name] = $airways[$name][$l]; } there could be something going on with the name here as going backwards, the point name isn't 'cleaned' (through the cleanName function), so I would try changing these lines: $point_name = self::cleanName($airways[$name][$l]->name); $allpoints[$point_name] = $airways[$name][$l]; // TO THIS: $allpoints[$airways[$name][$l]->name] = $airways[$name][$l]; and seeing if that does anything. For these lines here: if (isset($airways[$name])) { $entry_name = self::cleanName($navpoints[$i - 1]); $exit_name = self::cleanName($navpoints[$i + 1]); because there's a bunch of looping happening afterwards, this could be something, so I would temporarily change it to this: if (isset($airways[$name])) { $entry_name = self::cleanName($navpoints[$i + 1]); $exit_name = self::cleanName($navpoints[$i - 1]); and see if it does the reverse (so the route is parsed correctly backwards instead of forwards). Just a hunch so I could be totally wrong. Does this mean it's not in the output at all? $navpoint_list_details = self::getNavDetails($navpoint_list); I would want to know if the $allpoints variable contains the correct airways/points at this stage before any of the parsing occurs. So before this line, you might want to dump it and see if the results are the same: return $allpoints; but phpVMS might not like the format of that, so you might have to return json_encode($allpoints) if you're logging it in the console or print_r($allpoints) if you have a url.

You should be able to modify this function in PHP: https://github.com/DavidJClark/phpvms_5.5.x/blob/master/core/modules/ACARS/ACARS.php#L60 which is read here: https://github.com/DavidJClark/phpvms_5.5.x/blob/master/lib/js/acarsmap.js#L65 and it should allow you to use the templating tags.

1 - If you've got auto-retire set to true in your local.config.php then it routes (either from cron or every 24hours) to this function: https://github.com/DavidJClark/phpvms_5.5.x/blob/master/core/common/PilotData.class.php#L712 then ultimately to this function: https://github.com/DavidJClark/phpvms_5.5.x/blob/master/core/common/PilotData.class.php#L353 2 - Check your local.config.php file first for PILOT_STATUS_TYPES, otherwise they're defined here: https://github.com/DavidJClark/phpvms_5.5.x/blob/master/core/app.config.php#L466 Can you check your console and inspect the <select name="retired"> when you go to edit a pilot (the dropdown for their status) and check that the value of each <option> matches up with what it should be.

I don't think it has been implemented yet. There's an image uploading request on github but I'm not sure if it covers avatars or just normal site images/pages.

Have you tried optimizing your tables through the maintenance page? Not sure if it will help but it's worth a try. It's possible that the phpVMS foreign key constraints have been messed up due to the high IDs, if you are continuing to have issue then I would recommend setup a second site, have a fresh install/DB and migrate your data over. If importing it retains the high IDs then you may have to write a script that takes the old data dump and inserts them one at a time from the start. It's definitely weird that things are working but the data is ending up in some sort of 'pseudo table' and not showing in the DB.

No I don't think it's been put anywhere yet, but you can put that code anywhere you want (you could try /layouts/SKIN/profile/index.blade.php and search for "Rank" and put it nearby). <img src="{{ asset('/assets/img/ranks/rank1.png') }}" alt="Rank 1" /> or <img src="{{ public_asset('/assets/img/ranks/rank1.png') }}" alt="Rank 1" />