Jump to content

simpilot

Administrators
  • Posts

    2773
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by simpilot

  1. Your site will not even come up for me and I think you are probably fighting a losing battle but try this if you are using a version other than mine;

    In file /core/lib/recaptcha/recpathalib.php find line 40, it should be;

    define("RECAPTCHA_VERIFY_SERVER", "api-verify.recaptcha.net");
    

    and change it to;

    define("RECAPTCHA_VERIFY_SERVER", gethostbyname('api-verify.recaptcha.net'));
    

  2. I think I figured it out, there are no other airlines with this issue so I started looking at your data and the newest PIREP right now has a unique_id of 9042 yet there are PIREPS from your airline with a unique ID as high as 10874. This is the id that is assigned to it in your database of PIREPS. When the vacentral system sees a PIREP come in that has the same airline id and the same unique id as a PIREP already in the system it assumes it is an update and updates the old pirep, and also bypasses the activity feed.

    My guess is that on the 24th you guys reset your PIREPs database, or at least cleaned some out or something and reset the id column back to somewhere in the 9000's.

    Two solutions;

    1 - I can delete all the PIREPS from the vaCentral database and you can resubmit them and it should correct the id issue or;

    2 - Set your id column of your PIREPs table to something above 10874

  3. Just noticed that the last update time has changed on VAcentral but the Airline larest events has not changed.

    Is there supposed to be a VAcentral table in the database ?

    The vastats update that you are seeing is separate from PIREP and ACARS data and only updates once every 24 hours. The events are driven by PIREP submissions which should be happening as soon as it is filed unless you have made changes to your system.

    I am not aware of any database table in phpVMS that would be for vaCentral specifically.

  4. You will just need to remove any reference to it in the registration controller and registration template, although you are probably going to get flooded with spam registrations. I don't know what version you are using but the newer versions use noCaptha that just requires a check in most cases.

  5. I did not understand what you were referring to, I was thinking the site news feed. I looked and it is actually right, the last true PIREP was put in the system on the 24th, the vasats have been updating. I am am guessing that your site is set to use json data which for some reason has all of a sudden given many sites an issue. When you go to your admin panel does it show flight waiting to be exported and when you try you get a message the there is no response from the API server? If so, try changing it to xml and let me know.

    http://forum.phpvms.net/topic/23275-exporting-pirep/#entry122813

  6. @flyalaska is probably on point. The older version of the screenshot center did not utilize the table prefix capability of phpVMS and the later versions do, so if you have updated most likely you will have to add your database prefix to your screenshots tables in your database.

  7. I have looked at your pages on your site and they seem to be working ok for tour details. My guess is that a person/site/crawler/forum is hitting a tour that is not visible to the public or doesn't exist, that is why I was wondering if it showed the url that was causing it. You may find that information in your apache logs.

    If you take a look at this page -> flyaka.com/index.php/tour/details/9999 <- you will see that the errors are there as the tour doesn't exist.

    If you go to a tour that exists and is properly setup -> flyaka.com/index.php/tour/details/115 <- everything seems to function properly.

    I can in the future try to put something in the code to catch this scenario.

  8. It is updated. It was because your flights are marked mostly without a flight type when you submit a PIREP, The system did not what to do with the calculation when it hit one like that, so I have changed the code to ignore this situation and continue.

×
×
  • Create New...