[Ищу] Oxy Classifieds Доска объявлений

видимо что-то с GD Librery, иначе без проблем загружает Gif и PNG фаилы; а вот с JPEG и JPG проблемы, не загужаются вовсе
 
Привет,
есть одна проблема. У меня 6 версия доски жрёт весь ресурс CPU. - CPU usage 100%.
Поставил v.7 - тоже самое. Кто ни будь встречался с такой проблемой? Мне кажется что это глючит софт от Oxi. Пробовал на разных серверах, но везде то же самое.
Поделитесь опытом как у вас с CPU usage? Или это только у меня так получается?
 
Интерсно это только нулл или и на официальной версии такая же картинка.
Крутится скрипт в холостую на полных оборотах.
 
Такая же ерунда с ЦПУ. Скорее всего касяк в декодере пшп.
это у них такие кодеры, у меня есть с открытым кодом, ошибок тьма!!!
Забудте вы о нем, даже если все ок, там запросов в базу капец сколько при 1000 хостах напряг будет капец
 
Тестировали представленную здесь 7.05.
В принципе, достаточно шустро бегает.
VPS, 1 core, 512 Mb, 3000 Hz. nginx+phpfpm.
10 000 объявлений, 100 он-лайн пользователей.

Нашли достаточное количество багов, например, один из главных — ручной платеж (Manual Payment). При использовании ожидания поступления платежа — невозможно потом вручную активировать оплаченный счет. Всплывает белое окно, и все. В оригинале, на тестовом сайте у разработчиков (7.07) — в этом окне должны отображаться элементы, которые можно активировать по поступлению денег.
Если у кого есть идеи — буду очень благодарен. Предполагаю, что в кодированном классе оплаты - ошибка.
Возможно, ее исправили в 7.06. Если да, то было бы здорово, если бы выложили здесь зануленные патчи.
 
Не увидел в теме, возможно кому-то понадобится.
Исправление баги с отображением кириллицы в БД при выборе кодировки UTF8.
/include/vars.php
исправляем
$mysql_names = "";
на
$mysql_names = "UTF8";
После этого править все названия и тп.

Очень странно, что разработчики это упустили. Вернее, они берут настройку кодировки из глобальных настроек сервера мускуля (
character_set_server
), а не из настроек текущей БД.

Ну и переменные мускуля проверить не мешает:
Код:
show variables like '%char%';
 
Для тех, кто уже начал заполнять свою БД без исправления из предыдущего поста:
Код:
mysqldump -uuser -ppassword --default-character-set=latin1 -n -K --skip-set-charset --skip-create-options --skip-extended-insert --compatible=mysql40 --max_allowed_packet=64K dbname > latin_dump.sql
iconv -f latin1 -t UTF-8 latin_dump.sql > utf8_dump.sql
mysql --max_allowed_packet=1M -uuser -ppassword --default-character-set=utf8 database_utf8 < utf8_dump.sql
rm -f *.sql
Идея состоит в том, что мы просто создаём дамп исходной базы, при этом указывая mysqldump, что никаких деклараций CHARSET и иже с ними указывать не надо, затем скармливаем полученный дамп iconv, который преобразует весь latin1 в Для просмотра ссылки Войди или Зарегистрируйся, а затем преобразованный файл отдаём Для просмотра ссылки Войди или Зарегистрируйся (при этом указываем, что charset по умолчанию у нас utf8).


Либо, вручную, каждую таблицу:
Код:
ALTER TABLE `table_name` CONVERT TO CHARACTER SET 'utf8';

Для просмотра ссылки Войди или Зарегистрируйся
 
раз уж зашла речь про vars.php, там же обязательно выставить $mysql_locale = "ru_RU"; еще там можно отрегулировать длину тайтлов дескрипшена и кейвордов. Еще для корректной работы русского в админке settings>languages для русского языка выставить URL special characters replacement set на russian, желательно еще до начала заполнения. Также в версиях 7.0х появился интересный файлик /include/seo.php в котором можно подкорректировать правила формирования урл, ссылок (убрать дубли категорий) и метатегов.
Насчет патчей, нулить там нечего, только декодировать...
 
Если еще говорить про русский, то стоит принудительно в БД выставить регистронезависимое сравнение (_ci). Что бы поиск был корректным. А то скрипт как-то странно воспринимает Большие и маленькие буквы.

На счет $mysql_locale = "ru_RU" - спасибо. Действительно нужно.

Странно. Вроде контора скриптом давно занимается, но элементарных UTF8 фитч особенности работы - не знает.. индийцы? Не похоже. Вроде румыны или венгры...
Пробовал им вопросы на румынском писать - отвечали..

Кстати, как у кого со оптимизацией обсуждаемого скрипта?
В плане, анализировали ли работу 7.05 с базой и кэшем? На первый взгляд, кэш там примитивно устроен. Но по скорости работы — пока придирок не было особых. У кого как?

Еще нашел важную багу — логин регистрозависимый. Т.е., имена admin и Admin — разные. Если кто-то правил уже, отпишитесь, пожалуйста.
 
Люди, у кого есть работающий файлик /admin/selective_invoice_accept.php
из 7.05 или старшей версии? Поделитесь, пожалуйста.
ПС. Файл отвечает за прием платежей, например, при ручном типе оплаты. Вызывается из раздела "orders" при нажатии на иконку accept (!) — ручное подтверждение поступления средств.
В текущем дистрибутиве является, предположительно, нерабочим. Выдает "500 Internal Server Error"
 
Назад
Сверху