ViArt PHP Shoping cart

[ndmitry]

Строки 840 и ниже:..
...версия 4.0.7.

чудес не бывает, будьте внимательны или почистите кеш браузера. Там не менее 13 раз прописаны копирайты.

И еще один (прошу прощения за нуберсвто) вопрос, пользуясь FloatRates.com (корректно считает, все ок), можно ли настроить магазин так, чтобы товары были в разных валютах при занесении их в ассортимент магазина, а на фронтенде выгружались бы в одной валюте (рубли), исходя из курса?

Да. В функционале можно указать и настроить одну валюту магазина для показа пользователям и другую для размещения этих товаров в админке. Для объявлений пользователей, к примеру, ещё можно разрешить пользователям вводить цену на свои предложения в разных валютах.

...главная страница выходит в правильной кодировке. а например страница авторизации выходит в знаках вопросов...

Это из-за того, что у вас в базу данные записались не в 1251, а в другой кодировке или настройки хостинга (сервера) для страниц отдают другую кодировку. К примеру, на странице регистрации в скобках должна быть ссылка "частное лицо" или "организация" (как тип пользователя при регистрации). Это записано в БД. Поэтому если вы видите названия блоков, их заголовки и т.п. нормально, то это потому, что они берутся из языковых файлов, а не из БД. Я уже с таким не раз сталкивался. Разбирайтесь с принудительной кодировкой БД или настройками хостинга выводящими данные из БД на страницы.

...как сделать многоязычные версии описания и названия продукта? Хочу чтобы в русской версии было название на русском, а в английской - на английском. Готов вручную всё вбивать...

Языковыми тегами, это разжёвано было ещё для версии 3.6 как здесь так и на viarts.ru/

 

[starkiev]

Это из-за того, что у вас в базу данные записались не в 1251, а в другой кодировке или настройки хостинга (сервера) для страниц отдают другую кодировку. К примеру, на странице регистрации в скобках должна быть ссылка "частное лицо" или "организация" (как тип пользователя при регистрации). Это записано в БД. Поэтому если вы видите названия блоков, их заголовки и т.п. нормально, то это потому, что они берутся из языковых файлов, а не из БД. Я уже с таким не раз сталкивался. Разбирайтесь с принудительной кодировкой БД или настройками хостинга выводящими данные из БД на страницы.

спасибо за ответ! но у меня кодировка базы была utf8. Вы имеете в виду, что надо выставить её в cp-1251? Как тогда быть например с греческой версией (она мне тоже нужна). Там тоже знаки вопроса и ведь они не пропадут, если я проставлю базу в 1251? Кстати заголовки страницы создаются правильно, например для греч. языка - <meta http-equiv="Content-Type" content="text/html; charset=windows-1253" />
Хостинг кодировку принудительно не проставляет тоже..

UPDATE
Помогло такое: в корень поставил файл .htaccess со строчкой AddDefaultCharset CP-1251

языки в описании меняются по такой волшебной схеме: [en]текст на английском[/en][ru]текст на русском[/ru]

 

[ndmitry]

...у меня кодировка базы была utf8. Вы имеете в виду, что надо выставить её в cp-1251?

Если основной язык магазина русский, а особенно, если берёте локализованную русскую версию, то рекомендую базу ставить в 1251 для этого движка. Для альтарнативных языков для выбора пользователями это не повредит, потому, что для разных языков, текстов описаний товаров хранящихся в БД, как вы сами разобрались и здесь уже указывалось, используются языковые теги. все прочие надписи и сообщения сайта бурутся из языковых файлов используемых языков, а не из БД. Но раз уж вы решили проблему зайдя с другой стороны через .htaccess... Может и так можно. Просто не будет ли у вас проблемой после при экспорте-импорте? Я этого не знаю, не сталкивался и знаний мало. Я когда ставил базу в ютф-8, то во фронтенде всё корректно показывалось, а вот в базе невозможно что-либо прочитать, всё крякозябрами...

 

[starkiev]

Если основной язык магазина русский, а особенно, если берёте локализованную русскую версию, то рекомендую базу ставить в 1251 для этого движка. Для альтарнативных языков для выбора пользователями это не повредит, потому, что для разных языков, текстов описаний товаров хранящихся в БД, как вы сами разобрались и здесь уже указывалось, используются языковые теги. все прочие надписи и сообщения сайта бурутся из языковых файлов используемых языков, а не из БД. Но раз уж вы решили проблему зайдя с другой стороны через .htaccess... Может и так можно. Просто не будет ли у вас проблемой после при экспорте-импорте? Я этого не знаю, не сталкивался и знаний мало. Я когда ставил базу в ютф-8, то во фронтенде всё корректно показывалось, а вот в базе невозможно что-либо прочитать, всё крякозябрами...

да, проверил, у меня в базе все нелатинские символы записаны в html-кодах. Но вроде бы проблем с функционированием нет. На самом деле я уже сталкивался с проблемой, когда один из движков разрабы решили перевести в ютф и вот там была проблема с перекодировкой баз при апгрейде. Так что лучше сразу начинать работать в ютф, такое мое скромное мнение.

