Tag: error

Gmail Storage Space Problem: Account Blocked, Wrong Numbers [en]

[fr] Problème de quota Gmail.

I’ve been sitting here for an hour with Elisabeth trying to figure out what the deal is with her Gmail storage. Here’s the story:

  • 10 days or so ago, Gmail tells her she’s used up 101% of her storage quota, blocks outgoing e-mail
  • she goes back and deletes lots of old e-mails, attachments and all (years of e-mail) but the quote indicator and message inviting her to get more storage doesn’t change
  • she empties the trash and waits 24 hours or so; still nothing; however, when she follows the link to buy more storage, the storage indicator there tells her she is now using 30% or so of her quota
  • in desperation, she buys the 25Gb Google Drive storage plan
  • 24 hours later, she notices that the block on outgoing e-mail is lifted and that her storage quote now says 90Gb — but that she is using 13.7Gb of those 90Gb.

I have poked around everywhere I could. She has almost nothing in Google Docs or Google Plus. The trash is indeed empty. The mails are indeed deleted. When we viewed her subscription plan, it indicated she was using 0.01% of her quota — obviously different numbers here.

What on earth is going on? How do we get Gmail to see how much storage she is really using? Any ideas welcome.

2nd Back to Blogging Challenge, day 2. Others: Nathalie Hamidi(@nathaliehamidi), Evren Kiefer (@evrenk), Claude Vedovini (@cvedovini), Luca Palli (@lpalli), Fleur Marty (@flaoua), Xavier Borderie (@xibe), Rémy Bigot (@remybigot),Jean-François Genoud (@jfgpro), Sally O’Brien (@swissingaround), Marie-Aude Koiransky (@mezgarne), Anne Pastori Zumbach (@anna_zap), Martin Röll (@martinroell), Gabriela Avram (@gabig58), Manuel Schmalstieg (@16kbit). Hashtag:#back2blog.

Invalid argument supplied for foreach() in wp-capabilities.php: Case Cracked! [en]

[fr] Le problème avec wp-capabilities.php qui fait qu'on peut se retrouver "exfermé" (enfermé dehors) de son blog WordPress (typiquement en cas de changement de serveur) semble avoir sa source dans le contenu du champ wp_user_roles dans la table wp_options. En particulier, pour la version française, "Abonné" est un rôle d'utilisateur, et en cas de problèmes d'encodage MySQL, le caractère accentué sera corrompu, causant ainsi l'erreur.

Il suffit de remplacer le caractère fautif dans PhpMyAdmin, et on retrouve l'accès à son blog. Bon, reste ensuite à régler les questions d'encodage... mais c'est déjà ça!

Finally. At last. Endlich. Enfin.

Once more, while trying to transfer a WordPress installation from one server to another, I found myself facing the dreaded problem which locks me out of my WordPress install with a rather cryptic message:

Warning: Invalid argument supplied for foreach() in /home/user/wp/wp-includes/capabilities.php on line 31

(Your lineage may vary.)

What happens is that WordPress cannot read user roles, and therefore, even though your password is accepted, you get a message telling you that you’re not welcome in the wp-admin section:

Vous n’avez pas les droits suffisants pour accéder à cette page.

Or, in English:

You do not have sufficient permissions to access this page.

A quick search on the WordPress forums told me that I was not alone in my fight with wp-capabilities.php, but that many problems had not been resolved, and more importantly, that suggested solutions often did not work for everyone.

I’ve bumped into this problem a couple of times before, and I knew that it was linked to encoding problems in the database. (I’ve had my share of encoding problems: once, twice, thrice — “once” being on of the most-visited posts on this blog, by the way, proof if needed that I’m not alone with mysql encoding issues either.)

I’ll leave the detailed resolution of how to avoid/cure the MySQL problems later (adding
mysql_query("SET NAMES 'utf8'"); to wp-db.php as detailed in this thread, and as zedrdave had already previously told me to do — should have listened! — should prevent them). So anyway, adding that line to my working WordPress install showed me that the problem was not so much in the database dumping process than in the way WordPress itself interacted with the database, because the dreaded wp-capabilities.php problem suddenly appeared on the original blog.

Now, this is where I got lucky. Browsing quickly through the first dozen or so of forum threads about wp-capability.php problems, this response caught my eye. It indicated that the source of the problem was the content of the wp_user_roles field (your prefix may vary). In this case, it had been split on more than one line.

I headed for the database, looked at the field, and didn’t see anything abnormal about it at first. All on one line, no weird characters… just before giving up, I moved the horizontal scrollbar to the end of the line, and there — Eurêka! I saw it.

Abonné

“Contributor”, in French, is “abonné”, with an accent. Accent which got horribly mangled by the MySQL problems which I’ll strive to resolve shorty. Mangled character which caused the foreach() loop to break in wp-capabilities.php, which caused the capabilities to not be loaded, which caused me to be locked out of my blog.

So, in summary: if you’re locked out of your blog and get a warning/error about wp-capabilities and some invalid foreach() loop thingy, head for PhpMyAdmin, and look carefully through the wp_user_roles field in the wp_options table. If it’s split over two or more lines, or contains funky characters, you have probably found the source of your problem.

Good luck!

Annoying NeoOffice Error [en]

[fr] Un problème récurrent avec NeoOffice. Vous connaissez ce message d'erreur?

