Add special character to glossary

Hello. First off, excuse my English. Not my native language :slight_smile:

As mentioned, I’m not English and in our language we have 3 special characters we use a lot.

æ (ae), Æ (ae), ø (oe), Ø (oe), å (aa), Å (AA)

I’m not a coder either, so for me PHP is some crazy stuff :stuck_out_tongue: I figured, well, I gotta lern PHP but not in the middle of a project. Therefore I ask you kindly… Can you please help me with adding æ Æ, ø Ø and å Å to my “glossary” page? —> http://aakk.brandkom.no/index.php/aakk/new-layouts/glossary

In glossary.php on my other server:
I’ve removed “blocing” from line 46, 50 and 52.
I’ve also changed the gateway to allow æ, ø and å…
[php]if ($firstChar < ‘a’ || $firstChar > ‘å’) {[/php]

A new group appears on the page but a questionmark is blocking the letter, I guess thats because the document is UTF-8, right?

I was also thinking, maybe I have to change the code below, but I don’t know… As mentioned. I’m not a coder… Please assist :slight_smile:

[php]$groups[$other] = array();
$other = array(
);[/php]

UTF-8 is the correct charset for international characters, how have you set the page to be UTF-8? It can be a tedious task on old PHP versions, as of today PHP runs UTF-8 out of the box though, so if you can upgrade it will probably be a lot easier.

I belive it’s UTF-8 by joomla standards, Norwegian sites is mostly iso-8859-1. And I also believe UTF-8 won’t display special characters like that on the page by default, so any upgrading won’t help my case. I think my webhotel use the latest stable PHP version available, and I use the latest on my private test-server. I always try code locally before I apply on projects. The problem occurs on both my own server and the webhotel, so I believe I need more code to the document rather than upgrading anything.

I probably need more code in the [php]$groups[$other][/php] to show those special characters. You can see rest of the code in the document below… And I’ll give you a pastebin to the glossary.php aswell: http://pastebin.com/ghGwKpxY

You should use UTF-8, and set up properly it should work. Im norwegian as well :wink:

You are you sure your html, php and database (if the data comes from one) is set up to use utf-8?

Everything is set up to use UTF-8 :slight_smile:

Here is what I get on my own private server after my changes:


Screenshot 2014-04-03 17.17.09.png

Must be something somewhere that’s messing it up. I’ve been using UTF-8 for norwegian sites for years as it has been the standard to use. May be some php string function that doesn’t handle unicode too well.

Do you have debugging set up so you can step through the code? Would be easier to see if the data comes from the database as expected, and if so, where it is messed up.

EIther that or you have to start dumping out data :slight_smile: and just try to figure out where it goes wrong.

Yeah, thats where I lack experience 8) Call me whatever you wan’t, but don’t tell me I’m a coder, lol.

I checked phpmyadmin, and it use utf8_general_ci. I did enable debug in joomla, but the result is totaly off for me… Lol… I’ll post the most interesting strings, cause I don’t know if those relate to the problem at hand.

NO INDEX KEY COULD BE USED … This is repeated 5-6 times throughout the log. Nothing else.

I’m totally blank… Lol…

1	SIMPLE	kco6a_languages	ALL	NULL	**NO INDEX KEY COULD BE USED**	NULL	NULL	1	100.00	Using where; **Using filesort**

**Explain** id select_type table type possible_keys key key_len ref rows filtered Extra 1 PRIMARY s const PRIMARY,idx_left_right PRIMARY 4 const 1 100.00 Using temporary; **Using filesort** 1 PRIMARY c ALL cat_idx,idx_access,idx_left_right **NO INDEX KEY COULD BE USED** NULL NULL 71 38.03 Using where 1 PRIMARY <derived2> ref <auto_key0> <auto_key0> 4 purityiii.c.id 10 100.00 Using where; Not exists; Using index 1 PRIMARY i ref idx_state,idx_catid idx_catid 4 purityiii.c.id 4 100.00 Using where 2 DERIVED parent range cat_idx,idx_left_right cat_idx 53 NULL 2 100.00 Using index condition; Using temporary; **Using filesort** 2 DERIVED cat index PRIMARY,cat_idx,idx_access,idx_checkout,idx_path,idx_left_right,idx_alias,idx_language idx_left_right 8 NULL 71 100.00 Using where; Using index; Using join buffer (Block Nested Loop) **Profile** **Call Stack**

