sv2109

Сегодня кто-то отметил файл как поврежденный, потому что: " Файл отмечен как поврежденный, потому что: Ne vozmogno oplatit fajl Pri nagatii knopki oplatit poyavlyaetsya nadpis Oshibka i t.d. Hotya segodnya i sejchas prodolgayu preobretat moduli " Проблема присутствует! + мне пришло на почту: "Это уведомление о том, что ваш файл 'Group Price - Разные цены для разных групп покупателей + быстрое изменение цены в базе' был помечен как поврежденный. Это сообщение сгенерировано автоматически. Никаких действий от вас сейчас не требуется. Наши модераторы проверят жалобу и примут соответствующее решение." При этом сообщение о поврежденном файле есть на странице модуля. Значит ли это что его уже проверили и приняли решение разместить сообщение на странице?

Сделал версию для OcStore 1.5.4.1, на сайт пока не выкладываю, кому нужна эта версия - пишите в ЛС В дальнейшем планирую полностью переделать поиск, поменять алгоритм, добавить новых настроек в админку и оптимизировать поиск для работы с большим к-вом товаров.

есть, сегодня доделал, но нужен еще день-два для тестов

Подскажу, зайти в гугл и вбить туда текст этой ошибки, можно в конце дописать site:ru, и посмотреть что это за ошибка, когда она появляется и как от нее избавится.

Да Но только что посмотрел код, проверка на наличие файла там присутствует: if (file_exists($file)) { unlink($file); } Замените на if (file_exists($file)) { @unlink($file); } Но если есть проверка то мне не понятно почему показывается ошибка что файл не найден если по логике функция unlink должна вызываться только тогда когда файл есть! Неужели 2 процесса почти одновременно запускают очистку того-же кеша (например сайт с большой посещаемостью)? Тогда проверка на наличие вернет true, файл удалит другой процесс и unlink выдаст ошибку что файла нету.

А файл cache.product.total.1.0.1.e6d0712475f2132e.1357157041 вообще существует? Посмотрите в папке кеша. Если существует то посмотрите права доступа на сам файл, возможно права доступа на сам файл неправильно выставляются при создании. Если не существует то кто-то этот файл уже удалил раньше и команда unlink выдает предупреждение что такой файл не найден. Попробуйте перед unlik поставить символ @ это должно подавить вывод ошибки если файла не будет. Или добавить проверку перед удалением if (file_exists(имя файла)) { удаляем этот файл}

проверю, отпишу нет

Пришло сегодня от клиента "Не могу купить Ваш модуль Group Price - Разные цены для разных групп покупателей + быстрое изменение цены в базе 1.4. при покупке выскакивает ошибка [#12345] An error occurred while trying to generate your invoice. Please try again or contact an administrator. (TITLE_TOO_LONG)." Исходя из ошибки проблема в слишком длинном названии модуля - "Group Price - Разные цены для разных групп покупателей + быстрое изменение цены в базе" То есть нужно или при сохранении страницы с модулем не давать сохранять длинные названия или убрать это ограничение при покупке.

Скажу что называть переменные $fucking_shit это очень непрофессионально, даже если эта переменная используется для примера. Название переменной должно говорить о содержании этой переменной, такой код намного легче читать и поддерживать. А по сабжу.. с одной стороны это не правильно - логика в шаблоне, лучше конечно поменять языковый файл. НО любой кто занимался поддержкой модулей знает сколько проблем для разработчика доставляют такие вещи.. даже если в инструкции будет четко указано что где и как нужно поменять.. все равно найдется 100500 ламеров которые это или не прочитают или не поймут или где-то накосячат, после чего будут терроризировать разработчика что у "У меня ничего не работает". И в данном случае имхо лучше добавить 1 регулярку в шаблон и избавить себя от этих вопросов. Правда регулярку я бы подправил - зачем отделять протокол от урла, а потом в коде его обратно собирать, не проще ли вытянуть сразу все? + те скобки, что не используются потом лучше писать так ( :?) тогда они не попадают в массив $well_done и код стает более читабельным. $well_done я бы тоже поменял название из него не понятно что в переменной + добавить комментарии чтобы было понятно что эта регулярка делает и для чего она нужна так как с ходу даже человек знакомый с регулярными выражениями не поймет что она делает, а незнакомый вообще будет в шоке от увиденного.. например какой-то верстальщик, который шаблон откроет)) Будет так - http://anongallery.o...-cant-sleep.jpg )))

Это не правильно.. Потому что невозможно! в админку запихнуть абсолютно все настройки, которые возможно сделать средствами css и html. Это способ для ленивых пользователей сделать что-то ничего не умея. А потом зайти на форум и задать 100500 вопросов "А как..?" Плюс эти темы идут с отдельными модулями, для их работы нужно изменить кучу кода движка (см. шопику), имеют очень сложную структуру с кучей условий так как все формируется динамически из настроек и в следствии чего работают медленнее обычных тем. И все для того, чтобы не добавлять пару строк в css или html? Это знания которые можно получить за 3 дня пройдя какой-то онлайн курс - html для чайников..

