Nelexis

Как-бы да, сейчас поставь заказчику низкую цену и получи еще "а сделай мне еще это, это ведь не сложно...". У меня один такой проект вырос раза в два, правда он не на престе, а на фреймворке, да и обещают прилично доплатить =) Но это в будущем, а работа сейчас. Более высокая оплата сразу заставляет заказчика обдумывать на сколько ему нужно то, или иное.

O_o фига себе. Вопрос, нафига делать подпись разрешенной после такого количества лайков если в ней нельзя размещать ссылку? Хотят чтоб народ суетился, он будет, но за плюшки. Нет плюшек? Тут оч. не мало как-раз тех кто готов добавлять разумные комментарии(и именно это подтверждается лайком) в обмен на то что его пост ему принесет +1 одну ссылку на его сайт/форум/блог. Считаю это достаточно малой ценой за разумную адекватную информацию. По поводу всего прочего это просто разгильдяйство. Более того эти сайты/блоги/форумы посвящены скорее всего снова же престе. А значит продвигают ключ PrestaShop по категории e-commerce. Что снова же приносит плоды самому форуму и сайту. Сама сертификация не понадобиться аж до тех пор, пока русскоязычная ниша не заполниться хотя бы теми кто готов выполнять работы по престе. Пока таких людей мало, никто не будет влаживать 1000 зелени в не приносящее ничего полезного. А вот тут возвращаемся как-раз таки к тому что чтобы ниша рынка заполнилась и приносила по 1000 долларов за сертификацию раз в год, нужно чтобы народ продвигал престу в массы, а значит давал поддержку на форуме за плюшки в виде ссылок в каждом из своих постов. Возвращаемся к вопрос, "кто плюнул себе в лицо?" в данном случае. Если моя логика абсолютно верна в данном случае, было бы неплохо чтобы модераторы обсудили этот вопрос между собой и решили, либо форум для людей, либо они сами отвечают пользователям на все их вопросы, форум по тихоньку шкандыбает, а преста не растет в массах с такими темпами как могла бы.

По всей видимости в шаблон темы. В файл ответственный за вывод товаров в категории. Обычно он находиться в /themes/ваша_тема/ Если я правильно на вскидку понял то это файл product-list.tpl в теме default. P.S. После редактирования шаблона не забудьте сбросить кеш smarty.

Как вариант просмотреть файл: /classes/Search.php Там в основном регулярные выражения. Найти то из-за которого поиск только по цифрам игнорируется. Скопирнуть код в файл перекрывающий(override) этот контроллер и изменить код на нужный.

Для этого все-равно нужен PHP. Как я понял по условию, условно доступ есть только к базе данных. Выполнить эту задачу средствами SQL не представляется возможным.

В базе или нет, какая разница? Картинки у категорий есть и они хранятся в папке /img/c/, только что проверил загрузив категории картинку через админ. панель. Хранятся они там в виде файлов: id_category.jpg id_category-шаблон_изображения.jpg Шаблоны изображений хранятся в таблице __DB_PREFIX__image_type, вместе с размерами. Вот и проверьте есть ли у всех. Сделайте выборку всех категорий и проверьте наличие файлов им соответствующих в папке. Ну а отчет уже выводите либо в текстовый файл, либо сразу в окно, либо каким-то другим методом. Это уже от ваших личных предпочтений зависит.

@martyniuk Варианты 1) Повышать плюшки 2) Попробовать заказать у конторы 3) Искать пока не найдется. 4) Научится и сделать самому. 5) Вы.... все мозги где-то найденному крутому программеру пока тот не согласится, лишь бы вы от... 6) Забить. 7) ... Выбирайте тот где ваши возможности совпадают с желанием. )))

martyniuk, на счет PHP уже не те времена, когда PHP и за язык не считался. Сейчас кроме PHP нужно знать, хотя бы для той же престы еще Smarty, JS, JQuery, MySQL, HTML(5), CSS, Нормализацию баз данных, API самой престы и некоторые мелочи. Те у кого есть такой уровень уже пасутся где-то на других задачах, коих уверен что хватает. А сюда поглядывают то ли по быстрому кому-то что-то подлатать и копейку сорвать, либо посоветовать, либо что-то интересное сделать, либо новости узнать. Как собственно и я. Работу чуток на других сайтах предлагают, а здесь больше уже сами разработчики подсказок просят.=)

