IE에서는 잘 되지만 Firefox에서만 CSS가 적용되지 않는다면 서버 쪽 설정 문제일 가능성이 있습니다.
Firefox는 CSS 파일을 받아올 때 서버쪽에서 파일 형식이 text/css이다라고 정확하게 말해주지 않으면 CSS 파일을 받아도 CSS로 해석하지 않는데요, 일부 웹서버에서 이런 설정(MIME-Type)이 누락된 경우가 있습니다.

그런데... 링크해주신 홈페이지를 로딩할 때 날아오는 HTTP 헤더를 뽑아보니 css 파일에 대한 mime-type이 "text/css;charset=euc_kr" 이렇게 되어 있고 내부적으로는 utf-8 인코딩을 사용한 파일이군요. IE와 Google Chrome 등 다른 브라우저는 잘 되나 Firefox 3.0에서는 적용되지 않더군요.;;;

그래서 테스트를 해보았습니다.
utf-8로 작성된 스타일시트를 불러올 때 웹서버가 보내주는 HTTP 헤더의 Content-Type을 각각 다르게 해봤는데요,

"text/css;charset=euc_kr" -> 인식 못함
"text/css;charset=euc-kr" -> 스타일시트 적용은 되지만 utf-8 한글로 적은 글꼴에 대한 스타일 선언 무시됨
"text/css;charset=utf-8" -> 정상
"text/css" -> 정상

세미콜론 뒤에 공백이 있느냐 없느냐는 영향을 주지 않았습니다.

서버 관리자나 웹호스팅 업체 측에 css mime-type의 charset 부분을 없애달라고 해보세요.
그나저나 이건 Firefox 버그 같기도 하네요;;; 한국 모질라 포럼에도 올려두었습니다.

이게... 제가 어제 쿨엔님과 OpenID 로그인 버그 테스트하면 알게 된 사실인데요, Session 테이블의 data 필드에 68KB 이상의 데이터가 들어가는 경우도 있습니다.; MySQL에서 strict mode가 활성화되어 있다면 짤리는 정도가 아니고 멈춰버리죠;;; 따라서 2048 정도의 작은 크기로 하면 오픈아이디 로그인에 문제가 생길 수 있습니다. orz

앗, 잠시, inureyes님께 질문 하나 드립니다-
1.7.5 이후의 htaccess 관련 코드에서 지하님이 적으신 대로 되어 있어서 제가 IIS 지원 추가 작업할 때 rewrite rule 기준을 위와 같이 잡고 했는데 이러면 지하님이 지적해주신 문제가 그대로 이어지는 것 아닌가요?;
어떤 rewrite rule을 쓰는 것이 맞는지 정리해주세요~

우선 티켓 #1094로 등록했습니다;

현재 텍스트큐브에서는 비밀번호 확인 기능을 제공하고 있지 않습니다.
대신 사용자 계정이 MySQL DB에 저장되어 있으므로, phpmyadmin과 같은 데이터베이스 관리 프로그램을 이용해 텍스트큐브가 생성한 사용자 정보 테이블에 접근하면 ID를 알 수 있습니다. 비밀번호는 단방향 해시 함수로 암호화되어 있기 때문에 거꾸로 알아낼 수 없고 단지 새로운 비밀번호로 설정하는 것만 가능합니다.

데이터베이스에 접속하기 위한 정보는 설치된 디렉토리의 config.php를 보시면 알 수 있을 겁니다.

setup.php에서 해당하는 부분의 코드가 400번째 줄 근처에

<li><?php echo _t('하드웨어');?>: <?php echo @exec('uname -mp');?></li>

이것인데 아마 exec 명령을 실행하는 도중 오류가 발생한 것 같습니다.

호스팅에서 막아두어서 그럴 수도 있으니 이 줄과 그 아랫줄의 exec 명령을 지우고 해보세요.

setup.php 뜯어고쳐서 IIS에서 설치할 경우 스스로 인식하여 IIS용 ISAPI Rewrite Filter에 맞는 룰들을 생성하도록 하였습니다. 별도 안내 없이 설치 과정에서 잘 따라하면 설치할 수 있으리라 (혼자) 생각해봅니다. (...)

음, 무조건 CP949로 변환되어버리는 듯하군요.
일단 rewrite 모듈이 적용되지 않아 query string으로 경로가 넘어가고 mod_url을 꺼둔 상황에서 query string의 인코딩이 자동으로 변환되는 현상이 어떤 조건일 때 나타나는지 확인해볼 필요가 있겠습니다.

SkyLine님께 한 가지 여쭤볼 것이 있습니다.

우선 현재 재현된 상황은 서로 다른 세션(한 컴퓨터 내에서 다른 브라우저를 이용하거나 다른 컴퓨터를 이용하거나)으로 접근했을 때 카테고리를 고친 쪽의 세션이 실제로 그 카테고리 페이지를 열어보기 전에 다른 한 쪽의 세션이 해당 카테고리에 접근할 경우 캐시 갱신이 안 되어 있는 것입니다.

실제로 사용하신 상황을 좀더 구체적으로 말씀해주시면 도움이 될 것 같습니다.

일단 저희가 할 수 있는 범위 내에선 취해드릴 수 있는 조치가 없네요.
사용하시는 DNS 서버를 다른 것으로 바꿔보심은 어떨지요? 예를 들면 OpenDNS라든지요.

그래도 안 된다면 서버 지원을 해주고 있는 TNC 측에 문의하여 IDC 쪽에 연락을 해봐야 할 것 같습니다.

내부적으로 사용하는 방화벽 툴에 의해 자동 차단된 것 같습니다.
일단 해제해드렸으니 확인해보세요.

아마 1.x 대에서는 힘들 것 같고 2.0 정도에서나 지원이 가능할 듯 싶습니다.
다양한 DBMS 모듈을 사용할 수 있도록 하는 대응이 추가되는 중입니다;

티켓 #1084로 등록하였습니다.