Над версией для 1.5.4.1 сейчас работаю. Без vqmod версии нету. Так как без vqmod в опенкарте мало что можно сделать, привыкайте. Или вы используете vqmod, или вносите изменения вручную в файлы (можно открыть vqmod файл и посмотреть куда и что он добавляет, там всего 2-3 строчки кода нужно изменить)

Опишите проблему более подробно. Где именно у вас что не работает - в каком модуле и что именно не работает. Так как модуля 2 то с вашего сообщения не понятно.

Мне создало просто архив с структурой каталогов и пустыми файлами внутри. Так и должно быть? Если да то пользы от этого "генератора" почти никакой. Вот если бы эти файлы были не пустыми а уже заполненными какими-то данными, например как уже предлагалось выше добавить названия классов и методов, в контроллерах подключение языковых фалов, моделей, рендеринг, присвоение языковых переменных (в идеале должна быть форма с возможностью внести эти переменные и чтобы потом они автоматом добавились в контроллеры и языковые файлы), вилидацией, сохранением настроек итд. Сделать админ часть с возможность из формы выбрать например "добавить форму выбора схемы" и чтобы после этого автоматом сгенерировался темплейт. Или добавить табы, таблицу итд. То есть автоматизировать максимум рутинной работы. Вот тогда такой генератор был бы реально полезен, так как сэкономил бы кучу времени. А то на все эти настройки в админке, языковые переменные итд иногда пол дня уходит все прописать, проверить, выловить все баги.

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

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

Тут нужно еще правильно разделить баги. Баг багу рознь. Например есть ошибка самого скрипта, когда не работает заявленный функционал, модуль глючит, работает не стабильно, это одно. И есть ошибки, возникающие из-за неправильной установки модуля или из-за того, что модуль конфликтует из другим модулем или темой или уставлен не на ту версию движка итд. В первом случае, считаю, что автор обязан или помочь покупателю в адекватные строки (например 1-5 дней) или вернуть деньги + также обязан помочь в настройке модуля, если с модулем не идет нормальная документация, где это разжевано. Во втором случае автор не обязан делать это. Тем более бесплатно. Он может (но не обязан) это сделать бесплатно, если например видит, что его модуль конфликтует с другим очень популярным модулем, который установлен у многих пользователей. Или может (но не обязан) сделать за деньги. Но в любом случае не нужно забывать об самой элементарной вежливости и хамить покупателю в ответ на какие-то претензии (даже не обоснованные) тоже нельзя. Решается просто - не 500 р., а например 10 уе в час. Тогда по мелочам писать не будут, а все остальное оплачивается согласно тарифу. Хочет заказчик приделать танцующего медведя.. без проблем, но это будет стоить .. ххх денег. Но тут есть одно большое преимущество для клиента - он будет уверен, что этот модуль или эта тема по любому у него заработает, пусть даже придется немного доплатить.

Хочу поднять один, как мне кажется, очень важный вопрос. Для меня это было очевидным, но видимо реальность далеко не всегда соответствует ожиданиям. Все началось с одной темы - которую выложили больше месяца назад. В теме я нашел кучу откровенных багов - например на странице товара слово "Теги: " показывалось независимо от того есть там теги или их нет, корзина открывалась с какими-то рывками, другие пользователи, купившие эту тему подтвердили эти баги + нашли и другие, например поиск вообще не работал, потому что автор темы не добавил в шаблон поиска код отвечающий за вывод результатов поиска.. И так далее. Целый месяц пользователи, купившие тему, отчаянно пытались связаться с автором, который откровенно забил на поддержку, отписал в теме, что вся поддержка ведется на его сайте, но по словах пользователей и на его сайте ответов они не получили.. Когда ситуация накалилась до предела, пользователи устали самостоятельно выпиливать баги из темы и начали на мой взгляд абсолютно справедливо требовать возврата денег, написали администрации форума. Только после того, как запахло жаренным, автор темы соизволил зайти в тему.. Нет, никаких извинений от него не последовало, вместо этого он во всех грехах начал обвинять именно пользователей, что это из-за их криворукости его тема не хочет работать.. и денег отдавать он никому не собирается. А эти незначительные баги будут исправлены в какой-то следующей версии.. После переписки с представителем администрации, пользователем afwollis получил некоторые ответы на свои вопросы на тему "обязан ли автор оказывать поддержку Мнение еще одного администратора То есть администрация считает что это абсолютно нормально когда автор темы или модуля не оказывает никакой поддержки и целый месяц не исправляет откровенные баги в своем платном (и недешевом) продукте. Собственно основной вопрос - "Обязан ли автор дополнения заниматься поддеркой своего продукта?" Под поддержкой я понимаю в первую очередь исправление багов, помощь в установке, настройке. И 2 подвопроса: 2.1 - "В какой строк разработчик должен реагировть на баг репорты" (автор темы не реагировал целый месяц и по мнению администрации это нормально, тогда сколько ненормально?) 2.2 - "Где должна осуществляться поддержка? Правильно отсылать пользователей за поддержкой на какой-то левый сайт?"

