Сообщений в теме: 70

[badisoft]

единственное кто этим занимается бадисофт когда находит ошибку он выкладывает ее в своей теме, и ему огромное за это спасибо, и он же отлично как пять пальцев знает движок, почему бы не скинуться коллективно, т.к. за любую работу нужно платить а интернет магазин это изначально коммерческое предприятие, и пусть бадисофт за оплату протестит и переведет стандартный движок на версии php 5.4+

Да бог с Вами, у меня давно есть версия ShopCMS на UTF8. Зачем тащить в светлое будущее проект на cp1251? Куда проще один раз все это переконвертить в UTF (с соответствующей подчисткой). Хотя другие переделки (та же передача параметров по ссылке, получившая новый синтаксис - символ & перед названием переменной) все равно будут нужны.
Проблема будет совсем в другом, не в движке. ShopCMS при всей своей изначальной убогости хорош наличием довольно большого бесплатного и платного модульного наполнения. На любой вкус и цвет. Мало кто использует shopCMS в голом виде, без доп. модулей. Кто будет перепиливать их? Вне зависимости, остаемся на cp1251 (проблема с функциями, поменявшими дефолтовую кодировку) или переходим на ShopCMS/UTF8 (переделка всех AJAX-запросов, т.к. больше не нужен iconv) - большинство модулей перестанут быть годными для установки.

на данный момент этот магазин умирает только потому что в стандарте он не может работать на версиях больше php 5.3, как только он в стандарте станет на новые версии, он сразу оживет. И будет новая работа для програмистов по написанию новых модулей и исправлению старых

Это не так. shopCMS по нынешним реалиям В ПРИНЦИПЕ устарел. То, что в нем делается установкой десятка модулей в современном поддерживаемом авторами или сообществом магазине есть уже изначально. Тот же Gres (просто пример, который тут уже мелькал), который бесплатен до 10 категорий и 50-ти товаров, а дальше не так уж и дорог. На уровне пары моих модулей для shopCMS, которые там уже есть штатно. Также нельзя не вспомнить вполне развивающийся OpenCart, если я правильно помню название. Он (если я не путаю) вообще на shopCMS похож почти как родной (ну, пусть двоюродный) брат. Тот же шаблонизатор, довольно похожая структура каталогов. И при этом не умер на версии 2007-го года.

Так что понятно, когда надо поддерживать уже существующий сайт. Я тоже считаю, что куда правильнее держать сайт на 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 и перекодировать файлы в нужную кодировку.
==================

[straniks]

Вы правы. перестали оформляться заказы.. на почту не приходят сообщения. вообщем беда. Если какое решение? Так не хочется переходить на другой движок..

заказы каким образом не оформляются?
При нажатии добавить в карзину - 500 ошибка , обновил страницу -
Not Found
The requested URL /index.php was not found on this server.

[kery]

Вы правы. перестали оформляться заказы.. на почту не приходят сообщения. вообщем беда. Если какое решение? Так не хочется переходить на другой движок..

заказы каким образом не оформляются?
При нажатии добавить в карзину - 500 ошибка , обновил страницу -
Not Found
The requested URL /index.php was not found on this server.

500 ошибка это вообще ошибка конфигурации сервера, как правило возникает когда время на выполнения скрипта вышло, увеличте время в директивах php.ini

[badisoft]

500 ошибка это вообще ошибка конфигурации сервера, как правило возникает когда время на выполнения скрипта вышло

IMHO, это не так. web-сервер (апач, нгинкс) возвращает код 500 когда происходит ошибка выполнения, т.е. в процессе выполнения скрипта возникла какая-то ошибка. Какая? Это надо смотреть в логах. Думаю, что ее вызывает какая-то из используемых в ShopCMS функций PHP, бывшая в 5.3 deprecated, а в 5.4 уже отсутствующая. А по таймауту (превышению скриптом разрешенного времени исполнения), если я не ошибаюсь, отдается какая-то другая ошибка. у меня Nginx в системе фронтенд-бэкенд отдает Request Timeout, но номер ошибки я не помню.

Но в любом случае вылет по таймауту при "положить товар в корзину" довольно маловероятен. Да и отличить просто - если ошибка сразу, то это явно не таймаут, т.к. при таймауте ошибка появится только через 30сек (дефолтовое значение времени исполнения скрипта) либо еще большее время (обычно его увеличивают до минуты-двух-трех).

[kery]

единственное кто этим занимается бадисофт когда находит ошибку он выкладывает ее в своей теме, и ему огромное за это спасибо, и он же отлично как пять пальцев знает движок, почему бы не скинуться коллективно, т.к. за любую работу нужно платить а интернет магазин это изначально коммерческое предприятие, и пусть бадисофт за оплату протестит и переведет стандартный движок на версии php 5.4+

