ProAvia

I still don't know where that field (status) came from.... but I did find this updated module.... LOA v 1.0 https://github.com/Cloudxtreme/phpvms_loa

In looking at my original module files and what is on my site, I have no idea where the status column came from or what it actually does. It may have something to do with my pilot manager module, which hasa column to mark pilots on leave. If I find out I will post back here.

The "You already have an LoA on file...." works on mine. I don't know anything about the loa table having a hub entry. Mine doesn't have hub - but does have status after reason. What PHP version are you using? What MySQL/MariaDB version?

Just ignore it. If it really bothers you, you can edit the module files to remove the check for updates. Of course, back up the originals before messing around with it.

What version of phpVMS? What PHP version? What MySQL/MariaDB version? Does the site load correctly with the default crystal skin?

What version of phpVMS are you using? Did you run the SQL file to add to the database? This adds a new table for the LOA module.

Read thru the docs again https://docs.phpvms.net/ Double check you have the hosting set up correctly.

What was the issue?

phpVMS version? PHP version? MySQL or Maria DB version? Using the ela skin shouldn't be the issue, but try again while using the default crystal skin.

@Redbeard- May help others if you post exactly what you did to fix the errors.

phpVMS 5.5.2.72 and phpVMS 5.5.2 have been reported as having issues with MariaDB 10.2 and higher. Check with the host to verify that Strict Mode is OFF. That may help fix the issue. Your pic shows PHP 7.3.6 . phpVMS 5.5.2.72 has issues with PHP 7.3 and higher. Verify which version of PHP the phpvms is set to run on. You may need to set up a subdomain to set it to PHP 7.2 (if the host has 7.2 available). The URL needs to point to the phpVMS root folder... in your case - https://usvaf.ml/phpvms Try with https and http - also with and without the trailing slash ( / ). I see you notrd you already tried that. Maybe try just usvaf.ml/phpvms or usvaf.ml/phpvms/ -- as your screenshot shows "inclusive http://", so may not need the http part in the URL box. Other than that, I'm out of ideas. Maybe another member who actually uses cacars will chime in.

Is your host doing awaywith PHP 5.6? If not, no reason to use phpVMS 5.5.2.72 As you can see on your hosting, only PHP 5.6 and PHP 7.0 are available. Both versions are deprecated and no longer receiving updates. Are you having any issues with your present install? I see your host is on MariaDB 10.3 - phpVMS 5.5.2.72 and 5.5.2 presently have some issues with MariaDB 10.2 and higher. In any case, there is no direct upgrading of phpVMS 5.5.2 to phpVMS 5.5.2.72. You have to start with a fresh install of phpVMS 5.5.2.72, get all your modules and skin working error free and then move you data (only) from your 5.5.2 install over to 5.5.2.72. Do NOT just use your 5.5.2 database as is - there are database changes in 5.5.2.72 that are not in 5.5.2. As for your present skin - it is not compatible with phpVMS 7 ... which has nothing to do with using PHP 7.0. It only has to do with what version of phpVMS you are using.

Hmm.... cacars should work with https - as long as local.config has https as the site url. Having phpVMS in root/phpvms shouldn't be an issue either. ERROR_LEVEL as listed will show all but Notices. That should also be okay. What version of MySQL or MariaDB are you using? Post the exact error you are seeing in cacars.

Have you checked the error logs? Did you modify the cacars files in any way? Make sure error reporting is on. Make sure there is an error_log file in thephpvms and phpvms/admin folders What is ERROR_LEVEL set to in local.config? Change back to the default crystal skin and try it again.

Nice find G!

OP hasn't visited the forums since 2016. Chances are their skins are no longer available.

Through the coding, those variables pull the pilots ID, first name and last name to be placed into the email.

@Heritage1- are you meaning this? - If so, maybe something there will help you out - or post to that thread? I assume your simBrief API is for your primary domain.

According to the github link you posted (https://github.com/shinoyasan/Airway-Route-Finder), it does pull from the web - routefinder to be exact. The phpVMS database (default) doesn't include date to make actual flight planning possible. If you modded it to only pull from the DB, can you share the changes you made? And maybe have all the language in English as not many here know Chinese (at least Google thinks it's Chinese). The module that @gio1961 linked to uses routefinder as well. There is also a module available that uses simBrief and it can be easily integrated into most phpVMS websites.

All the airports? Are you actually going to use all of them? It takes a while to load that may airports. Suggest you trim your airports table to only those that you will use.

If you stay with your host, nothing you can do. Or find a host that uses the specific versions of PHP and either MySQL or MariaDB needed to run phpVMS correctly.

Search the forums for - non-static method. That's been covered here many times. Also, Google is your friend... search there for - Deprecated: Non-static method

Miguel Your issues come down to your install. Most probably your MySQL/MariaDB version and Strict Mode settings. Talk with your host and ask them to turn Strict Mode off, then test again. You statedin one of your other threads that youare using MariaDB 10.4 - that is probably the issue. Keep all your issues in one thread - as they are all caused by the same thing. It's either the MariaDB version or Strict Mode.

I think FSAcars may have some issues with new versions of PHP that would need to be fixed. What version of PHP are you using with phpVMS 2.x?

The real issue is probably MariaDB 10.4 and Strict Mode. We know that phpVMS 5.5.2 will work under MariaDB 10.1 . Some users have reported issues with MariaDB 10.2 and above. Some of these issues were related to Strict Mode. Search here for "strict mode". Your work-around may work. There may be other DB tables that may need the same adjustments. Only time will tell. Keep us advised in this thread if you notice other similar issues.