Почему это за копейки? К вам приходит заказчик и вы называете свою цену, например 10$ в час, работа займет 5 часов и будет стоить 50$ Заказчик платит вам 50$ и получает решение своей задачи. А потом на следующий день заходит на форум и видит, что это решение выложено в платных модулях и любой, включая его конкурентов может купить его за 100 рублей. Справедливо ли это? Вопрос не только в идее. Вопрос в том, что заказчик заплатил за работу! И заплатил далеко не копейки а именно ту сумму, которую ему назвал программист.

Чисто по человечески наверное вы правы и вас можно понять. Но по закону, если с разработчиком не подписан договор согласно которому разработчик не претендует ни на какие авторские права, то по умолчанию авторские права на разработку принадлежат именно разработчику. А вообще такие вещи нужно оговаривать до начала работы. Я обычно говорю заказчику примерно так - работа будет стоит например 50$ и я не имею права ее кому-либо продавать или работа стоит 25$ и я ее включаю в свой коммерческий модуль. Во втором случае кроме цены покупатель получает еще ряд преимуществ - модуль будет развиваться, будут исправляться баги, доделываться новые функции, будут писаться версии для новых версий движка итд и покупатель получит все новые версии бесплатно.

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

ресайзинг картинок происходит через модель ModelToolImage, где есть такой код: class ModelToolImage extends Model { public function resize($filename, $width, $height) { if (!file_exists(DIR_IMAGE . $filename) || !is_file(DIR_IMAGE . $filename)) { return; } $info = pathinfo($filename); $extension = $info['extension']; $old_image = $filename; $new_image = 'cache/' . utf8_substr($filename, 0, utf8_strrpos($filename, '.')) . '-' . $width . 'x' . $height . '.' . $extension; if (!file_exists(DIR_IMAGE . $new_image) || (filemtime(DIR_IMAGE . $old_image) > filemtime(DIR_IMAGE . $new_image))) { // создание нового рисунка } else { // тут добавляем touch } if (isset($this->request->server['HTTPS']) && (($this->request->server['HTTPS'] == 'on') || ($this->request->server['HTTPS'] == '1'))) { return HTTPS_IMAGE . $new_image; } else { return HTTP_IMAGE . $new_image; } } }

Не нужно забывать так же что далеко не все товары в магазине просматриваются равномерно. Всегда есть какие-то топовые модели или товары по акциям или товары на первых страницах в каталогах, которые просматриваются регулярно (думаю их будет процентов 20) и товары, не очень популярные или которых может вообще не быть на складе и которые просматриваются раз в несколько дней.. (а таких вполне может быть процентов 80) А это кстати вариант! Есть такая linux команда - touch, которая меняет время доступа к файлу. Так почему бы во время каждого обращения к файлу (или для файлов, старше несколько часов) не запускать эту команду? Так у нас все популярные файлы будут со свежими датами доступа и удаляться будут только не популярные.

Какая 100% загрузка, вы о чем? Мы же не будет удалять каждый час по миллиону файлов? Если удалять только устаревшие файлы и запускать крон каждый час то сколько файлов устареет за час? 10, 100, 1000? Сколько времени займет для команды rm удалить 1000 файлов? 1 секунда? Так в чем проблема?

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

Так у вас проблемы с кешем рисунков, который в /image/cahce/data или системный кеш который в /system/cache? Если рисунки и рисунков много то соответственно и создается на каждый рисунок несколько разных вариантов размеров. Как вариант (если используется много похожих размеров) можно оставить на сайте несколько основных размеров, а остальные менять средствами css. Например если одному модулю нужен рисунок 100 на 100, а другому 90 на 90 то для каждого рисунка в системе создается 2 варианта. Можно для 2-х модулей установить 100 на 100, а для второго прописать в css высоту и ширину 90. Еще вариант написать скрипт который будет удалять старые рисунки и запустить его по крону, тогда он автоматически будет все подчищать. Отключать кеширование рисунков очень не рекомендую, это создать огромную нагрузку на сервер, для каждой страницы и для каждого пользователя придется постоянно на лету создавать уменьшенные копии каждого рисунка, а их на 1 странице может быть штук 50