Next deployment (after 2023-06-28) to openflights.org

[reedy]

Relevant tasks/PR's that may require action for the next deployment to openflights.org.

I believe on 2023-06-28 it was updated to ecf635a.

Changes: ecf635a...master

After #1216 / a70afa1 this will be easier to check in future from the live site.

• Locale setup improvements #1388 - php7.4-intl needs installing (and then nginx/fpm restarts as appropriate)
• Make user ID for "demo mode" configurable #1232 / 9108498 - Update config.php to replace $OF_ADMIN_UID = 3; with $OF_ADMIN_UID = [ 3 ];
• Config setting for enabling/disabling signups #1360 / 7a6ca62 - Update config.php to add $OF_ENABLE_SIGNUP = true;
• Make user ID for "demo mode" configurable #1232 / 968137c - Update config.php to add $OF_DEMO_UID = 1;
• Remove vbulletin "integration"? #1355 / 071cd3e - Remove $OF_VBULLETIN_LOGIN from config.php
• attempting to edit an airport yields an internal server error #1314 / 5e0fae7 - Check and update $GITHUB_ACCESS_TOKEN if it's expired (it might not be, just the previous code update was rubbish in c03f720).
  • May want to check the submission works afterwards too.
  • It might be necessary/useful to do Submit airport edit suggestions under a different account #1171 too; add/create an openflights-bot user (or similar), and create a token on that account.
  • Maybe leave a comment in the config.php when the token is due to expire; as the newer token style only last a year.

TODOs:

• Add to/update news banner to reflect ongoing development #1266
• Add en_GB locale to locale table
  • Write script/sql file to update locale table #1404 - Make updating locale table easier; don't just want to run sql/load-data.sql. Split locale stuff into a new/separate/extra file so it can be run separately?
• Do we need to do any locale related regeneration server side? (Need more documentation here...)
• Update some of the data files in repo from openflights.org #1414
  • Update route table. Data updated 2023-03-22.
    • Add schedule table schema to import-vrs.py refers to schedules table which isn't in create.sql #1408
    • Run tools/update-arm.sh
    • Run sql/import-arm.sql
    • Export updates routes to data/routes.dat
• HSTS headers #1435

---

Other fixes (missing files/crons):

• Site statistics is giving a 404 (top10.dat) #1136 - Run sql/top10.sql and add/fix cron job
• "Recently added flights" aren't recent #1225 - Run sql/update-demo.sql and add/fix cron job

---

Errors from logs that could do with investigating (or at least, logs posting on tasks):

• attempting to edit an airport yields an internal server error #1314 - Possibly fixed with 5e0fae7 and necessary token updates mentioned above
• TripIt import blank page/fatal #1178

[jpatokal]

@reedy Are you OK with me doing a deploy from head to prod?

[reedy]

@reedy Are you OK with me doing a deploy from head to prod?

I believe so, yeah.

I'm not going to say 100% everything is going to work right, but...

I think the big things that need doing before upgrading, are as listed in the task description. Just to prevent things failing spectacularly.

Install php7.4-intl and restart service (fpm/nginx) as appropriate.

As long as you update config.php as appropriate (ideally adding $OF_ENABLE_SIGNUP and $OF_DEMO_UID; though the former doesn't have to be added, due to checks in the code, but it'd be nice to remove the isset() checks. Also updating $OF_ADMIN_UID after too).

Happy to try and be around when you do it, if you want. I keep a weird local TZ.

[jpatokal]

OK, thanks. This sounds involved enough that I'm not going to risk it without access to a proper computer if things go pear-shaped, so I'll put this on hold for two weeks or so.

[jpatokal]

Apologies for the massive delay. I have updated the configs, pulled from head, rebooted nginx and done a quick sanity check, and the site seems to work. Only bump in the road: I had to explicitly install php7.4-mbstring as well, not just php7.4-intl. I've followed up on #1314 re: the Github token, AFAICT it has no expiration date.

[reedy]

Bleugh, that's my fault - 39226ef for #1412

Will put it in composer.json.

I honestly can't remember if I already had it installed in my dev vm for one reason ro another...

[reedy]

Hmm, it was already listed in composer.json since before a728c1d (which suggests there was a mb_ call somewhere..).

No big deal at least, easily enough resolved :)

[reedy]

Hmm. First load of the site (existing browser or incognito) I see

Click OK a couple of times, change the locale and we're ok...

Some something to follow up on there

[jpatokal]

Works for me(tm) in incognito. Might be a locale issue, which one are you using? en_GB?

[reedy]

It will be trying to use en_GB yeah, but I notice it's not in the drop down (because it won't be in the locales table, which is another issue, and mentioned in the task :))...

Browser console tells all:

Looks like a fallback isn't quite working; and/or the check for null needs to be checking for '' too.

[reedy]

5e3957f and b9b58a7 should take care of this!

[jpatokal]

I've done another pull from head to fix the locale issues, which were causing significant pain (#1448).

[jpatokal]

@reedy I suggest we close this out and open a new issue for the next bigger release.