У меня возник другой вопрос, сори если ламерский. Можно ли в виарте организовать такой механизм:
Я хотел бы сделать молл, где товары структурировалсь по названию. Скажем, есть телефон Нокиа Н80, так пусть при нажатии на него будут отображены все продавцы, которые его предлагают.
Не нашел такой опции, она возможна?

 

[Abdalballah]

чудес не бывает, будьте внимательны или почистите кеш браузера. Там не менее 13 раз прописаны копирайты.

Спасибо, вы правы.
Даже больше, они теперь их "перемножают". Проще всего присвоить какое-нибудь ничего переменной строка 941

$Z9N3 .= "</div></center>&nbsp;";
	$Z9N3 = "";

А можно поддержать их игру и составить свою матрицу

 

[Abdalballah]

Да. В функционале можно указать и настроить одну валюту магазина для показа пользователям и другую для размещения этих товаров в админке. Для объявлений пользователей, к примеру, ещё можно разрешить пользователям вводить цену на свои предложения в разных валютах.

Рубль я рокировал с долларом, чтобы на фронтенде по умолчанию все выгружалось в национальной валюте, убрав возможность ее выбирать для конечного пользователя. Все валюты активны:

Но в карточке товара все, что мне доступно, это поставить цену в валюте по умолчанию:

Я что-то недоглядел?

 

[ndmitry]

Abdalballah, я невнимательно прочёл ваш вопрос. Размещать товары в админке в разных валютах в текущей версии нельзя, пока в 4-ке это сделали возможным только для объявлений, но не для товаров.

 

[khamiss]

could anyone do have the nulled ver for Viart 4.0.7 enterprise edition
very urgent

 

[EugeneX9]

Ошибка в модуле "Производители" напрочь убивающая производительность

В block_manufacturers.php в 4.06 foreach ($manufacturers AS $manufacturer) {
$manufacturers - все производители, в этом цикле происходит поиск производителей, изделия которых есть для данной категории. В цикле для каждого производителя выполняется один sql запрос вида:
SELECT i.item_id FROM (( va_items i INNER JOIN va_items_categories ic ON ic.item_id=i.item_id) INNER JOIN va_categories c ON ic.category_id=c.category_id) WHERE i.is_showing=1 AND i.is_approved=1 AND ((i.hide_out_of_stock=1 AND i.stock_level > 0) OR i.hide_out_of_stock=0 OR i.hide_out_of_stock IS NULL) AND (i.language_code IS NULL OR i.language_code='' OR i.language_code='ru') AND i.sites_all=1 AND i.guest_access_level&2 AND (c.category_id=50 OR c.category_path LIKE '%0,49,50,%') AND i.manufacturer_id=70;
Если к примеру в магазине 150 производителей, то при нажатии категории с товарами или выборе страницы выполнится 150 таких запросов.
Естественно по "производительности" magento нервно курит в сторонке. Если убрать столь злополучный фильтр, магазин начинает летать.
Интересно какой школьник сие написал.
Сия глупость есть как в 3.* так и в 4.*

 

[IEVteam]

В block_manufacturers.php в 4.06 foreach ($manufacturers AS $manufacturer) {
$manufacturers - все производители, в этом цикле происходит поиск производителей, изделия которых есть для данной категории. В цикле для каждого производителя выполняется один sql запрос вида:
SELECT i.item_id FROM (( va_items i INNER JOIN va_items_categories ic ON ic.item_id=i.item_id) INNER JOIN va_categories c ON ic.category_id=c.category_id) WHERE i.is_showing=1 AND i.is_approved=1 AND ((i.hide_out_of_stock=1 AND i.stock_level > 0) OR i.hide_out_of_stock=0 OR i.hide_out_of_stock IS NULL) AND (i.language_code IS NULL OR i.language_code='' OR i.language_code='ru') AND i.sites_all=1 AND i.guest_access_level&2 AND (c.category_id=50 OR c.category_path LIKE '%0,49,50,%') AND i.manufacturer_id=70;
Если к примеру в магазине 150 производителей, то при нажатии категории с товарами или выборе страницы выполнится 150 таких запросов.
Естественно по "производительности" magento нервно курит в сторонке. Если убрать столь злополучный фильтр, магазин начинает летать.
Интересно какой школьник сие написал.
Сия глупость есть как в 3.* так и в 4.*

С Вами соглашусь и скажу, что многие вещи в этом скрипте реализованы немного странно, что сильно влияет на работоспособность в целом. Как пример: год назад мой аккаунт на виртуальном хостинге заблокировали, из-за того, что скрипт давал сильную нагрузку на сервер. Как выяснилось позже, причина всему этому - это: неправильная обработка графики (именно изображений товаров и вспомогательных сервисных иконок) через стили CSS, работа фильтров и отображения товаров в каталоге (products.php) - конечно пришлось немного "поработать напильником" над скриптом и перейти на другого хостера. P.S. В этом топике много полезных рекомендаций к скрипту от людей, которые имеют непосредственное отношение к продукту компании Viart, плохо лишь то, что все это не выписано в общий FAQ.