Drupals internationalisation (or i18n) module works really well and is fairly intuitive. I had no problems setting up a multilanguage site, save one: translating custom blocks.

If you want multilanguage custom blocks, you have to create one for each language. Then, in in »configure« → »multilingual settings«, pick the language you want the block to appear in (not: »All Languages« and not »All Languages (translatable)«!).

And now the fun started: it didn't work whatever I tried until by sheer luck I stumbled upon the solution after wasting almost an entire Saturday.

Go to »Administer → Site Configuration → Languages«. Here, pick the »configure«-Tab. There are four options for »Language Negotiation«. Fo me »none« was selected. This one is the one that doesn't show translated blocks. So pick anotherone and you're good.

I usually develop locally to an advanced degree and then export the local database and import it on the server. If you do that with Drupal, you might have noticed that the database can easily become risiculously large. Mine had 6MB on a site with hardly any content. In that case truncate all cache tables before exporting the local db (after that mine was down to around 250 KB). That should make things easier.

If you did everything you should to enable FCK-editor with Drupal 6 in a customised theme, but it still doesn't show, switch back to Garland theme. When it shows there, switch back to your theme, open its page.tpl.php and check if it has

<?php print ($closure); ?>

right above the </body> tag. Let me tell you: it's a must have these days...

In Drupal 6 I wanted to use

require_once($base_path.'sites/all/themes/skin/functions.php');

in

drupalinstallation/sites/all/themes/skin/page.tpl.php

but had an error concerning root_path being somewhere completely yonder.

Thus (as marky suggests) I opened

drupalinstallation/includes/common.inc

and added

at the very bottom and now

require_once('./sites/all/themes/skin/functions.php');

seems to work. Only I don't know whether it's smart and safe editing common.inc like that. Thus it works and I have a bad feeling...

I can't seem to get my head around this one. Whenever I use an ftp client (gftp and FileZilla mostly), eventually my wifi connection breaks. I have to disconnect the router from the power supply, wait a couple of seconds and plug it in again. Sometimes network manager reconnects automatically, sometimes I have to reconnect manually and at other times I have to log off and on again before I can reconnect. The symptoms are very similar to this bug, but exclusively happen while I have an ftp connection established.

The only other instance of my problem I could find is afulls04 on tomshardware.co.uk ftping into his x-box.

I use a D-LINK DSL-G624T router (which I learned to hate pretty soon), lspci reports

03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

and I (still) am on ubuntu 7.10.

I also posted this to the ubuntu forum.

Until yesterday I was convinced that wherever an Ethernet cable came through a wall, all I had to do was plug it into my computer. Safe, secure, fast, no user name, no password, no fuss.

Wrong.

When Virgin is supplying the ethernet, it is probably also supplying a Virgin modem. In my case a Virgin cable modem (which made my ADSL wifi router as useless as could be, but that is an altogether different story).

Virgin apparently stores the MAC address of the piece of equipment that is directly connected to the modem. If it is a router, you're good. If it's your computer and you somehow have the strange idea to access the internet with a different machine, you need three to five minutes of patience.

Virgin – in its infinite wisdom – only ever allows one MAC address at a time. So if you want to access the tubes with another computer, you have to power down the modem to have it taste a blow of instant amnesia. Opinions vary how long it takes, three to five minutes is the most frequent estimation for a modem to forget previous relationships.

Then: power it on again. Plug in your different machine. Repeat each bloody time you change machines. Thanks Virgin.

I recently put together a website for a German university department making use of Drupal. Drupal offers a function where you can promote articles to the front page. You can also specify if you want the full content of each promoted article on the front page or just a teaser. My client decided, they wanted teasers of 200 characters in length. After thorough testing the site went live and trouble came rolling in. All of a sudden the little teaser boxes started behaving in a strange way, popping up in strange places, overlapping each other and ruining the entire layout.

What was the problem?

It was obvious that the trouble came from a post that had a link with the 200 characters ending right inside the <a>-tag. So on the front page, everything following the teaser was considered being inside an <a>-tag as the closing </a> had been cut off.

What was not the solution?

At first my research was not very promising. I got this:

So it's the user's fault. Unfortunately I'm not in a position where I can handpick highly html-literate users for the websites I sell and thus I might have an editor-team on client side who knows zip html.

What was the solution?

Although VeryMisunderstood said

I went for it anyway. Onhand: HTML corrector did solve the problem (I believe it is now included in Drupal 6 by default). You just have to follow the steps in the installation guide:

Step three is key! I had to look around a bit and found that it was in »Administer« → »Site Configuration« → »Input Formats«. Here you have to enable the module for each desired input type (php, full html, filtered html) via the »configure«-links provided.

Firefox has a printing problem. Most people agree on this. What they can't agree on is how to fix it.

