Apr 242016
 

One of my cli­ent web­sites sud­denly star­ted giv­ing an error: Error estab­lish­ing a data­base con­nec­tion. When I went to the /wp-admin URL, the error was still there.

This par­tic­u­lar web­site is on shared host­ing, so I logged into the CPan­el and checked the data­base was still there. Then I checked the data­base and found some issues with some of the tables.

[site.wp_links] error: Table upgrade required. Please do "REPAIR TABLE `wp_links`" or dump/reload to fix it!
[site.wp_options] error: Table upgrade required. Please do "REPAIR TABLE `wp_options`" or dump/reload to fix it!
[site.wp_postmeta] status: OK
[site.wp_posts] status: OK
[site.wp_term_relationships] status: OK
[site.wp_term_taxonomy] error: Table upgrade required. Please do "REPAIR TABLE `wp_term_taxonomy`" or dump/reload to fix it!
[site.wp_terms] status: OK
[site.wp_usermeta] error: Table upgrade required. Please do "REPAIR TABLE `wp_usermeta`" or dump/reload to fix it!
[site.wp_users] error: Table upgrade required. Please do "REPAIR TABLE `wp_users`" or dump/reload to fix it!

Run­ning those SQL quer­ies on the appro­pri­ate data­base in phpMy­Ad­min fixed the prob­lem. I don’t know wheth­er the host­ing com­pany upgraded the data­base, or some­thing happened with the auto­mat­ic Word­Press upgrade sys­tem, or if some­thing else caused the problem.

[Update] There were a bunch of oth­er errors that cropped up after­wards with the White Screen of Death; I had to call the host­ing com­pany to sort out the serv­er-side errors caus­ing those. It’s pos­sible those errors were the ori­gin­al cause of the data­base prob­lems, whatever they were.

Apr 222016
 

I dis­covered anoth­er issue while deploy­ing to Python­Any­where (maybe it’s applic­able to oth­er PAAS pro­viders as well).

There was an odd Impor­t­Er­ror when run­ning manage.py. In the spe­cif­ic case I had, it showed up when run­ning the tests with coverage: from Uni­path import Path Impor­t­Er­ror: No mod­ule named ‘Uni­path’. It turned out I had­n’t installed cov­er­age in the vir­tu­al envir­on­ment, which meant the sys­tem was using the default one. Installing cov­er­age in the vir­tu­al envir­on­ment as well fixed the problem.

Apr 212016
 

A check­list for mov­ing a Django-Wag­tail pro­ject to Python­Any­where. There is doc­u­ment­a­tion on the Python­Any­where site; mine includes things I forget.

Setup: devel­op­ment and test­ing on my laptop, sta­ging and pro­duc­tion on PythonAnywhere.

The help files are pretty good, but I need my own check­list. Right now I’m in the sta­ging mode, but at some stage I’ll be mov­ing to pro­duc­tion. No point fig­ur­ing out the same things twice!

  1. Devel­op on laptop in a vir­tualenv. Push com­mits reg­u­larly to bit­buck­et account. At some stage squash the migra­tions and clean those up. Four sets of set­tings: dev, test­ing, sta­ging, production.
  2. Set up account on Python­Any­where that allows the use of Post­gres (it’s an add-on to a cus­tom plan).
  3. Cre­ate vir­tualenv and set up sta­ging web app. Delete vir­tualenv when you real­ise you did­n’t use the right ver­sion of Python and the default is 2.7, not 3.5. Recre­ate the vir­tualenv with python 3.5.
  4. Clone the repos­it­ory (using the ssh-key­gen instruc­tions). Redir­ect the pub­lic key to a file so you can copy it without line-breaks get­ting in the way.
  5. pip install -r requirements/production.txt (includ­ing psycopg2, which I did­n’t need for development). 
  6. Cre­ate the Post­gres serv­er, user, and data­base Don’t for­get a strong pass­word for the user (own­er of the pro­ject database).
  7. Update the set­tings file with the data­base settings.
  8. Set the envir­on­ment vari­ables for the set­tings and the secret key (gen­er­at­or).
  9. Attempt to apply the migra­tions. This will show where you made mis­takes on all the pre­ced­ing steps.
  10. Fix the mis­takes. Reload the web app to see if any­thing shows up. 
  11. Set up the stat­ic file serv­er. Check the stat­ic files are being served correctly.
  12. Cre­ate the Django super­user and log in.

The next step is data, of course.

/* ]]> */