| Bugs in V.2.8.1 RC1 [message #158960] |
Sun, 19 April 2009 19:08  |
Peter Vendike
Messages: 65
Registered: February 2009
Location: Denmark
Karma: 0
|
Member
Translator |
|
|
Made a new installation of 2.8.1RC1
Can't register new users
The register link only gives an empty page.
In error log:
Parse error: syntax error, unexpected T_STRING in /srv/www/htdocs/fud/theme/default/pre_reg.php on line 78
It is possible to register by entering by hand:
http://(address)/(forum)/index.php?t=register&®_coppa=0
My System:
FUDforum: 2.8.1RC1
PHP: 5.2.9
MYSQL: 5.0.67
In the same line:
Despite I set for short links all links come in the form of (typical)
http://(address)/(forum)/index.php?t=pre_reg&S=996373e51301c2cfff6778d2 164ac95d:
or
http://(address)/(forum)/index.php?S=42dd810da36f9ae9d30e07da73c4a6af&S Q=d660de26316c6701198f036d48b91bde&t=search&srch=111&btn_submit =Søg&field=all&forum_limiter=&search_logic=AND&sort_order= DESC&author=
[Updated on: Sun, 19 April 2009 19:55] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Bugs in V.2.8.1 RC1 [message #158968 is a reply to message #158963] |
Mon, 20 April 2009 07:46  |
Peter Vendike
Messages: 65
Registered: February 2009
Location: Denmark
Karma: 0
|
Member
Translator |
|
|
| naudefj wrote on Sun, 19 April 2009 21:57 | Strange, I can register other users on my test forum. What is on line 78?
Yip, "russian" is now UTF-8. Like all the other translations.
|
Strange, yes you are right, I should have looked at that line myself.
I checked now it only happens when you use danish as default language.
It is caused by my danish translation file, the registration form where I did use ' instead of " which breaks the php logic. I will send in a corrected msg-file later, (looking for more mistakes first)
I still only can compile the foreign utf-8 characters when i use my "patch" in compiler.inc line 187 to 194:
// if (stristr($GLOBALS['char_set'], 'utf-8') !== false && substr(PHP_OS, 0, 3) == "WIN") {
// Windows doesn't have UTF-8 locales
$func = '\'.utf8_encode(strftime("';
$close = ')).\'';
// } else {
// $func = '\'.strftime("';
// $close = ').\'';
// }
My system runs on Opensuse 11.0
|
|
|
|
|
|
| Re: Bugs in V.2.8.1 RC1 [message #158997 is a reply to message #158990] |
Wed, 22 April 2009 09:32 |
Peter Vendike
Messages: 65
Registered: February 2009
Location: Denmark
Karma: 0
|
Member
Translator |
|
|
Ok, DA_da.UTF-8 works with compiler.inc, but in Wiki you write:
" Locale is the setting FUDforum will export to PHP making php automatically format various strings such as dates according to certain language/country. This field is automatically filled in using JavaScript when you select the language, however you can change the value manually if you believe you have a better alternative to the one offered.
If you are unsure of what this option does, it is better to leave the default value as the locale setting."
I've never seen that field automatically filled with any UTF-8 versions, but should be from the below list, would be nice if it was. Should the UTF-8 part even be necessary as all msg-files are in utf-8? It is mandatory now for the international characters to appear in dates.
af_ZA.UTF-8, am_ET.UTF-8, an_ES.UTF-8, ar_AE.UTF-8, ar_BH.UTF-8, ar_DZ.UTF-8, ar_EG.UTF-8, ar_IN.UTF-8, ar_IQ.UTF-8, ar_JO.UTF-8, ar_KW.UTF-8, ar_LB.UTF-8, ar_LY.UTF-8, ar_MA.UTF-8, ar_OM.UTF-8, ar_QA.UTF-8, ar_SA.UTF-8, ar_SD.UTF-8, ar_SY.UTF-8, ar_TN.UTF-8, ar_YE.UTF-8, as_IN.UTF-8, ast_ES.UTF-8, az_AZ.UTF-8, be_BY.UTF-8, bg_BG.UTF-8, bn_BD.UTF-8, bn_IN.UTF-8, br_FR.UTF-8, bs_BA.UTF-8, byn_ER.UTF-8, ca_AD.UTF-8, ca_ES.UTF-8, ca_FR.UTF-8, ca_IT.UTF-8, cs_CZ.UTF-8, cy_GB.UTF-8, da_DK.UTF-8, de_AT.UTF-8, de_BE.UTF-8, de_CH.UTF-8, de_DE.UTF-8, de_LU.UTF-8, el_CY.UTF-8, el_GR.UTF-8, en_AU.UTF-8, en_BE.UTF-8, en_BW.UTF-8, en_CA.UTF-8, en_DK.UTF-8, en_GB.UTF-8, en_HK.UTF-8, en_IE.UTF-8, en_IN.UTF-8, en_NZ.UTF-8, en_PH.UTF-8, en_SG.UTF-8, en_US.UTF-8, en_ZA.UTF-8, en_ZW.UTF-8, es_AR.UTF-8, es_BO.UTF-8, es_CL.UTF-8, es_CO.UTF-8, es_CR.UTF-8, es_DO.UTF-8, es_EC.UTF-8, es_ES.UTF-8, es_GT.UTF-8, es_HN.UTF-8, es_MX.UTF-8, es_NI.UTF-8, es_PA.UTF-8, es_PE.UTF-8, es_PR.UTF-8, es_PY.UTF-8, es_SV.UTF-8, es_US.UTF-8, es_UY.UTF-8, es_VE.UTF-8, et_EE.UTF-8, eu_ES.UTF-8, fa_IR.UTF-8, fi_FI.UTF-8, fo_FO.UTF-8, fr_BE.UTF-8, fr_CA.UTF-8, fr_CH.UTF-8, fr_FR.UTF-8, fr_LU.UTF-8, ga_IE.UTF-8, gd_GB.UTF-8, gl_ES.UTF-8, gv_GB.UTF-8, he_IL.UTF-8, hi_IN.UTF-8, hr_HR.UTF-8, hsb_DE.UTF-8, hu_HU.UTF-8, id_ID.UTF-8, is_IS.UTF-8, it_CH.UTF-8, it_IT.UTF-8, iw_IL.UTF-8, ja_JP.UTF-8, ka_GE.UTF-8, kk_KZ.UTF-8, kl_GL.UTF-8, ko_KR.UTF-8, ku_TR.UTF-8, kw_GB.UTF-8, lg_UG.UTF-8, lt_LT.UTF-8, lv_LV.UTF-8, mg_MG.UTF-8, mi_NZ.UTF-8, mk_MK.UTF-8, ml_IN.UTF-8, mn_MN.UTF-8, mr_IN.UTF-8, ms_MY.UTF-8, mt_MT.UTF-8, nb_NO.UTF-8, ne_NP.UTF-8, nl_BE.UTF-8, nl_NL.UTF-8, nn_NO.UTF-8, no_NO.UTF-8, oc_FR.UTF-8, om_ET.UTF-8, om_KE.UTF-8, pa_IN.UTF-8, pl_PL.UTF-8, pt_BR.UTF-8, pt_PT.UTF-8, ro_RO.UTF-8, ru_RU.UTF-8, ru_UA.UTF-8, se_NO.UTF-8, sh_YU.UTF-8, sid_ET.UTF-8, sk_SK.UTF-8, sl_SI.UTF-8, so_DJ.UTF-8, so_ET.UTF-8, so_KE.UTF-8, so_SO.UTF-8, sq_AL.UTF-8, st_ZA.UTF-8, sv_FI.UTF-8, sv_SE.UTF-8, ta_IN.UTF-8, te_IN.UTF-8, tg_TJ.UTF-8, th_TH.UTF-8, ti_ER.UTF-8, ti_ET.UTF-8, tig_ER.UTF-8, tl_PH.UTF-8, tr_CY.UTF-8, tr_TR.UTF-8, tt_RU.UTF-8, uk_UA.UTF-8, ur_PK.UTF-8, wa_BE.UTF-8, xh_ZA.UTF-8, yi_US.UTF-8, zh_CN.UTF-8, zh_HK.UTF-8, zh_SG.UTF-8, zh_TW.UTF-8, zu_ZA.UTF-8, aa_DJ.UTF-8, aa_ER.UTF-8, aa_ET.UTF-8,
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Bugs in V.2.8.1 RC1 [message #159026 is a reply to message #159017] |
Fri, 24 April 2009 11:24 |
Peter Vendike
Messages: 65
Registered: February 2009
Location: Denmark
Karma: 0
|
Member
Translator |
|
|
Character conversion goes to Windows locals, should go to Linux locales.
In the source, I find this sections doing all conversion. Is this true?
from maillist.php,v 1.77
line 407-410:
list($GLOBALS['usr']->lang, $locale) = db_saq("SELECT lang, locale FROM ".sql_p."themes WHERE theme_opt=1|2 LIMIT 1");
/* set locale */
$GLOBALS['good_locale'] = setlocale(LC_ALL, $locale);
line 472-486:
$msg_post->body = apply_custom_replace($msg_post->body);
if (!($mlist->mlist_opt & 16)) {
if ($frm->forum_opt & 16) {
$msg_post->body = tags_to_html($msg_post->body, 0);
} else {
$msg_post->body = nl2br($msg_post->body);
}
}
fud_wordwrap($msg_post->body);
$msg_post->subject = htmlspecialchars(apply_custom_replace($emsg->subject));
if (!strlen($msg_post->subject)) {
mlist_error_log("Blank Subject", $emsg->raw_msg);
$msg_post->subject = "(no subject)";
}
--------------------------------------------------------------
from replace.inc.t,v 1.20:
function apply_custom_replace($text)
{
if (!defined('__fud_replace_init')) {
make_replace_array();
}
if (empty($GLOBALS['__FUD_REPL__'])) {
return $text;
}
return preg_replace($GLOBALS['__FUD_REPL__']['pattern'], $GLOBALS['__FUD_REPL__']['replace'], $text);
}
function make_replace_array()
{
$GLOBALS['__FUD_REPL__']['pattern'] = $GLOBALS['__FUD_REPL__']['replace'] = array();
$a =& $GLOBALS['__FUD_REPL__']['pattern'];
$b =& $GLOBALS['__FUD_REPL__']['replace'];
$c = uq('SELECT with_str, replace_str FROM {SQL_TABLE_PREFIX}replace WHERE replace_str IS NOT NULL AND with_str IS NOT NULL AND LENGTH(replace_str)>0');
while ($r = db_rowarr($c)) {
$a[] = $r[1];
$b[] = $r[0];
}
unset($c);
define('__fud_replace_init', 1);
}
|
|
|
|
|
|
|
|
|
|
| Re: Bugs in V.2.8.1 RC1 [message #159051 is a reply to message #159047] |
Tue, 28 April 2009 19:38 |
Peter Vendike
Messages: 65
Registered: February 2009
Location: Denmark
Karma: 0
|
Member
Translator |
|
|
| naudefj wrote on Mon, 27 April 2009 22:05 | The subject must be Q-encoded. Here is an example (PHP5 only, unfortunately):
iconv_mime_encode("Subject", $subject,
array('scheme'=>'Q', "input-charset"=>$GLOBALS['CHARSET'],"output-charset"=>$GLOBALS['CHARSET']))."\r\n");
|
using iconv_mime_decode in stead of decode_header_value in maillist.php solves the problem, but I don't know if ther are other effects.
2 testmails I use for this testing imported without problems now, one coded in ISO-8859-1, the other in UTF-8.
change maillist.php ver 1.77 like this:
(together with earlier patch)
line 56:
if (!isset($this->headers[$hk])) {
$this->headers[$hk] = iconv_mime_decode($hv,2,'UTF-8');
} else { $this->headers[$hk] .= ' '.iconv_mime_decode($hv,2,'UTF-8');
}
|
|
|
|
|
|
|
|
| Re: Bugs in V.2.8.1 RC1 [message #159060 is a reply to message #159057] |
Thu, 30 April 2009 14:34 |
Peter Vendike
Messages: 65
Registered: February 2009
Location: Denmark
Karma: 0
|
Member
Translator |
|
|
Hey, I think i need to know a diff system, made this by hand, hope it works.
diff -u -r1.77 maillist.php
--- maillist.php 2009/02/28 11:47:18 1.77
+++ maillist.php
@@ -215,3 +215,3 @@
function decode_message_body()
{
- $this->body = decode_string($this->body, $this->headers['content-transfer-encoding']);
+ $this->body = decode_string($this->body, $this->headers['content-transfer-encoding'], $this->headers['__other_hdr__']['content-type']['charset']);
}
then I think we just change function decode_header_value($val) in scripts_common.inc to be iconv_mime_decode($val,2,'UTF-8') for php >= 5
diff for scripts_common.inc
??????????????????????
|
|
|
|
| Re: Bugs in V.2.8.1 RC1 [message #159071 is a reply to message #159060] |
Sat, 02 May 2009 12:40 |
 |
naudefj
Messages: 3771
Registered: December 2004
Karma: 28
|
Senior Member
Administrator
Core Developer |
|
|
You can make a patch by running one of the following commands:
$ diff -u oldfile newfile >patch
or if you have CVS installled:
Please check if you still need the "iconv_mime_decode" if you apply this patch to scripts_common.inc:
diff -u -r1.36 scripts_common.inc
--- scripts_common.inc 15 Feb 2009 20:01:03 -0000 1.36
+++ scripts_common.inc 2 May 2009 12:36:48 -0000
@@ -147,9 +147,9 @@
$ec_type = strtolower($m[4][$i]);
if ($ec_type == 'q') {
- $newval .= decode_string(str_replace('_', ' ', $m[5][$i]), 'quoted-printable');
+ $newval .= decode_string(str_replace('_', ' ', $m[5][$i]), 'quoted-printable', $m[3][$i]);
} else if ($ec_type == 'b') {
- $newval .= decode_string($m[5][$i], 'base64');
+ $newval .= decode_string($m[5][$i], 'base64', $m[3][$i]);
}
if (!empty($m[5][$i])) {
Best regards.
Frank
|
|
|
|
|
|
|
|
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]