Under certain circumstances prints from Firefox only populate the first printed page and are cut off at the bottom of this single page. So when your content is longer than a page, you'll loose it. I'll cover two fixes: One for developer and one for the user.

1. The developer

The problem apparently occurs with tables and floats. I have no experience with tables concerning this problem, so if a table is causing you a headache, I'm afraid you have to look somewhere else for a solution.

As for for floats, ALA suggests to replace all your floats with

float: none !important;

in your printing stylesheet (see the same ALA article on how to create a stylesheet for a printer). I'm sure it works for them, it didn't work for me. Other solutions (that didn't work for me) included:

for the element in question.

After quite a bit of research with no result whatsoever, I started removing section for section from my original stylesheet until the problem didn't occur any more. What I found is this:
The main box has

overflow: hidden;

So in print.css the same box needs

overflow: visible !important;

and the problem is fixed (note: overflow: auto; didn't work). Neither IE6 nor IE7 seemed to be bothered by the hidden overflow.

2. The User

As a user you obviously can't influence the behaviour of a given site, so you'll have to live with what's there. If you come across a page that has this printing problem, try the following:

1. press ctrl + a (to select all)
2. press ctrl +p (to open the printing menu)
3. In the printing menu try and find the options what to print. Usually you get
   
   1. »Print all«
   2. »Pages |__| to |__|« (where you can specify which pages you want)
   3. Selection.
   Pick »Selection« and you should get all you selected all right onto that piece of paper.

At the moment I am setting up the new website for the department of Romance Studies at a south German university. I want it to run on Drupal but had three [update: four] [later update: five] problems:

1. Error 500 »Internal server error«
2. Specify the correct directory
3. The uni's IT department
4. [update] SQL-Version
5. [later update] ./files/.htaccess

i. Error 500

Drupal's .htaccess file apparently can cause conflicts with other server settings. I am not very smart when it comes to servers, so I just copied my local installation to the server. There was no .htaccess in my local installation so I gather it should be save to work without it. If somebody knows more, you're more than welcome to comment on this. Also, there are two threads at the Drupal site that might be of interest: one, two.

ii. Directory

Drupal always wanted to go into a ./php directory which wasn't there. Even when I mirrored ./ to ./php it didn't work. I didn't have this issue with my local installation, so I was surprised to see it still there after my copying the local stuff to the remote server. In order to make the local installation work on the remote server, I obviously had to change the configuration (user, password, database). While doing this in ./sites/default/settings.php, I stumbled over a section called »Base URL«. It reads like this:

Just uncomment the last line by removing the hash (»#«) and write down the URL of your site and you're in business.

iii. The IT Department From Hell

[Rant warning: absolutely no relevant information in next two paragraphs]
I have some experience with this specific IT department, and I always hated to deal with them. They are neither helpful nor competent. It is the second website I am setting up for the university and both times they tried to get me into using their commercial CMS. When asked why I wouldn't want to use it, I said because it doesn't even validate with html 4.01 Transitional. He then terminated the conversation abruptly, close to hanging up in my face.

But what would one expect from an IT department where http://subdomain.uni-something.de/ will get you a time-out and only http://www.subdomain.uni-something.de/ takes you where you want to go?

iv. [Update] SQL Version

I just managed to finally import my database. I run 5.0.45, the University runs 4.0.18. On import (in phpmyadmin) I got the following:

When you export from phpmyadmin, there should be an option called »SQL compatibility mode«. In the drop-down pick the version the moron remote admin picked and you should be fine.

[Rant warning: again, next two paragraphs contain no relevant information]
Just another note: I had to listen to a bleeding sermon for half an hour that I should use their CMS because of vulnerability issues. His CMS gets updated automatically, open source ones don't. This, he said, puts the user of open source ones at risk of having the server hacked when they fail to run the latest version. If hacked, he has to shut down the server.
Now, as I mentioned above, I am not very server literate, but my common IT sense tells me, that running apache 2.0.55 (from 2005 I gather; latest release: 2.2.8) and MySQL 4.0.18 (from Feb. 2004 I understand; latest release: 5.0.51) might by far be the greater risk.

Another perversion is that I can only access their server from the local network. To vpn into this network, they provide a windows client and a Linux howto. The latter dates from 2002. As I don't feel like messing my Gutsy Gibbon up with a six year old piece of gunk, I always have to abandon my own Linux system and boot Windows to then access a remote Linux system.

v. [Later Update] ./files/.htaccess

Drupal insists on having the file .htaccess in ./files. My server insists on going haywire when there is a file .htaccess in ./files.

Bugger.

dman suggests to feed Drupal with the file but leave it empty for the convenience of a server with special needs, and it works for me.

[The usual rant]
If, as dman says, the .htaccess-file in question here actually stops user uploaded files from ever executing, why on earth does a security concerned IT-department does everything to stop the file from doing its job?