Spencer Critchley

The Web

Let’s watch Erato’s “Call Your Girlfriend” go viral, in real time

by

On Facebook today I came across a video shared by a friend whose musical taste I respect, so I gave it a click, and had that wonderful experience of discovering something great and unexpected. It’s three members of a female Swedish choral group named Erato singing – beautifully – a cover of “Call Your Girlfriend”, by Robyn. The young women are sitting in underlit gloom around a kitchen table, accompanying themselves by using cottage cheese tubs as percussion instruments, with amazing, deadpan skill.

[Read more…] about Let’s watch Erato’s “Call Your Girlfriend” go viral, in real time

Literacy now includes not just language, not just media, but code, too.

by

…as we’re reminded by CodeNow, featured at WhiteHouse.gov today:

CodeNow focuses on developing the next pioneers in technology by teaching underserved youth foundational skills in computer science and programming with the objective of narrowing the current digital divide. The organization teaches high school students the basics of computer programming and computer science in free, extra-curricular, off-campus trainings and boot camps. Each student who completes their program receives a netbook, mentoring and assistance finding internships.

…and by CodeAcademy.org, offering free programming lessons on the web:

Coding is not just for the chosen few. Anyone can learn with the right environment, resources and dedication.

Top Drupal Gotchas, #2: White Screen / Not Enough PHP Memory

by

Cross-posted at O’Reilly Broadcast.

Continuing my effort to spare newcomers to Drupal from falling into this powerful content management system’s most common traps, this time I look at a frequent cause of white screens – the sudden and scary devolution of a previously healthy Drupal site into a blank browser window.

This can be caused by coding mistakes, such as neglecting to conclude a line of custom PHP with a semicolon.

But white screens often happen to new Drupal admins who haven’t yet come near any custom PHP. The typical story is that you install a new module and suddenly – poof, there goes the site. You might assume that the new module is buggy or incompatible with your site.

But the cause is often simply that your web server has run out of memory for executing PHP. Since at heart Drupal runs on PHP interacting with an SQL database, your site can’t bootstrap to begin writing any html pages.

Under many web hosting accounts, the default setting for memory allocated to PHP is quite low – on mine, it’s 8 MegaBytes. But it’s not uncommon for a Drupal site with extra modules installed to require 96 MB or more.

In order to increase PHP’s memory allocation, you need access to your web server’s PHP initialization file, which is called php.ini. (You won’t have this access with web hosting plans that restrict you to the site’s home directory, since php.ini is typically found higher up the directory tree, such as in the /etc folder if you’re using Apache.)

When setting up a new Drupal site to which you plan to add extra modules, find your server’s php.ini file, open it and search for this line:

memory_limit = xM

…where “x” is some integer, such as 8. If it’s a small number like that, replace it with something more appropriate. Some Drupal modules will give you guidance on this in their documentation. I’ve found that 96 MB is a good starting point.

Save the newly edited php.ini file, and you should now be safe from memory-related white screens.

But whatever the cause of a particular problem, all of them are arguments for routinely backing up a Drupal site and its database, and/or for trying out significant changes on a test site before deploying them to the public site.

Top Drupal Gotchas: “Access Denied” and Permissions Problems

by

Cross-posted at O’Reilly Broadcast.

The Drupal Content Management System keeps getting better and better. But the learning curve is still steep and the interface is still tricky – even after working with it for several years, some gotchas keep tripping me up. That tells me it’s worth jotting them down, hopefully to spare a few other Drupallers falling into the traps I’ve fallen into enough times for all of us.

This time: Mysterious problems logging in or accessing content.

These are fairly common and can have a variety of causes. The ones I’ve found most often:

1. You just need to clear your browser’s cache (I believe Drupal’s cache management has improved, so that this is less common in recent versions).

2. You haven’t given a particular user role permission to access a particular content type. Go to [yoursiteurl]/admin/user/permissions and make sure the appropriate boxes are checked (replace [yoursiteurl] with your actual site url, of course). Note that you need to do this every time you create a new content type (as when using CCK, the Content Construction Kit), or even when you are only adding a new field to a content type. Also note that giving a permission to Anonymous users does not mean that Authorized users inherit that permission. You have to check the box for each.

3. The SQL database has a problem. This can cause access or login problems even for the super admin user (user 1). Bearing in mind that you should back up your database before doing anything to it, you can try these fixes:

  • Rebuild permissions: Go to /admin/content/node-settings/rebuild.
  • Repair the Sessions table: You can use the appropriate SQL query for your DB, or an easy way is to use PHPMyAdmin. In PHPMyAdmin, choose your Drupal database, check the box next to the Sessions table, and find the “With selected” drop-down near the bottom of the page. Choose “Repair table”.

The Sessions table seems to be prone to problems. I recently came across this idea at Stanford Tech Commons for keeping it healthier. It sounds useful, but I don’t know enough about database innards to judge its reliability. Comments?