Редакция МОЖЕТ отклонить приложения, которые:
2.11 повторяют приложения которые уже есть в App Store, особенно если их там уже много, например: фонарики, Кама Сутры, пукающие приложения.
Хорошее правило, но явно не запрет прямых аналогов.
в лучшем случае авторы зарабатывают десятки тысяч в месяц и лучше пусть один автор получает денюжку но делает безупречный продукт и имеет стимул его совершенствовать
Прямо реклама монополии :). Всю жизнь учили, что конкуренция лучше, а тут прямым текстом монополия лучше :). Я отстал от жизни? Монополия в ИТ лучше?
Мне кажется, что монополия провоцирует не совершенствовать продукт, а просто сидеть и стричь денежки :).
Если вдруг на мой компонент появиться конкурент и продажи упадут вдвое, то я, скорее всего, увеличу стоимость компонента вдвое. В расчете на то, что конкуренту тоже надо отбивать вложения, и так как, сложный компонент дорого делать, то конкурент тоже подымет стоимость.
А чем вам эта идея не нравиться? Стандартным импортом минишоп пользуются. Если будет компонент который будет позволять им пользоваться без танцев в бубном, то им тоже будут пользоваться.
А по факту, я почти на 100% уверен, что если вы сделаете стоящий и сложный компонент, который пусть и содержит идеи других авторов но выполняет их на голову выше — модерация его одобрит, а сообщество похлопает
А я вот не уверен. В правилах четко написано никаких прямых аналогов. Значит никаких. А то что за произвол? Это понравилось одобрим, а это не одобрим. И вдруг стоящий и сложный компонент чуть чуть не дотянет и его не одобрят, а время то на сложный надо много :(.
Владельцы MODSTORE обычно сначала интересуются мнением авторов аналогичных платных дополнений. И если автор против нового компонента (обоснованно), то магазин отказывает в публикации. Это уже много раз обсуждалось.
Можно ссылки где это обсуждалось. Что-то я не верные слова в поиск забиваю.
Очень заинтересован, как можно ознакомиться с демо компонента?
Мой компонент UserTest. По крайней мере требовалось сделать статистику тестов. Сколько на что сдали и т.д. с диаграммами. Сейчас заказчик в отпуске и говорит не знает требуется ли еще статистика.
Вы в разработке этого компонента заинтересованы? Или в чем заинтересовались? :)
Есть и минусы и плюсы.
1 минус. Как в моем случае, нельзя просто дополнение выпустить. Надо еще и сам функционал компонента под статистику доработать.
2 минус. Клиентам 2 дополнения придется ставить.
3 минус. Функционал компонента может измениться и дополнение станет не совместимым. Если в одном компоненте, то там это отслеживаешь, чтоб компонент был полностью рабочим. А в дополнении хата не моя и не знаю что там твориться :).
1 плюс как вы сказали
автор отвечает на вопросы по своему функционалу, а вы по своему
2 плюс если клиенту не нужна статистика он ее просто может не покупать.
В целом мне было бы интересней и клиентам удобней в одном компоненте. Только админам Modstore под группы разработчиков переделывать магазин — это много работы. Наверно они на это не пойдут :(.
Понятие прямого аналога все таки нечеткое. Допустим компонент msImportExport. Например я сделаю просто кнопку в админке для импорта товаров через стандартный скрипт минишопа http://webcandy.ru/manuals/import-csv-minishop2/. Плюс доработаю на долгую обработку, чтоб не обрывало при импорте многих товаров. Это будет считаться прямым аналогом?
Здесь в
Вообще есть тема такая. У меня есть заказ на доработку моего компонента. Прикрутить статистику тестов. Доработка не идет. Не складывается. Мне было бы удобно найти разраба, который бы эту доработку сделал. Но права на компонент и деньги за него я терять не хочу. Мне было бы удобно, если в модсторе были бы группы разработчиков и оплата за компонент перечислялась каждому разрабу по договеренности. Например сейчас компонент стоит 1990р другой разраб делает статистику, получает деньги от заказчика доработки и говорит 200р ему от продаж компонента. Наценяем компонент на 200р и от продаж мне падает 1990 а ему 200р.
Некоторые разработчики перестают развивать свои компоненты. Некогда или интерес пропал. Вышеописанная идея как раз для них подойдет.
Открытое ПО как раз и ценно тем, что его дорабатывать может кто захочет. А запрет на прямые аналоги эту ценность прибивают.
Ну мне главное не продавать компонент, а разнообразие доступных компонентов. Доступных в смысле посмотрел в магазине, что есть и выбрал, что более подходит. Я не все топики читаю неудобно по ним рыться. Да и компонент в модсторе гарантия, что перечислил кому-то левому деньги и не фига не получил. И для разраба удобнее через магазин. Гарантирует, что деньги получишь.
Кажется это сделано для того, чтобы разработчики не воровали код у друг друга. Код то открытый и в компоненте, при желании, можно восстановить билд, переименовать компонент и продавать как свой.
Но лучше с воровством бороться как-нибудь другим методом :(. Разнообразие компонентов нужно.
Пишите комментарии. 2 отзыва маловато, чтоб на администраторов modstore повлиять.
У меня при загрузке в ms2Gallery картинки не загружались. Поправил следующим образом.
В файле core/components/tinycompressor/model/tinycompressor/tinycompressor.class.php
это
function createTinyPNG() {
require_once $this->config['modelPath'] . '/tinycompressor/lib/tinify/init_tinify.php';
$this->tinyPNGClient = (empty(trim($this->config['tinyPNGApiKey'])) ) ? false : new Tinify\Client($this->config['tinyPNGApiKey']);
$this->tinyPNGCrazyClient = new Tinify\CrazyClient();
return true;
}
function createILovePDF()
{
require_once $this->config['modelPath'] . '/tinycompressor/lib/ilovepdf/init_ilovepdf.php';
$this->iLovePDF = (empty(trim($this->config['iLovePDFProjectID'])) || empty(trim($this->config['iLovePDFProjectKey'])) ) ? false : new Ilovepdf\Ilovepdf($this->config['iLovePDFProjectID'], $this->config['iLovePDFProjectKey']);
return true;
}
Т.е. я не знаю зачем это нужно, поэтому удалю нафиг?
Да :). Там где это точно не на что не повлияет. Просто имя кеша будет другое и все. А в сам $scriptProperties не трогаю. Я ведь верно понимаю, что удаление из переменной $options внутри функции на $scriptProperties не влияет? И в остальном коде setTotal присутствует?
Не знаю в каких. Наверно не в каких, но если вдруг где-то еще кеш используется, то очистка зависимости имени файла кеша от request не помешает.
И вообще включите на гитхабе issue и я бы вообще в этот код не лез.
Ну я хотел сначала issue, но не разобрался где оно там на гитхабе, а с пулл-регвест разобрался. На pdoTools issue кажется вообще заблокированы. Это во первых. Во вторых setTotal мне вообще не понятно зачем нужно и зачем оно именно в том месте. А request лучше в ядре удалить. Из-за него у всех сниппетов pdoTools проблемы с кешированием.
PS: кстати у меня открывается ваш сайт за ~400-500мсек.
А у меня время ответа сайта прыгает от 183 до 700 мс. В основном 180-195мс а иногда 300 или 700мс. debugParser ничего такого не показывает. У него от 100мс до 180мс. Как выяснить из-за чего прыгает?
Зачем на главной вызов pdoPage, если нет пагинации?
Достаточно просто msProducts.
Пагинация есть. Кнопка загрузить еще. Только она когда вызываешь сниппет кешируемым не показывается. Кстати, если бы не это, то можно было бы вызвать pdoPage кешируемым и Total parse time 0.1153460 s. В рамки гугл бы укладывался. Но вот не работает пагинация.
Спасибо не знал или уже забыл.
pdoPage все равно 88-93мс занимает. Его надо еще сокращать. Правда стало Total parse time 0.1874032 s. Но у гугла время ответа сервера от 210мс до 420мс. Как еще сократить время pdoPage?
js и css от компонентов можно тоже в minifyx загнать (не забыть отключить их в настройках или в вызове)
До этого еще просто не добрался. Завис на скорости ответа сайта.
Это очень плохо yadi.sk/i/rvBAyF2g3ZvLEq
Это вообще не понятно зачем такое. В модальном окне зум работает. Наверно разраб сайта под одну гребенку все сделал.
Не работал с Gallery, но на каждую картинку слайдера идет запрос на коннектор — отсюда короткое время кеширования. может есть там возможность уже готовый статичный путь получать?
Тоже удивило. Здесь еще не копался. Только стандартные параметры сниппета смотрел. Наверно напишу свой сниппет для вывода галереи. А то стандартный сниппет работает аж 50мс. Что он там делает столько времени не понятно :(.
Пока больше интересует скорость работы. Кто-нибудь замерял насколько феном убыстряет?
У вас функционал похожий, но явно другой зачем-то табличка в базе создается и какое-то ограничение по пользователям и группам. А у меня все просто скрипт загружает чанк, что указали в параметрах и запускает модальное окно в нем. Если конечно оно там есть. И больше ничего не делает. Функционала на 2 часа работы :). И то в основном на то чтобы из modExtra лишнее вырезать и описание написать.
Хорошее правило, но явно не запрет прямых аналогов.
Прямо реклама монополии :). Всю жизнь учили, что конкуренция лучше, а тут прямым текстом монополия лучше :). Я отстал от жизни? Монополия в ИТ лучше?
Мне кажется, что монополия провоцирует не совершенствовать продукт, а просто сидеть и стричь денежки :).
Если вдруг на мой компонент появиться конкурент и продажи упадут вдвое, то я, скорее всего, увеличу стоимость компонента вдвое. В расчете на то, что конкуренту тоже надо отбивать вложения, и так как, сложный компонент дорого делать, то конкурент тоже подымет стоимость.
А я вот не уверен. В правилах четко написано никаких прямых аналогов. Значит никаких. А то что за произвол? Это понравилось одобрим, а это не одобрим. И вдруг стоящий и сложный компонент чуть чуть не дотянет и его не одобрят, а время то на сложный надо много :(.
Вы в разработке этого компонента заинтересованы? Или в чем заинтересовались? :)
1 минус. Как в моем случае, нельзя просто дополнение выпустить. Надо еще и сам функционал компонента под статистику доработать.
2 минус. Клиентам 2 дополнения придется ставить.
3 минус. Функционал компонента может измениться и дополнение станет не совместимым. Если в одном компоненте, то там это отслеживаешь, чтоб компонент был полностью рабочим. А в дополнении хата не моя и не знаю что там твориться :).
1 плюс как вы сказали 2 плюс если клиенту не нужна статистика он ее просто может не покупать.
В целом мне было бы интересней и клиентам удобней в одном компоненте. Только админам Modstore под группы разработчиков переделывать магазин — это много работы. Наверно они на это не пойдут :(.
Здесь в а в msImportExport
Некоторые разработчики перестают развивать свои компоненты. Некогда или интерес пропал. Вышеописанная идея как раз для них подойдет.
Открытое ПО как раз и ценно тем, что его дорабатывать может кто захочет. А запрет на прямые аналоги эту ценность прибивают.
Но лучше с воровством бороться как-нибудь другим методом :(. Разнообразие компонентов нужно.
Пишите комментарии. 2 отзыва маловато, чтоб на администраторов modstore повлиять.
В файле core/components/tinycompressor/model/tinycompressor/tinycompressor.class.php
это
заменил на это
Теперь работает, но сервис после phpTrumbOn картинки меньше не делает.
PageSpeed Insights ругается, что картинки можно сжать еще. В итоге компонент мне не подходит. Буду пробовать OptiPic
Не знаю в каких. Наверно не в каких, но если вдруг где-то еще кеш используется, то очистка зависимости имени файла кеша от request не помешает.
И вообще включите на гитхабе issue и я бы вообще в этот код не лез.
А у меня время ответа сайта прыгает от 183 до 700 мс. В основном 180-195мс а иногда 300 или 700мс. debugParser ничего такого не показывает. У него от 100мс до 180мс. Как выяснить из-за чего прыгает?
pdoPage все равно 88-93мс занимает. Его надо еще сокращать. Правда стало Total parse time 0.1874032 s. Но у гугла время ответа сервера от 210мс до 420мс. Как еще сократить время pdoPage?
До этого еще просто не добрался. Завис на скорости ответа сайта.
Это вообще не понятно зачем такое. В модальном окне зум работает. Наверно разраб сайта под одну гребенку все сделал.
Тоже удивило. Здесь еще не копался. Только стандартные параметры сниппета смотрел. Наверно напишу свой сниппет для вывода галереи. А то стандартный сниппет работает аж 50мс. Что он там делает столько времени не понятно :(.
Пока больше интересует скорость работы. Кто-нибудь замерял насколько феном убыстряет?