**Explain** id select_type table type possible_keys key key_len ref rows filtered Extra 1 PRIMARY c const PRIMARY,idx_access PRIMARY 4 const 1 100.00 Using temporary; **Using filesort** 1 PRIMARY a ref idx_access,idx_catid idx_catid 4 const 87 100.00 Using where 1 PRIMARY fp eq_ref PRIMARY PRIMARY 4 purityiii.a.id 1 100.00 Using where; Using index 1 PRIMARY ua ALL PRIMARY **NO INDEX KEY COULD BE USED** NULL NULL 6 83.33 Using where; Using join buffer (Block Nested Loop) 1 PRIMARY uam eq_ref PRIMARY PRIMARY 4 purityiii.a.modified_by 1 100.00 Using where 1 PRIMARY parent const PRIMARY PRIMARY 4 const 1 100.00 Using where 1 PRIMARY v ALL PRIMARY **NO INDEX KEY COULD BE USED** NULL NULL 1 100.00 Using where; Using join buffer (Block Nested Loop) 1 PRIMARY <derived2> ref <auto_key0> <auto_key0> 4 const 10 100.00 Using where; Using index 2 DERIVED parent range cat_idx,idx_left_right cat_idx 53 NULL 2 100.00 Using index condition; Using temporary; **Using filesort** 2 DERIVED cat index PRIMARY,cat_idx,idx_access,idx_checkout,idx_path,idx_left_right,idx_alias,idx_language idx_left_right 8 NULL 71 100.00 Using where; Using index; Using join buffer (Block Nested Loop) **Profile** **Call Stack**

My document also tells me that it use UTF-8. :-/

Was your data originally in tables with Latin encoding and then you changed it to utf8? If so you will need to update your data and encode those characters. Even if it wasnt, it should still fix the black diamonds with a question mark.

Æ - Æ

æ - æ

Ø - Ø

ø - ø

Å - Å

å - å

They were inserted as UTF-8 and retrieved as UTF-8. Havn’t changed document, sql or any encondig settings.

Hmmm a second…

Could this string encode the Æ Ø Å to a another value in SQL?
[php]/* clean special char to put it into alphabet list */
function clean_special_chars ($s, $d=false) {
if($d) $s = utf8_decode( $s );[/php]

What does the data look like for those characters when you view them directly from the DB? Do they look like the characters or like the encoded versions I show you?

This is what I get… I believe PHP pulls the first letter from the DB title. I’ve tried changing alias and that doesn’t affect index letter.


How does it look without using CONVERT. Do Select title FROM yourtable

It would appear your characters are not encoded.

You lost me, I’m just a noob, lol… How do I do that?

I navigated to the main table, and then I opened “kco6a_assets” table. The title is “Åsestranda” from that view.

Can you post an SQL dump of your database?

Yeah, here are from the 2 tables on my demosetup that i found “Åsestrand” in.


purityiii.zip (95.7 KB)

See this, your data tables are not UTF-8 Character set:

ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=656 ;

The Database itself is this:

CREATE DATABASE IF NOT EXISTS purityiii DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
USE purityiii

What?? ???

I’ll try to convert…

Does anyone know if this could be joomla’s fault? I did set up phpmysql as UTF-8 before joomla install. I thought it was enough to set DB in phpmyadmin to UTF-8.

Sponsor our Newsletter | Privacy Policy | Terms of Service