Да бог с Вами, у меня давно есть версия ShopCMS на UTF8. Зачем тащить в светлое будущее проект на cp1251? Куда проще один раз все это переконвертить в UTF (с соответствующей подчисткой). Хотя другие переделки (та же передача параметров по ссылке, получившая новый синтаксис - символ & перед названием переменной) все равно будут нужны.
Проблема будет совсем в другом, не в движке. ShopCMS при всей своей изначальной убогости хорош наличием довольно большого бесплатного и платного модульного наполнения. На любой вкус и цвет. Мало кто использует shopCMS в голом виде, без доп. модулей. Кто будет перепиливать их? Вне зависимости, остаемся на cp1251 (проблема с функциями, поменявшими дефолтовую кодировку) или переходим на ShopCMS/UTF8 (переделка всех AJAX-запросов, т.к. больше не нужен iconv) - большинство модулей перестанут быть годными для установки.

на данный момент этот магазин умирает только потому что в стандарте он не может работать на версиях больше php 5.3, как только он в стандарте станет на новые версии, он сразу оживет. И будет новая работа для програмистов по написанию новых модулей и исправлению старых

Это не так. shopCMS по нынешним реалиям В ПРИНЦИПЕ устарел. То, что в нем делается установкой десятка модулей в современном поддерживаемом авторами или сообществом магазине есть уже изначально. Тот же Gres (просто пример, который тут уже мелькал), который бесплатен до 10 категорий и 50-ти товаров, а дальше не так уж и дорог. На уровне пары моих модулей для shopCMS, которые там уже есть штатно. Также нельзя не вспомнить вполне развивающийся OpenCart, если я правильно помню название. Он (если я не путаю) вообще на shopCMS похож почти как родной (ну, пусть двоюродный) брат. Тот же шаблонизатор, довольно похожая структура каталогов. И при этом не умер на версии 2007-го года.

Так что понятно, когда надо поддерживать уже существующий сайт. Я тоже считаю, что куда правильнее держать сайт на 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.

[straniks]

500 ошибка это вообще ошибка конфигурации сервера, как правило возникает когда время на выполнения скрипта вышло, увеличте время в директивах php.ini

Доступа к php.ini у меня нет.
Как то странно стал работать магазин. Ошибки идут по нарастающей, сегодня плюс ко всему не отправляет сообщения и заказы на почту не шлет.. Придется переходить на другой движок.. Посоветуйте не дорогой и не замороченный под конфиг моего хостера5.6.26-1~dotdeb+7.1.
Спасибо

[R.Sergey]

Придется переходить на другой движок.. Посоветуйте не дорогой и не замороченный под конфиг моего хостера5.6.26-1~dotdeb+7.1.

Лучше оплатите работу и переведем Вам движок и на utf и под 5.4 и под 5,6 и вообще под что угодно.

[straniks]

Придется переходить на другой движок.. Посоветуйте не дорогой и не замороченный под конфиг моего хостера5.6.26-1~dotdeb+7.1.

Лучше оплатите работу и переведем Вам движок и на utf и под 5.4 и под 5,6 и вообще под что угодно.

Цена вопроса?

[badisoft]

Бадисофт вот и выкладывайте рабочую инструкцию в продажу, избавит многих у кого есть интернет магазин от перехода на другую cms

А нет у меня такой готовой инструкции, есть только один из тестовых сайтов, который я перевел на utf8. Это оказалось довольно просто, коммерческого смысла не имело (мне было просто любопытно это сделать), поэтому с окончательной инструкцией я заморачиваться не стал. Ну а черновик, написанный для себя я и так уже выложил.
Если будет какой-то коммерческий интерес к созданию такой инструкции по переходу на 5.4+ версии PHP и/или UTF8, то я ее напишу. А пока не вижу смысла тратить на это время. С точки зрения программирования "для себя" задача оказалась совершенно не интересной.

[kery]

Нашел еще один косяк который надо исправить т.к. не работала настройка Доставка по странам и областям (фиксированная стоимость), это функция session_is_registered и функция session_register которая была удаленны в php 5.4
в файле functions.php находим функцию:

function xSaveData($_ID, $_Data, $_TimeControl = 0)

в ней следующий код

if (!session_is_registered('_xSAVE_DATA'))

меняем на

   //if (!session_is_registered('_xSAVE_DATA'))
	if (!isset($_SESSION['_xSAVE_DATA']))

комментируем строку

session_register('_xSAVE_DATA');

на

//session_register('_xSAVE_DATA');

и еще дополнение

