Because sharing is good for everyone.

Welcome to Open Source Catholic. We want to help Catholic techies, web developers, organizations, dioceses and all other Catholics involved in software and web development to find effective solutions for spreading the Gospel of Jesus Christ. Read more »

Create an account or login with your OpenID to join the conversation.

Don't Neglect Your print.css file!

I just spent a few hours working on making a better print.css file for the Archdiocese of St. Louis' website, and, imho, it was time very well spent.

In a meeting just last week with the St. Louis Review staff, I noticed that three different people on staff had printed out pages from archstl.org, and those printed pages looked like junk. I had neglected spending much time with the Archdiocese's print styling (in a print.css file) when I originally designed the site, and I decided it was time to work on it a bit.

I first hid all non-essential elements (graphics, search, navigation, sidebars), then worked on styling the main body of the page a lot nicer. Now, it prints relatively well across Safari, Chrome, FireFox, and Internet Explorer. However, there's a weird bug in FireFox that causes some pages to print with a blank leading page, then with cut-off content on the second page.

Online vs Printed Layout

At least it looks pretty :)

I think you'd be surprised how many people print out articles and pages from your website—especially if your site is heavy on written content. It's a good idea to cater to them just as you would to mobile readers and those using less-than-ideal browsers (<cough>IE</cough>).

Google's New Open Font Library

Reposted from Life is a Prayer.com:

Today Google announced they'd help advance web typography by hosting open-sourced fonts on their CDN, and by giving the code to easily embed fonts on websites on a new website, the Google Font Directory.

It was amazingly simple: just copy the <link> code and paste it in your template's header, then set any element on your page to use the Google-provided font(s). I started using OFL Sorts Mill Goudy TT, and I like the look (except for the lower-case y, which seems to be cut off).

(The code simply adds an @font-face declaration via a Google-hosted CSS file... I wonder if it's legit to self-host the CSS and font file; I haven't read through the terms and conditions yet).

I'm thinking of using this library for a few other projects on which I'm working. Much easier than Typekit, and it doesn't require any javascript or flash overhead, like alternatives such as Cufon and sIFR do. (Source).

Vatican Announces Upgrade of Network Infrastructure

It looks like the Vatican is going optical! Here are the details, from CathNews Asia:

The Vatican City State has announced a major upgrade to its communications infrastructure including fibre optics links to other Vatican sites including the pontifical villa at Castelgandolfo.

The Governorate of the Vatican City State and Telecom Italia announced the signing of a contract for the installation of the first nucleus of the “Integrated Communication Infrastructure for Vatican City State”, VIS reports.

This consists in a broadband IP network capable of voice, data and video transmission within the territory of the Holy See and Vatican City State, a communique says.

The plan includes, among other things, fibre optic cable links between the ten main extraterritorial sites including the Pontifical Villas at Castelgandolfo and the radio stations in Santa Maria de Galeria.

Creating a More Friendly 404 Page

I finally had a little time today to update the Archdiocese of Saint Louis' 404 Not Found page. Drupal has built-in 404 handling, so I simply created a new node, added in the content of the 404 page in the node body, and went to the 'site information' page to set 404 errors to that node.

Archdiocese of Saint Louis - 404 Page

In redesigning the page, I wanted to fulfill two goals: Continue Reading »

Franciscan Monks Involved in Drupal Core Development!

According to Dries Buytaert, a Franciscan Monk was working on Drupal Core at DrupalCon SF last week; he was involved in the core developer's summit with 149 other attendees.

[At Drupalcon, we] organized a core developer summit with 150 attendees, 16 lightning talks, 11 breakout sessions and 1 Franciscan monk.

Where are the Jesuits? The Dominicans? Any other orders? In the Archdiocese of Saint Louis, many of the curial websites are running on Drupal. I also hear the Legionaries have a lot of Drupal involvement (for instance, their Familia website).

Plan for Emergencies—Before they Happen

I was recently emailed by an organization who has recently had their website go belly-up, and they lost most of their recent data. Their development company supposedly has some backups, but are not being the best of communicators right now (it can happen to the best of us).

So, in the email, I was asked to offer my help in getting their site back online. Unfortunately, I can do just about nothing, since the organization has no backups, no data, not even an old database backup.

If you run a website, do the following right now:

  1. Set up an automated weekly or monthly backup of the entire website (daily, if your data merits that level of backup), including the site database, in case of catastrophe. Keep it locally (i.e. within your offices, or on an accessible backup server). This way, even if your developer goes belly-up, you can transfer the backup to someone else and quickly get back up and running (within a day or two). (I might do a post on how the Archdiocese maintains weekly backups of everything in two separate locations soon...).
  2. Develop a site maintenance and upgrade plan; with content managed websites, maintenance and security patches must be applied on a monthly or quarterly basis (I do it every week on the Archdiocesan website), otherwise maintenance and upgrade costs will go through the roof in as little as a year's time.

Do these things, and nobody gets hurt.

It's also good practice to have more than one developer in your rolodex (er... iPhone?), in case your main developer is inaccessible. Better yet, have someone on-staff who can help in a pinch (or full time!).

Speeding up a Site: Quicker 404 Errors for files in Drupal

On the Archdiocese of Saint Louis website, we moved thousands of files around as part of our site migration from 49 separate Joomla sites to Drupal. Internally, all our file links were updated. However, there are thousands of hotlinks from different websites to the Archdiocesan website (for instance, the blog American Papist hits a missing file of a Church interior about 80 times a day).

This was creating a lot of overhead for the server, as Drupal would do a full bootstrap, sending out a fully-rendered 404 page on each missing file request.

Looking to Drupal forums for help, I found some help from kbahey, founder/owner of 2bits, a Drupal shop that specializes in speeding up large Drupal sites. The advice in the issue linked above has the proper code for speeding up requests on a Drupal 7 site, but the code is slightly different for Drupal 6.x. Here's the code:

<?php
/**
* 404 Handling, to conserve server resources upon missing image/text/non-html file.
*/
if (preg_match("/\.(txt|png|gif|jpe?g|shtml?|css|js|ico|swf|flv|cgi|bat|pl|dll|exe|asp)$/", $_SERVER['QUERY_STRING'])) {
header('HTTP/1.0 404 Not Found');
print
'<html><head><title>404 Not Found</title></head><body><h1>404 Not Found</h1><p>The requested URL was not found on this server. If you think you reached this page in error, please visit the <a href="http://archstl.org/">Archdiocese of Saint Louis home page</a> and search for the page or file for which you are looking.</p></body></html>';
exit();
}
?>

You can simply paste this at the bottom of the settings.php file.

In a nutshell, it does the following: If the request is for a file in it's list of regular expressions, and the file is not found, it will output 404 headers, along with a simple HTML string.

This is a heck of a lot faster than allowing a full Drupal bootstrap on each missing file request—an operation which, on our server, takes up a nice 30 MB of RAM, plus a lot extra CPU usage per request, when compared with using the code above.

Syndicate content Syndicate content Syndicate content Syndicate content