UncleAndy

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

Ну, естественно, я не собираюсь все переносить автоматически. Естественно, я буду смотреть логику. И, кстати, когда разбирал структуру базы был удивлен небольшим количеством индексов. Как пишет alexxxus, поля типа "*_id", по идее, обязаны иметь индекс т.к. служат для связи между таблицами. А если это кроме моих "теоритических" предположений еще и подтверждается на большой базе, я просто не вижу что здесь обсуждать (вернее, что обсудить - есть всегда, просто в данном конкретном случае мне кажеться все очевидным).

Если их "от балды" понаставлено на все поля - да. В данном случае это все-таки оптимизация, т.к. делается по реальной ситуации которую она улучшила.

ПЛИИИЗЗЗ!!! Напишите какие поля в каких таблицах индексировали! Мы их просто добавим в БД что-бы всем было хорошо. :) Ну или если в лом - хотя-бы дамп структуры базы данных. :)

aVadim, добро пожаловать! :) У меня такая-же ситуация. Выбрал этот движок как основной для установки магазинов клиентам. И начал допиливать. Основное что я хотел я сделал - адаптировал SQL запросы для использования Postgresql и сделал драйвер БД для этого и добавил возможности кэширования (в ближайшее время добавлю кэширование в драйвер Postgresql). Кроме того, исправил несколько небольших проблем в функционале. В принципе, правка SQL - это тоже большое изменение. Но, то что ты предлагаешь (по поводу строк) очень плохо из-за того что надо править шаблоны. И выложенные в куче мест шаблоны для OpenCart "из коробки" не будут работать. Меня тоже много что коробит в коде. Но я давно понял, что то что удобно программисту может быть плохо либо пользователю либо серверу (падает скорость, жрется память и т.д.). В твоем случае я пока вижу что для каждого процесса будет грузится вся языковая база. Это плохо с точки зрения памяти. Я считаю что такое изменение излишним, т.к. оно дает только удобство программисту и непонятно как влияет на расход памяти. Но, думаю, нам всем, в любом случае, интересно какие еще доработки вы используете.

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

По всем файлам в каталоге магазина. Если вы не в курсе - существует групповой поиск строк по файлам.

Тут явно где-то испортили упоминание page. Попробуйте поиск среди файлов по "ge или 'ge

Ссылку, плиз.

Yesvik-у, как автору изменения написал. Будем исправлять.

Yesvik, нужна твоя помощь с устранением глюка. Ситуация: 1. Включаем SEO-URL с твоими правками. 2. В одной из категеорий (с большим количеством товара) оставляем элиас пустым. 3. Идем в эту категорию и обнаруживаем отсуствие листания по страницам. Поправь, плиз и скинь мне изменения.

Так. Что-то я не понял. Вот здесь SEO выключен и листание не работает. Причем, как-то крайне странно. При наведении мышки на ссылку видно что ссылка нормальная - с page=2. Но при клике на ней в ссылке исчезает параметр page. Чудеса.

Можно где-то посмотреть?

Спасибо. В SVN поправил. Это последствие подгонки SQL запросов для использования Postgresql. Объемы были большие - мог где-то что-то не так сделать. Большую часть функционала проверял, а вот добавление магазина как-то пропустил.

Человек только-что узнал о существовании Open Source. :)

Я ответил на счет ежедневных обновлений. На счет автоматитческой конвертации не в курсе, т.к. просто с этим не сталкивался.

Не далее как вчера поправил небольшой глюк в этом модуле. Курсы обновляются автоматически 1 раз в сутки.

Попробовал поставить - остановился на правке html. Слишкам многа букаф, сорри.

Телепаты у нас обычно в отпуске. Версия движка какая? Внесены-ли изменения которые здесь упомянуты?

Этот патчь специально для ocStore или на OpenCart поставится?

Проверьте. Почистите лог, сходите на страницу статистики и посмотрите лог.

Там код простейший. Единственное что возможно - что функция PHP не возвращает в массиве значения bits. Я вижу только две возможные причины - изменение версии PHP или картинки для которых эта функция не возвращает данного значения (либо битый файл картинки).

И на другой сервер? "For some image types, the presence of channels and bits values can be a bit confusing. As an example, GIF always uses 3 channels per pixel, but the number of bits per pixel cannot be calculated for an animated GIF with a global color table." Картинки точно не менялись? Может вы используете какие-то анимированные гифки а раньше просто не замечали этой проблемы?

Тогда вряд-ли. Если-бы вы использовали драйвер БД mysql_cached, вероятно вы это знали-бы. Тогда рекомендую смотреть логи ошибок в админке и на сервере.

Вы случайно кэширование SQL запросов в админке не включили? :) А то у меня такой-же эффект был когда я эксперементировал с кэшированием. :)