С ув. к Вам, не подумайте что обидеть хочу или еще чего... Я конечно не знаю как долго и качественно работает absent, но и модули что вы запросили не столь простые чтобы сделать на коленке за пол часа. Тем более если уж Вы собрались подбирать людей, вы же должны как-то понимать на сколько сложное/легкое задание даете и сколько реальный срок его разработки. Потому, как и написал savvato, больше никто и не списался с вами кроме абсента, что задание достаточно геморное, а из плюшек ничего не описано. Возможно человек реально на какой-то стадии разработки, пусть и не на финишной, не будет же он за каждый чих отписываться. Но это его и ваши проблемы. Есть у программеров такая привычка ошибаться со сроками. Сейчас с ним поругаетесь, будете искать еще пол года кого-нибудь )) ИМХО.

Да, многовато. Это без кеширования и с постоянной перекомпиляцией шаблонов. С кешированием еще не проверял. Но в любом случае еще есть над чем работать.

Да, Вы правы, что-то закралось у меня такое неправильное ощущение что smarty работает с той же скоростью что и php. Хотя там был уже сформированный массив, смарти нужно было лишь все это в цикле вывести. Так же нашел ошибку в собственном SQL запросе, из-за чего получал массив намного больше чем должен был. Моя невнимательность. В итоге без кеширования с фильтрами все страницы грузятся не более чем за 2 секунды. Вопрос исчерпан. =)

Эм... Проверял я это на связке Nginx+Php-fpm+memcached вообще-то, на локалхосте под Debian GNU\Linux, с 3 ГБ ОЗУ из которых у PHP лимит в 512. Вся суть в том что мне нужно динамически формировать список фильтров по аттрибутам, а не выбирать в админке. И суть в другом, без цикла что я написал выше, но с выборкой всех нужных данных из базы панель отладки показывает такие результаты: Load time: 2.631s You'd better run your shop on a toaster config: 86ms constructor: 0ms init: 28ms checkAccess: 0ms setMedia: 2ms postProcess: 0ms initHeader: 1ms initContent: 1.976s initFooter: 0ms display: 537ms С циклом который я привел выше, то есть по сути просто построение ul списка, на той же категории производительность существенно отличается. То есть единственная разница между тем и тем результатом это проход смарти по массиву. Load time: 15.179s You'd better run your shop on a toaster config: 74ms constructor: 0ms init: 33ms checkAccess: 0ms setMedia: 3ms postProcess: 0ms initHeader: 1ms initContent: 2.044s initFooter: 1ms display: 13.022s Уважаемый, мне как бы не до тролинга. У меня тут таки реальная пробелмка. Вот смотрю куда копать. Думал может кто сталкивался уже или где я чего не так сделал(хотя что удивительного в таком цикле? O_o) К слову версия престы 1.5.5

Вот собственно вывод дебагера: Load time: 27.702s You'd better run your shop on a toaster config: 263ms constructor: 0ms init: 74ms checkAccess: 0ms setMedia: 9ms postProcess: 0ms initHeader: 5ms initContent: 7.614s initFooter: 1ms display: 19.738s И в тоже время тот кусок кода в смарти который так тормозит: {foreach $attributes as $id=>$attribute} <tr> <td> <h3>{$attribute.name}</h3> <ul> {foreach $attribute.values as $value} <li><input type="checkbox" name="a[{$id}]" value="{$value}">{$value}</li> {/foreach} </ul> </td> </tr> {/foreach} Родительский массив 3 элемента. Дочерних по несколько десятков. Но я все-таки не понимаю из-за чего столь долгое время идет на построение шаблона. Использую Smarty 3 на других проектах, вместе с фреймворками, естественно на этапе разработки кеширование представлений отключаю, но и таким образом оно на много производительнее. Кто разбирался, может подскажете суть? Ну если сам докопаюсь то отпишусь.

В любой новой задаче, которой вы учитесь, вам не будет хватать опыта. А такие есть всегда. У вас есть задача(цель) и вам ее нужно решить. Все остальное лишь оправдания. Дорогу осилит идущий. ;-)

Там как бы не столь сложно, сколько ресурсоемко. Последовательность действий опишу приблизительно: 1) Получаете ID текущей категории. 2) Делаете выборку id_category, id_parent_category из prefix_category. 3) В массиве циклом перебираете все подкатегории данной категории и их подкатегории, закидываете в список через "," 4) Делаете выборку count(*) по товарам "SELECT count(*) from prefix_product IN ($строка_с_айди_категорий_из_п_3)", в итоге получив заветное число. Вот приблизительно такая логика. Возможно не самый лучший вариант, но лучше я чет пока не вижу. Вам остается реализовать.