I’ve been getting this error ever since I moved from my iBook to my MacBook. I’ve erased NeoOffice from my Applications folder and reinstalled it. I know we had this error at school, too. It doesn’t seem to create any problems, but it’s just annoying that the first time in a session I save a file I need to click through this (and the next).

Screenshot of error message.

Welcome to Steph’s Troubleshooting Centre, and thanks for your help!

Converting MySQL Database Contents to UTF-8 [en]

I finally managed to convert my WordPress database content to UTF-8. It’s easy to do, but it wasn’t easy to figure out.

[fr] Voici comment j'ai converti le contenu de ma base de données WordPress en UTF-8. C'est assez simple en soi, mais ça m'a pris longtemps pour comprendre comment le faire!

A few weeks ago, I discovered (to my horror) that my site was not UTF-8, as I thought it was. Checking my pages in the validator produced this error:

The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the XML declaration (utf-8). I will use the value from the HTTP header (iso-8859-1).

In all likeliness, my server adds a default header (iso-8859-1) to the pages it serves. When I switched to WordPress, I was careful to save all my import files as UTF-8, and I honestly thought that everything I had imported into the database was UTF-8. Somewhere in the process, it got switched back to iso-8859-1 (latin-1).

The solution to make sure the pages served are indeed UTF-8, as specified in the meta tags of my HTML pages, is to add the following line to .htaccess:

AddDefaultCharset OFF

(If one wanted to force UTF-8, AddDefaultCharset UTF-8 would do it, but actually, it’s better to leave the possibility to serve pages with different encodings, isn’t it?)

Now, when I did that, of course, all the accented characters in my site went beserk — proof if it was needed that my database content was not UTF-8. Here is the story of what I went through (and it took many days to find the solution, believe me, although it takes only 2 minutes to do once everything is ready) to convert my database content from ISO-8859-1 to UTF-8. Thanks a lot to all those who helped me through this — and they are many!

First thing, dump the database. I always forget the command for dumps, so here it is:

mysqldump --opt -u root -p wordpress > wordpress.sql

As we’re going to be doing stuff, it might be wise to make a copy of the working wordpress database. I did that by creating a new database in PhpMyAdmin, and importing my freshly dumped database into it:

mysql -u root -p wordpress-backup < wordpress.sql

Then, conversion. I tried a PHP script, I tried BBEdit, and they seemed to mess up. (Though as I had other issues elsewhere, they may well have worked but I mistakenly thought the problem was coming from there.) Anyway, command-line conversion with iconv is much easier to do:

iconv -f iso-8859-15 -t utf8 wordpress.sql > wordpress-iconv.sql

Then, import into the database. I first imported it into another database, edited wp-config.php to point to the new database, and checked that everything was ok:

mysql -u root -p wordpress-utf8 < wordpress-iconv.sql

Once I was happy that it was working, I imported my converted dump into the WordPress production database:

mysql -u root -p wordpress < wordpress-iconv.sql

On the way there, I had some trouble with MySQL. The MySQL dump more or less put the content of all my weblog posts on one line. For some reason, it didn’t cause any problems when importing the dump before conversion, to create the backup database, but it didn’t play nice after conversion.

I got this error when trying to import:

ERROR 1153 at line 378: Got a packet bigger than 'max_allowed_packet'

Line 378 contained half my weblog posts… and was obviously bigger than the 1Mb limit for max_allowed_packet (the whole dump is around 2Mb).

I had to edit my.cnf (/etc/mysql/my.cnf on my system) and change the value for max_allowed_packet in the section titled [mysqld]. I set it to 8Mb. Then, I had to stop mysql and restart it: mysqladmin -u root -p shutdown to stop it, and mysqld_safe & to start it again (as root).

This is not necessarily the best way to do it, and it might not work like that on your system, but it’s what I did and the site is now back up again. Comments welcome, and hope this can be useful to others!

Validation and Errors [en]

Although neither do validate, we should not judge a valid page with errors as harshly as a page of tag soup.

For some time now, I have been meaning to clarify the distinction I make between markup which is valid with errors and that which is outright invalid. Yes, I know, in both cases it does not validate.

Take a page which would normally validate as xhtml strict, and insert some are errors into it, like an unclosed tag, an unescaped ampersand and maybe even (oh horror!) a couple of target="_blank" attributes. It does not validate.

Take tag soup. It does not validate either.

But there is a difference between the two, you’ll have to admit. Which is why I suggest calling one of them valid with errors and the other one outright invalid (or just plain invalid). This would also encourage us standards evangelists to be a bit more appreciative of the efforts of those who have gone through the trouble of cleaning up their markup and bringing it nearer to validation, compared to those who just don’t give a damn. As seen on various mailing lists and forums, they are often both greeted quite bluntly with the same “your page doesn’t validate!”

For me, the difference is the same as the one between a well structured text with correct grammar but a few spelling mistakes (it can happen to anybody, even to English teachers!) and a clumsy story with no plot or ending, filled with spelling mistakes, and approximate grammar which makes certain sentences unintelligible.

That might also help us respond to “anti-standards” people who go around sticking our pages in the validator and then say “Hah! it doesn’t validate, look, 50 errors, they’re as bad as we are!”

I’ll say it again: validation (with zero errors) is important. Your PHP or XML parser doesn’t care if there is one or 100 mistakes in your page: it can’t parse it. But we are human beings, and should give credit where credit is due. A “valid page with errors” is not as big a crime as tag soup.