1.в файле custord_subscribers.php в двух местах:
находим

				if(!session_is_registered('SUBSCRIBE_MESSAGE')){

						session_register('SUBSCRIBE_MESSAGE');
				}

меняем на

				if(isset($_SESSION['SUBSCRIBE_MESSAGE'])){

						$_SESSION['SUBSCRIBE_MESSAGE'];
				}

2. в файле affiliate_program.php
находим

				session_register('s_RefererLogin');

закоментируем

				//session_register('s_RefererLogin');

3. в файле modules.export_products.php
находим

		if(!session_is_registered('explortExpandedIDs')){

				session_register('explortExpandedIDs');
				$_SESSION['explortExpandedIDs'] = array(1=>1);
		}

меняем на

		if(isset($_SESSION['explortExpandedIDs'])){
	   		 //session_register('explortExpandedIDs');
				$_SESSION['explortExpandedIDs'] = array(1=>1);
		}

находим

		if (!session_is_registered('checkedCategories')) {

				session_register('checkedCategories');
				$_SESSION['checkedCategories'] = array();
		}

меняем на

		if(isset($_SESSION['checkedCategories'])){

				//session_register('checkedCategories');
				$_SESSION['checkedCategories'] = array();
		}

находим

		if (!session_is_registered('selectedProducts')) {

				session_register('selectedProducts');
				$_SESSION['selectedProducts'] = array();
		}

меняем на

		if(isset($_SESSION['selectedProducts'])){

				//session_register('selectedProducts');
				$_SESSION['selectedProducts'] = array();
		}

находим

		if (!session_is_registered('selectedProductsIncSub')) {

				session_register('selectedProductsIncSub');
				$_SESSION['selectedProductsIncSub'] = array();
		}

меняем на

		if(isset($_SESSION['selectedProductsIncSub'])){

				//session_register('selectedProductsIncSub');
				$_SESSION['selectedProductsIncSub'] = array();
		}

находим

		if (!session_is_registered('isExpanded')) {

				session_register('isExpanded');
				$_SESSION['isExpanded'] = array();
		}

меняем на

		if(isset($_SESSION['isExpanded'])){

				//session_register('isExpanded');
				$_SESSION['isExpanded'] = array();
		}

обновил первый пост

[badisoft]

это функция session_is_registered и функция session_register которая была удаленны в php 5.4

ИМХО, общая инструкция для НЕ КРИВОРУКИХ состоит в:
1. убираем везде & в передаче аргумента в функцию не по значению, а по ссылке. Это класс asido и еще пара мест, насколько я помню.
2. добавляем везде задание кодовой страницы в функции конвертации текста, поменявшие дефолтовую кодовую страницу с однобайтовой на UTF-8. Типа функции htmlentity и подобных.
3. Заменяем убранные в PHP 5.3 и выше функции на действующие аналогичные по смыслу.

Это 99% решения. Возможно, что-то еше вылезет - поправить по ситуации.

PS. Я это к тому, что бессмысленно публиковать простыню изменений "как сделать ShopCMS 2007-го года, сделанный под PHP 4.х работосопособным под PHP 7.0". Кто может это сделать - сделает сам. Не велика проблема. А кто не может, но владеет сайтом на ShopCMS - у того врядли дефолтовая конфигурация. Установлены какие-то дополнения, модули, частично перелопачен код. И описание изменений для дефолтовой конфиги врядли поможет. Есть лишь риск получить не работоспособную систему ни там, ни там.

[badisoft]

Написал я себе инструкцию по переводу на 5.4-5.5 и 5.6-7.0 (второе проще).
Мысли для самостоятельных:

Заменяем функцию [...] которая устарела

Куда удобнее написать свою одноименную функцию, делающую то же самое, а не править два десятка файлов.

Заменяем функцию ereg которая устарела с php 5.4

В 5.4 она стала deprecated, но работает от этого не хуже.
Удалена эта функция (и eregi) только в 7.0

