Lauren Wood

May 102016
 

If you read the documentation closely enough, of course all the information is there. Getting the order of operations right, however, can cause the odd issue.

Developing Django apps means applying migrations, and those don’t always do what’s expected. In that case, you can roll back to the n-1 migration by using ./manage.py migrate [app_label] {n-1_migration_label}, then delete the nth migration, then edit the models.py to try again.

To clean up the database from some third-party app you decide you don’t want after all, you use ./manage.py migrate [app_label] zero to get rid of the migrations from that app. You have to run this before deleting the app from your settings.py file.

Apr 242016
 

One of my client websites suddenly started giving an error: Error establishing a database connection. When I went to the /wp-admin URL, the error was still there.

This particular website is on shared hosting, so I logged into the CPanel and checked the database was still there. Then I checked the database 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!

Running those SQL queries on the appropriate database in phpMyAdmin fixed the problem. I don’t know whether the hosting company upgraded the database, or something happened with the automatic WordPress upgrade system, or if something else caused the problem.

[Update] There were a bunch of other errors that cropped up afterwards with the White Screen of Death; I had to call the hosting company to sort out the server-side errors causing those. It’s possible those errors were the original cause of the database problems, whatever they were.

Apr 222016
 

I discovered another issue while deploying to PythonAnywhere (maybe it’s applicable to other PAAS providers as well).

There was an odd ImportError when running manage.py. In the specific case I had, it showed up when running the tests with coverage: from Unipath import Path ImportError: No module named ‘Unipath’. It turned out I hadn’t installed coverage in the virtual environment, which meant the system was using the default one. Installing coverage in the virtual environment as well fixed the problem.

Apr 212016
 

A checklist for moving a Django-Wagtail project to PythonAnywhere. There is documentation on the PythonAnywhere site; mine includes things I forget.

Setup: development and testing on my laptop, staging and production on PythonAnywhere.

The help files are pretty good, but I need my own checklist. Right now I’m in the staging mode, but at some stage I’ll be moving to production. No point figuring out the same things twice!

  1. Develop on laptop in a virtualenv. Push commits regularly to bitbucket account. At some stage squash the migrations and clean those up. Four sets of settings: dev, testing, staging, production.
  2. Set up account on PythonAnywhere that allows the use of Postgres (it’s an add-on to a custom plan).
  3. Create virtualenv and set up staging web app. Delete virtualenv when you realise you didn’t use the right version of Python and the default is 2.7, not 3.5. Recreate the virtualenv with python 3.5.
  4. Clone the repository (using the ssh-keygen instructions). Redirect the public key to a file so you can copy it without line-breaks getting in the way.
  5. pip install -r requirements/production.txt (including psycopg2, which I didn’t need for development).
  6. Create the Postgres server, user, and database Don’t forget a strong password for the user (owner of the project database).
  7. Update the settings file with the database settings.
  8. Set the environment variables for the settings and the secret key (generator).
  9. Attempt to apply the migrations. This will show where you made mistakes on all the preceding steps.
  10. Fix the mistakes. Reload the web app to see if anything shows up.
  11. Set up the static file server. Check the static files are being served correctly.
  12. Create the Django superuser and log in.

The next step is data, of course.

Jan 022016
 

Over the Christmas break I made a couple of dips, one of which got better reviews than the others. This is not a recipe for purists, since a real tapenade should have anchovies in it, but I didn’t have any and my family doesn’t like them anyway.

None of the quantities are exact. The sun-dried tomatoes were loosely packed in the measuring cup and I didn’t measure the olives, just drained the can and tossed them in the food processor. I didn’t chop anything before putting it in the food processor.

  • Approx 2 cups black olives (contents of one can, 398ml size). I used Californian black olives since those were in the cupboard, next time I’ll probably use Kalamata olives.
  • Approx 3/4 cup oil-packed sun-dried tomatoes; let most of the oil drip off but not all of it.
  • 5 cloves of garlic.
  • 2 tbsp capers

Process in a food processor until finely chopped. If it’s too dry, add a few drops of olive oil (or oil from the sun-dried tomatoes).

Nov 172014
 

WordPress was designed for public websites, not private ones, so password protection can be a little clunky. Fortunately there are plugins to help, but (as always) there are trade-offs to be made.

When all you want to do is add a password to stop search engines indexing and outsiders reading the content, but you also want make it as easy as possible for people to use, there’s the Password Protected plugin. As it says, it doesn’t protect the images or other uploaded content.

If you also want to protect the media, you will need to give people an account on the WordPress site (with username and password). Then you can use the htaccess edits detailed at http://www.idowebdesign.ca/wordpress/password-protect-wordpress-attachments/. This works, but in many cases you just don’t want to give lots of people accounts on the system, or make groups of people share an account. So it’s a trade-off – how important is password-protecting the images versus the administration overhead of user accounts with the associated username/password ease of use issues? If you do want to use usernames and passwords, perhaps giving a group of people a shared account, I’d recommend also using one of the plugins that helps with finer-grained access control, such as Members, to stop people being able to change things you don’t want them changing (such as passwords for the shared account).

/* ]]> */