Baco

поддерживаю

Тоже могу поддержать, только без читерства...

Я б вообще то предложил, командно против престашоп или магентовцев выступить, но это так... при условии, что есть игроки под анриал или на кваке подкованы...

Unreal Tournament 99

+ нет возврата линка, если у товара не прописан url, но с другой стороны - стимул его прописывать или генерировать...

С поиском увидел трабл, попробую на днях пофиксить + добавить "отсебятину" соотв. отпишу решение тут.

Спасибо за мульти-сео-контроллер.

Достойное решение, плюс однозначно...

Из багов, нашел только одно:

function getAlterLanguageLinks

возвращает префикс языка, даже при условии, что:

$this->config->get('ocjazz_seopro_hide_default') == true

как решение, не могу форкнуть на гите, посему пишу сюда:

if($lang['status']) {

прописать на доп. условие типа:

if($lang['status'] ) {
	if($this->config->get('ocjazz_seopro_hide_default') == 1 && $lang['code'] != $this->config->get('config_language')) {

а то щас получается в админке выбрано: 

а в магазине показаны оба языка с префиксом:

В OcShop есть встроенный модуль Блог. Выводить нужно краткое описание статьи, ссылку на статью и изображение, поиск должен проходить по названию и тексту статьи.

Так а чего вы к автору OcShop не пишите такие вопросы ?

Наверное блоки со статьями (href_information_id, name||title, image_if_isset, short_description) как то так, а вместо кнопки купить - перейти в статью... 

Это не смотрели ?

Сделать условие на проверку кол-ва по определённому товару (product_id != key) в сесии (корзине)

Спасибо всем, тема закрыта))) :-)  :-)  :-)

Решение в студию (если оно бесплатным было), что бы другой такой искатель, смог вместо "задать вопрос" взять "решение".

мне нравится политика opencart.com

IMHO, там монархия.

А с чего вы взяли, что должно что то генерироваться ?

catalog\view\javascript\common.js

/* Search */
	$('.button-search').bind('click', function() {
		url = $('base').attr('href') + 'index.php?route=product/search';
				 
		var search = $('input[name=\'search\']').attr('value');
		
		if (search) {
			url += '&search=' + encodeURIComponent(search);
		}
		
		location = url;
	});
	
	$('#header input[name=\'search\']').bind('keydown', function(e) {
		if (e.keyCode == 13) {
			url = $('base').attr('href') + 'index.php?route=product/search';
			 
			var search = $('input[name=\'search\']').attr('value');
			
			if (search) {
				url += '&search=' + encodeURIComponent(search);
			}
			
			location = url;
		}
	});

seo_pro - это контроллер, который кушает index.php?route= и выдает адекватный урл, при условии что он был записан ранее в базу, при редактировании товара, категории, статьи... Он не имеет никакого отношения к генерированию УРЛ-ов !

Во первых, определитесь какая тема по сути.
Во вторых, дайте ссылку на сайт, где это можно на примере просмотреть.
В третьих, циклические ссылки вы хотите убрать, начиная с активной подкатегории ?
 
Если 3-й вопрос актуален, то для этого надо найти такой вид переменных:

<?php if ($category['active']) { ?>
	<a href="<?php echo $category['href']; ?>" class="active"><?php echo $category['name']; ?></a>
<?php } else { ?>
	<a href="<?php echo $category['href']; ?>"><?php echo $category['name']; ?></a>
<?php } ?>

и превести к такому:

<?php if ($category['active']) { ?>
	<b><?php echo $category['name']; ?></b>
<?php } else { ?>
	<a href="<?php echo $category['href']; ?>"><?php echo $category['name']; ?></a>
<?php } ?>

Если же рассматривать боковой модуль (вертикальное меню), то следует найти:

<?php if ($category['category_id'] == $category_id) { ?>
        <a href="<?php echo $category['href']; ?>" class="active"><?php echo $category['name']; ?></a>
<?php } else { ?>
        <a href="<?php echo $category['href']; ?>"><?php echo $category['name']; ?></a>
<?php } ?>

и поменять на:

<?php if ($category['category_id'] == $category_id) { ?>
        <b><?php echo $category['name']; ?></b>
<?php } else { ?>
        <a href="<?php echo $category['href']; ?>"><?php echo $category['name']; ?></a>
<?php } ?>

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

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

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

Кроме высокой степени доверия, должен быть так же уровень знаний в модулестроении, уязвимостях, быть более - менее вкурсе дополнений, которые актуальны на рынке и... иметь доступ к раскодированным данным (если модуль закодирован) что бы проверить наличие "дыр". 

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

9 строка:

$this->db->query("UPDATE " . DB_PREFIX . "product SET date_modified = NOW() WHERE product_id = '" . (int)$product_id . "'");

Насколько я вижу оригинальный код, то там нет ниодной строки, которая затрагивала бы таблицу product, исходя из этого утверждения, напрашиваются 2 вывода:

1. Либо у вас какой то модификатор (vqmod файл) вносит неправильные изменения или по неправильному пути...

2. Либо у вас были раньше криворукие исполнители, которые решили впихнуть невпихуемое...

Решение:

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

Выделить человека, который будет взаимодействовать с разработчиками, держать обратную связь с лагом в 1-3 рабочих дня максимум.

Человек на альтруистических побуждениях или какая то мотивация из 16% общака должна быть этого человека ?

(если можно, распишите детально, а то одним предложением сложно что то передать)

Покажите, что находится в 9-й строке файла: vqmod/vqcache/vq2-admin_model_catalog_category.php

2 freelancer:

доверие к пользователям с такими проблемами (варезный  response.php) резко падает

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

2 tabook:

Есть ли конструктивные предложения, касательно ?

Произвести пересмотр политики взаимодействия администрации с разработчиками

Вот он же.

Понятно, диагноз первоначальный - установлен, панацея:

1. Отключить и вырезать по всем контроллерам, любые упоминания о product_total (если конечно вам не принципиален вывод кол-ва товаров в категориях).

2. Убрать ненужные подзапросы (например выборку из таблицы product_to_store), а-ля оптимизировать запросы.

3. Сделать по возможности аякс подгрузку дочерних элементов.

4. Проанализировать другие модификаторы, не влияют ли они на "замедление".

Примерное время выполнения - 3 часа., расценки по времени вы найдёте в профиле, хотя можно задать вопросы на форуме и самостоятельно попробывать реализовать "лечение пациента".

Доктору нужно диагноз поставить, может ли ваш хостинг предоставить low_query.log ?

А то искать место самостоятельно разве "знахарь" сможет, а это по времени долговато, соотв. и по затратам.

Вот 3-й пункт интересный, но реализация его под IPB у грамотного специалиста, по бюджету будет не маленькой.

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

Проблема в подгрузке модели фильтра + по остальным ошибкам - отсутствие переменных, которые необходимы при выполнении запроса в базу, как идентификатор.

Сильные же тормаза сайта повязанны с неоптимизированными запросами в базу, отсутствием кеширования распостранённых данных, возможно лишней выборкой кол-ва элементов для родительских категорий (товаров, подкатегорий), сходу сказать сложно что является причиной, анализировать необходимо, как совет - используйте "ускорители" или "кешеры", если у вас много товаров (более 10-15 тыс.) ну и конечно же найдите специалиста, по устранению данного недуга, так как по практике, то торможение сайта, влечет за собой нагрузку на сервер , что в результате может привести к "бану" со стороны хостинга и отключению вашего сайта за превышение лимитов.