Problém s kódováním češtiny

[TomasEParticipant]

Ahoj,

narazil jsem na velice zajímavý problém. V e-shopu WooCommerce používám doplněk pro generování faktur v PDF, který pro generování toho PDFka používá knihovnu dompdf. Po aktualizaci na český WPress 3.6 se začalo v generovaných fakturách rozpadat kódování, po dluhém a vyčerpávajícím bádání jsem zjistil, že to má na svědomí funkce strtolower(). Od místa kde je text (obsah proměnné) upraven touto funkcí je veškerý text úplně rozpadlý.

Když jsem tuto funkci vyhodil, zase všechno začalo fungovat normálně.

Zatím jsem neměl sílu bádat nad tím, jestli ta funkce zlobí jen v kombinaci s tím dompdf nebo i když je použitá jinde.

Napadá někoho, kde může být příčina této chyby? Ve WP 3.5.2 to ještě fungovalo normálně.

[adminKeymaster Web]

O jaký doplněk pro WooCommerce se přesně jedná? Našel jsem např. PDF Invoices?

Nějaká souvislost s WordPressem 3.6 by tam teoreticky být mohla, ale samotná čeština by to neměla ovlivnit. Objevil jste, že problémy způsobovala funkce strtolower(), ale kde byla konkrétně použita (aneb kde jste ji přesně opravil)? Správně by tam asi měla být funkce mb_strtolower(), kde můžete definovat všeobecné kódování UTF-8.

Problém může být přímo ve WordPressu, pluginu WooCommerce nebo v doplňku pro generování .pdf šablon, těžko říci bez dalších podrobností… Nemohlo dojít také k nějaké změně prostředí na hostingu?

[TomasEParticipant]

Ano, jedná se o oficiální doplněk PDF Invoices, funkce byla použita na dvou místech – v souboru upravených, předefinovaných funkcí v adresáři šablony a na jiném místě, přímo v souboru pluginu PDF Invoices. V obou případech vzniká ta chyba, ale oba případy taky generují ten kód pro PDF.

Zatím jsem ještě neměl čas vyzkoušet funkci někde jinde ve WordPressu, takže nevím, jestli se problém vyskytuje jen při použití toho generátoru PDF nebo i jinde.

S hostingem to nesouvisí, protože to mám nainstalováno všechno na lokálu (přes XAMPP) a všechny ostatní verze stejného webu fungují normálně. Nefunguje to jen v té jedné, kde je právě instalace toho nejnovějšího WP 3.6 s již integrovanou češtinou.

Problém jsem zatím vyřešil tím, že jsem funkci na obou místech vyhodil. Jakmile budu mít chvíli, vyzkouším jí nahradit tou funkcí mb_strtolower() a uvidíme.

Zatím díky za tip!

[adminKeymaster Web]

Pokud se ta chyba neobjevuje přímo v souborech WordPressu, tak by tím neměla být aktualizace ovlivněna. Ale možná je funkce strtolower() součástí nějaké funkce, která se napojuje pomocí hooku do WordPressu a tam k nějaké změně dojít mohlo. Zkoušel jste napsat na podporu pluginu? Jde o placený produkt a kódování by asi měli mít pořešené, protože pokud nejde čeština, tak nepůjde ani žádný jiný “exotický” jazyk. A pokud není problém v pluginu, tak by mohlo jít také o šablonu, těžko říci bez konkrétního zdrojového kódu… Používáte nejnovější verze šablony i pluginu?

[TomasEParticipant]

Tak jsem vyzkoušel nahradit tu funkci strtolower() funkcí mb_strtolower() a už to zase funguje!

Tu původní funkci jsem tam přidával sám, takže za to výrobce pluginu asi nemůže…

Šablonu používám MIO od Splashing Pixels a všechny doplňky i e-shop používám nejaktuálnější.

Pro představu přidávám kód s definicí té problémové funkce:

add_filter ( 'pdf_template_order_shipping' , 'custom_order_shipping', 20, 3 );

function custom_order_shipping ( $output, $order_id ) {

global $woocommerce;

$woocommerce_pdf_invoice_options = get_option( 'woocommerce_pdf_invoice_settings' );



if (!$order_id) return;

$order = new WC_Order( $order_id );

$output = '';



$output = 'Způsob dopravy: ' . '<strong>' . strtolower($order->get_shipping_method()) . '</strong>'  ;



return $output;

}

[adminKeymaster Web]

Aha, takže jestli jsem to dobře pochopil, tak jste tam funkci strtolower() přidal dodatečně (viz “Způsob dopravy”)? Tím se asi všechno vysvětluje a WordPress z toho vychází bez viny :-)

Doporučuji ale neupravovat přímo soubory pluginu/šablony, ale použít uvedený hook pdf_template_order_shipping (a samostatný vlastní plugin).

[Autor]

Příspěvky