єдине хто цим займається бадісофт коли знаходить помилку він викладає її в своїй темі, і йому величезне за це спасибі, і він же відмінно як п'ять пальців знає движок, чому б не скинутися колективно, тому що за будь-яку роботу потрібно платити а інтернет магазин це спочатку комерційне підприємство, і нехай бадісофт за оплату протесту і переведе стандартний двигун на версії php 5.4+
Та бог з Вами, у мене давно є версія ShopCMS на UTF8. Навіщо тягнути в світле майбутнє проект на cp1251? Куди простіше один раз все це переконвертіть в UTF (з відповідною підчисткою). Хоча інші переробки (та ж передача параметрів по посиланню, що отримала новий синтаксис - символ перед назвою змінної) все одно будуть потрібні.
Проблема буде зовсім в іншому, не в движку. ShopCMS при всій своїй споконвічній убогості хороший наявністю досить великої безкоштовного і платного модульного наповнення. На будь-який смак і колір. Мало хто використовує shopCMS в голому вигляді, без доп. модулів. Хто буде перепилювати їх? Незалежно, залишаємося на cp1251 (проблема з функціями, поміняти дефолтовая кодування) або переходимо на ShopCMS / UTF8 (переробка всіх AJAX-запитів, тому що більше не потрібен iconv) - більшість модулів перестануть бути придатними для установки.
на даний момент цей магазин вмирає тільки тому що в стандарті він не може працювати на версіях більше php 5.3, як тільки він в стандарті стане на нові версії, він відразу оживе. І буде нова робота для програмістів з написання нових модулів і виправлення старих
Так що зрозуміло, коли треба підтримувати вже існуючий сайт. Я теж вважаю, що куди правильніше тримати сайт на VPS / VDS, де ти сам визначаєш версію PHP і інше наповнення. А якщо новий сайт робити, то ну його нафіг, цей некроCMS. Я-то хоч знаю його добре, у мене є мотив продовжувати робити сайти на ньому. А звичайного клієнта - нафіг таке допотопне щастя.
У мене збереглося якусь подобу інструкції, яку я писав для себе про перехід на UTF8.
Чомусь я її так і не встиг викласти на форум, не пам'ятаю вже.
Можливо, вона не повна і я хотів її дописати.
Можливо, вона десь не коректна і я хотів написати коректніше.
===========================
1. Функції htmlspecialchars (без завдання codepage зустрічається в functions.php три рази і в counter.php два рази) і html_entity_decode (без завдання codepage зустрічається в functions.php один раз).
2. Починаючи з PHP 5.6 дефолтовий для цих функцій codepage задається в php.ini налаштуванням default_charset (або в .htaccess). Тобто проблема зі зникненням російських букв тільки при PHP 5.4 і 5.5.
3. Я не помітив якихось особливих проблем з перекладу ShopCMS цілком в UTF8 та (або) надання працездатності в 5.4 і 5.5. Витратив на це години дві, не більше. Напевно, якісь проблемки вилізуть, але навcкідку все працює.
- переніс DEFINE ( 'DEFAULT_CHARSET' з language.php в init.php. Вже не пам'ятаю, навіщо. Мабуть, language.php вантажиться не у всіх випадках
- задав його як DEFINE ( 'DEFAULT_CHARSET', 'UTF8')
- всюди, де знайшлася рядок 1251 (cp1251, windows-1251) замінив її на DEFAULT_CHARSET
- перекодував файли, де є російські літери з 1251 до UTF8
- додав у xml_installer.php в функцію GetCreateTableSQL рядок "DEFAULT CHARSET =". DEFAULT_CHARSET
- додав у функції htmlspecialchars і html_entity_decode завдання DEFAULT_CHARSET (це вже для PHP 5.4 і 5.5).
- замінив клас asido на теоретично працює у версіях PHP старше 5.3 (немає поки 5.4, нема на чому перевірити).
Отриманий дистрибутив легко перемикається 1251<->UTF8. Досить змінити DEFAULT_CHARSET і перекодувати файли в потрібне кодування.
==================
єдине хто цим займається бадісофт коли знаходить помилку він викладає її в своїй темі, і йому величезне за це спасибі, і він же відмінно як п'ять пальців знає движок, чому б не скинутися колективно, тому що за будь-яку роботу потрібно платити а інтернет магазин це спочатку комерційне підприємство, і нехай бадісофт за оплату протесту і переведе стандартний двигун на версії php 5.4+
Та бог з Вами, у мене давно є версія ShopCMS на UTF8. Навіщо тягнути в світле майбутнє проект на cp1251? Куди простіше один раз все це переконвертіть в UTF (з відповідною підчисткою). Хоча інші переробки (та ж передача параметрів по посиланню, що отримала новий синтаксис - символ перед назвою змінної) все одно будуть потрібні.
Проблема буде зовсім в іншому, не в движку. ShopCMS при всій своїй споконвічній убогості хороший наявністю досить великої безкоштовного і платного модульного наповнення. На будь-який смак і колір. Мало хто використовує shopCMS в голому вигляді, без доп. модулів. Хто буде перепилювати їх? Незалежно, залишаємося на cp1251 (проблема з функціями, поміняти дефолтовая кодування) або переходимо на ShopCMS / UTF8 (переробка всіх AJAX-запитів, тому що більше не потрібен iconv) - більшість модулів перестануть бути придатними для установки.
на даний момент цей магазин вмирає тільки тому що в стандарті він не може працювати на версіях більше php 5.3, як тільки він в стандарті стане на нові версії, він відразу оживе. І буде нова робота для програмістів з написання нових модулів і виправлення старих
Так що зрозуміло, коли треба підтримувати вже існуючий сайт. Я теж вважаю, що куди правильніше тримати сайт на VPS / VDS, де ти сам визначаєш версію PHP і інше наповнення. А якщо новий сайт робити, то ну його нафіг, цей некроCMS. Я-то хоч знаю його добре, у мене є мотив продовжувати робити сайти на ньому. А звичайного клієнта - нафіг таке допотопне щастя.
У мене збереглося якусь подобу інструкції, яку я писав для себе про перехід на UTF8.
Чомусь я її так і не встиг викласти на форум, не пам'ятаю вже.
Можливо, вона не повна і я хотів її дописати.
Можливо, вона десь не коректна і я хотів написати коректніше.
===========================
1. Функції htmlspecialchars (без завдання codepage зустрічається в functions.php три рази і в counter.php два рази) і html_entity_decode (без завдання codepage зустрічається в functions.php один раз).
2. Починаючи з PHP 5.6 дефолтовий для цих функцій codepage задається в php.ini налаштуванням default_charset (або в .htaccess). Тобто проблема зі зникненням російських букв тільки при PHP 5.4 і 5.5.
3. Я не помітив якихось особливих проблем з перекладу ShopCMS цілком в UTF8 та (або) надання працездатності в 5.4 і 5.5. Витратив на це години дві, не більше. Напевно, якісь проблемки вилізуть, але навcкідку все працює.
- переніс DEFINE ( 'DEFAULT_CHARSET' з language.php в init.php. Вже не пам'ятаю, навіщо. Мабуть, language.php вантажиться не у всіх випадках
- задав його як DEFINE ( 'DEFAULT_CHARSET', 'UTF8')
- всюди, де знайшлася рядок 1251 (cp1251, windows-1251) замінив її на DEFAULT_CHARSET
- перекодував файли, де є російські літери з 1251 до UTF8
- додав у xml_installer.php в функцію GetCreateTableSQL рядок "DEFAULT CHARSET =". DEFAULT_CHARSET
- додав у функції htmlspecialchars і html_entity_decode завдання DEFAULT_CHARSET (це вже для PHP 5.4 і 5.5).
- замінив клас asido на теоретично працює у версіях PHP старше 5.3 (немає поки 5.4, нема на чому перевірити).
Отриманий дистрибутив легко перемикається 1251<->UTF8. Досить змінити DEFAULT_CHARSET і перекодувати файли в потрібне кодування.
==================
Бадісофт ось і викладайте робочу інструкцію в продаж, позбавить багатьох у кого є інтернет магазин від переходу на іншу cms, досить один раз перейти на utf 8 і проблеми з кодуванням вже пішли, а також в продаж і голий движок вже на utf8. А це в свою чергу підштовхне писати нові модулі вже під utf8? і ті що писалися люди будуть замовляти переробити під utf.