//if(eregi('^(.+)<img src='http://vsupport.club/public/style_emoticons/<#EMO_DIR#>/sad.png' class='bbc_emoticon' alt=':(' />[0-9]+)$', $hosts[$index], $hostinfo))
if(preg_match('/^([^:]+)<img src='http://vsupport.club/public/style_emoticons/<#EMO_DIR#>/sad.png' class='bbc_emoticon' alt=':(' />[0-9]+)$/', $hosts[$index], $hostinfo))

eregi и ereg - разные функции.
eregi('...' преобразуется в preg_match('/.../i'

[Salp]

Перевел свой сайт mykrasa.com на php 5.6.32
После вылавливания остаточных глюков, пока полет нормальный и скорость работы немного улучшилась.
На 7.0 вообще не работает - белый экран и все. Пока не разбирался в чем дело.

[badisoft]

Перевел свой сайт mykrasa.com на php 5.6.32
После вылавливания остаточных глюков, пока полет нормальный и скорость работы немного улучшилась.

На 5.6 переводить проще, чем на 5.4 и 5.5, т.к. появилась возможность выбора дефолтовой кодовой страницы для функций преобразования строк - default_charset в php.ini или .htaccess.
Т.е. добавление 'CP1251' во все вызовы htmlspecialchars() и html_entity_decode() стало не нужно.

На 7.0 вообще не работает - белый экран и все. Пока не разбирался в чем дело.

Небось, дело в функциях ereg и eregi, которые deprecated в 5.4 и удалены в 7.0.
У меня под это дело написан deleted_functions.php:

<?php
if (!function_exists('session_unregister')) // deprecated в 5.3, убранo в 5.4
{
function session_unregister($var)
	{
	unset($_SESSION[$var]);
	return true;
	}
}

if (!function_exists('session_register')) // deprecated в 5.3, убранo в 5.4
{
function session_register($var)
	{
	$_SESSION[$var];
	return true;
	}
}

if (!function_exists('session_is_registered')) // deprecated в 5.3, убранo в 5.4
{
function session_is_registered($var)
	{
	return isset($_SESSION[$var]);
	}
}

if (!function_exists('ereg')) // deprecated в 5.4, убранo в 7.0
{
function ereg($tpl,$var)
	{
	return preg_match('/'.$tpl.'/',$var);
	}
}

if (!function_exists('eregi')) // deprecated в 5.4, убранo в 7.0
{
function eregi($tpl,$var1,$var2)
	{
	return preg_match('/'.$tpl.'/i',$var1,$var2);
	}
}
?>

PS. Глянул по теме - оказывается, я уже это писал .

[Salp]

На php 7.0, похоже, дело в init.php, пока изучаю
Для начала закомментировал в нем:

//@ini_set('display_errors',0);
//error_reporting (0);

теперь хоть что-то видно:
Parse error: syntax error, unexpected 'new' (T_NEW) in /core/classes/class.xmlnodex.php on line 65

[Robby]

На php 7.0, похоже, дело в init.php, пока изучаю
Для начала закомментировал в нем:

//@ini_set('display_errors',0);
//error_reporting (0);

теперь хоть что-то видно:
Parse error: syntax error, unexpected 'new' (T_NEW) in /core/classes/class.xmlnodex.php on line 65

$_ChildNode = &new xmlNodeX($_Name, $_Attributes, $_Data);

В PHP 7 нельзя назначать классы с символа &. Попробуйте удалить &.

[badisoft]

В PHP 7 нельзя назначать классы с символа &. Попробуйте удалить &.

Странно, что оно работало в 5.6.

2. Удаляем передачу по ссылке & (deprecated в 5.3, убранo в 5.4)

2.1. заменяем "& new" на "new" в файлах (а лучше поискать поиском)

\core\includes\processor\cart.php"
\core\includes\processor\compare.php"
\core\includes\processor\stat.php"
\fckeditor\ckfinder\core\connector\php\php4\Core\Factory.php"

2.2. заменяем "&new" на "new" в файлах (а лучше поискать поиском)

\core\classes\class.xmlnode.php
\core\classes\class.xmlnodex.php

[Salp]

Странно, что оно работало в 5.6.

Действительно странно. Да, спасибо, это я сразу исправил.
Столкнулся с основной проблемой при переходе на 7.0 это переписать всю работу с БД на mysqli

Вот здесь не все гладко т.к. mysqli_query постоянно требует параметр link, а в function db_query($s) он так просто не передается.
Да и вся структура, на мой взгляд, с mysqli должна быть другой (подсмотрел в opencart).

[badisoft]

Столкнулся с основной проблемой при переходе на 7.0 это переписать всю работу с БД на mysqli

А зачем? В 7.0 mysql уже нет вообще?

а в function db_query($s) он так просто не передается.

Первое, что пришло в голову - через define DB_LINK-а в db_connеct():
В ShopCMS база один раз открывается, если fckeditor не считать (там тоже есть работа с базой).

mysqli.php 7,07К

Я не понял, что там исправлено, кроме добавления $link в db_connect и db_query. И не увидел, где $link передается в db_query.

[Salp]

Я не понял, что там исправлено,

там было не все готово еще, думал, может подскажет кто...

А зачем? В 7.0 mysql уже нет вообще?

нет, совсем нет (((
вот, теперь как-то так:
 Снимок.JPG   137.34К   22 Количество загрузок:

и даже так:
 Снимок.JPG   91.34К   22 Количество загрузок: