dwd

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

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

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

Да, тут вы правы на 100%. Абсолютно все разработки состоят из букв латинского алфавита.
Так что хочешь ты этого или нет, но без повторов не получится))

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

Я конечно могу потратить час и написать трактат о том, как решить все ваши перечисленные задачи посредством данного компонента. Но во-первых у меня нет желания этого делать, во-вторых это будет скорее похоже на повесть о каше из топора. Да и вообще - мое дело писать инструменты, ваше - решать нужны ли они вам и придумывать как использовать. Мы же начинаем скатываться к диалогу "а нет ли у вас такого же, но с перламутровыми пуговицами?".

Цена всегда устанавливается продавцом, а им в данном случае выступает не автор а площадка. Особенно в случаях с оплатой размещения самим же автором публикации. Хотя реализовать назначение цен самими авторами тоже не сложно. Если вам это будет необходимо я подскажу как.

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

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

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

а) увы, никакой аналогии между тем что вы описываете и данным компонентом нет
б) нужного вам решения для групп у меня тоже нет
в) акции типа "купи поле и получи доступ в группу" кажутся мне не актуальными

Для вас любой каприз. Хоть сканер сетчатки глаза))

Куда кидать? Какие пользователи? Вы о чем? Вы пожалуйста сперва разберитесь о чем компонент)))
Он не про "пользователи могут кидать", а про "система кидает пользователям небольшую ежедневную монетку за посещение сайта".

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

Можно много чего. Особенно если вы располагаете штатом сотрудников и серверными мощностями Гугла))
А пока у меня нет ни того ни другого я пытаюсь мыслить категориями здравыми. И здравый смысл мне говорит о том, что если кому-то интересно, то он откроет страницу и посмотрит. А все эти уведомления это лишние издевательства над сервером. Вы ведь не допускаете мысли что опросов таких могут быть сотни и тысячи и проголосовавших в каждом десятки тысяч. И если по каждому из них если заниматься рассылкой подобных уведомлений, то сервер очень скоро придется менять. Миллионы строк никому не нужного хлама ...

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

Уведомлений? Вы хотите чтобы автор записи получил 100500 сообщений о том, что кто-то поддержал идею? Добавить такой функционал несложно, но думаю он скорее расстроит автора чем обрадует. Конечно приятно, что твою идею поддержало 100500 человек, но 100500 уведомлений это перебор))

Схож да не похож. Или "не все то золото, что блестит"))
На эту тему есть немало разработок, например - https://www.youtube.com/watch?v=BO5nDFIS4mY
Негоже хвалить свое, это должны делать другие. Но, допустим, что это будет сказано на правах рекламы)))
Данное поле отличается хотя бы тем, что оно более дружелюбно:
1. Позволяет легко и быстро голосовать гостям. При этом имеет абсолютную защиту от накрутки.
2. Умеет автоматически регистрировать проголосовавших гостей на сайте, отправлять данные для доступа им на почту и т.д.
3. Автоматически определять имеется ли у гостя аккаунт на сайте и вежливо предлагать авторизоваться либо даже оставить голос без авторизации
4. Имеет возможность отмены голоса как для пользователей так и для гостей
и т.д. и т.п.

Я плохо понимаю как все то, о чем вы пишете касается автоматического начисления средств пользователям? Кто и куда должен вводить номера карт? Ну и если даже предположить, что речь идет о прямом начислении средств не на баланс пользователей, а прямо им на карты, то назревают чисто праздные вопросы:
1. какой нормальный пользователь согласится вводить номера карт на вашем сайте?))
2. кто должен оплачивать конскую комиссию это сервиса? минимальная комиссия 95р.))
3. какого ж размера у вас планируются бонусы если минимальный платеж у них 250р.?))

Не планировал подобных вещей. И на это есть ряд причин.
1. Все решают заказчики. Мое планирование как правило сводится к потребностям тех людей, которые ко мне обращаются. В основной своей массе я пишу то, что нужно им. Порой эти просьбы вообще далеки от сайтостроения. Ну а если у меня от этого остается какое-то время, то жизнь тут же беспощадно находит чем его занять))
2. Поляна уже занята. Как бы то ни было, но я стараюсь не дублировать тот функционал, который уже присутствует в системе и дополнениях других разработчиков. А в данном случае даже считаю его неправильным. Биллинг - это компонент от разработчиков системы, а следовательно при всех его недостатках продажи приносят им какую-то копейку, что позволяет меньше заниматься зарабатыванием денег и больше времени посвящать системе.
3. Хорошо там, где нас нет. Учитывая место моего проживания написание и поддержка подобного компонента сопряжены с рядом юридических трудностей - Webmoney запрещен, Яндекс заблокирован, Qiwi и WalletOne тоже под запретом, большинство платежных систем вообще не желают сюда заходить и здесь работать. Следовательно даже тестовые аккаунты этих систем это куча юридической волокиты.

У вас отличнейшая фантазия, браво! Вы придумали еще 2 способа продажи полей до которых я не додумался. И невольно подтолкнули меня к третьему забытому мной способу. Получается, что когда мне нечем будет заняться я могу освоить три новых направления:

- эксклюзивный выкуп(продажа в одни руки)
- лимитированная продажа(определенное число копий)
- аукцион(торговля за право эксклюзивного выкупа)

А если серьезно, то здравое зерно в этом есть, нужно найти время и подумать над этим, спасибо за идеи.

Читаем вашу ссылку:

1. Это чем-то отличается от нынешнего "Открывает вкладку баланс и нажимает Вывести"?))
2. Вы уверены, что это кому0то нужно? Чем дольше деньги находятся на балансе пользователя, тем больше шансов, что он их потратит а не выведет))

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

Здравствуйте!
Так а это кому-то нужно? Лично мне - нет))
До сих пор никто не потрудился сесть и написать какая конкретно дружба требуется.
Какие параметры считать, за что конкретно выдавать награды и т.д.
И не в форме комментариев пожалуйста, моя почта есть в профиле.

Здравствуйте! Нет, на данный момент в компоненте не такой возможности.

Вот так например подобные сайты зарабатывают на диллерах - https://price.ua/business/stores/price-lines-goods-and-arrangement-types.html

Я не знаю что нужно именно нужно конкретно вам и что для вас минусы а что плюсы. Есть масса сайтов, построенных по этому принципу. Ярким примером можно назвать тот же price.ua - https://price.ua/intel/intel_core_i5-10400/catc25t2m4381856.html
Вот открываю я страницу и вижу где, когда и за сколько можно купить интересующий вас товар. И при этом никто не запрещает добавить вам, подчеркиваю - к стандартному типу контента, корзину, систему приема платежей и реализовать онлайн продажи и любые другие нужные вам функции. Все это вы также можете увидеть на том же price.ua. Никто не мешает использовать бесплатный интернет-магазин, который так же построен на стандартном типе контента. Никто не мешает вам брать с диллеров плату, за то, что вы приводите к ним клиентов. Никто не мешает включать голову и думать. Я не маркетолог, я программист. Мое дело писать инструменты, ваше - думать как их использовать.

Вы сами можете добавлять в репозиторий товары, которые будут доступны для продажи диллерам. В этом случает ТК Производители вам не нужен.

Мне кажется, что компонент реализует не ту модель, которая вам нужна. В вашем случае, если я правильно понял, речь идет о продажах товаров самими пользователями. В рамках же компонента предусмотрена продажа именно магазинами и ТК Диллеры выступает ненужным звеном. А логика компонента построена так, что избавиться от него не получится.

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

Собственно об ошибке - ошибка возникает из-за того, что MySQL может индексировать только первые N символов столбца BLOB или TEXT. Таким образом, ошибка в основном возникает, когда есть тип поля / столбца TEXT или BLOB, или они принадлежат к типам TEXT или BLOB, таким как TINYBLOB, MEDIUMBLOB, LONGBLOB, TINYTEXT, MEDIUMTEXT и LONGTEXT, которые вы пытаетесь создать первичный ключ или индекс. С полным BLOB или TEXT без значения длины MySQL не может гарантировать уникальность столбца, поскольку он имеет переменный и динамический размер. Таким образом, при использовании типов BLOB или TEXT в качестве индекса необходимо указать значение N, чтобы MySQL мог определить длину ключа. Однако MySQL не поддерживает ограничение длины ключа для TEXT или BLOB. ТЕКСТ (88) просто не работает.

Ошибка также появится, когда вы попытаетесь преобразовать столбец таблицы из не-ТЕКСТОВОГО и не-BLOB-типа, такого как VARCHAR и ENUM, в тип TEXT или BLOB, когда столбец уже определен как уникальные ограничения или индекс. Команда Alter Table SQL завершится ошибкой.

Решение проблемы состоит в том, чтобы удалить столбец TEXT или BLOB из индекса или ограничения уникальности или установить другое поле в качестве первичного ключа. Если вы не можете этого сделать и хотите установить ограничение на столбец TEXT или BLOB, попробуйте использовать тип VARCHAR и установите для него ограничение длины. По умолчанию, VARCHAR ограничен максимум 255 символами, и его предел должен быть указан неявно в скобках сразу после его объявления, то есть VARCHAR (200) ограничит его длиной только 200 символов.

Иногда, даже если вы не используете в своей таблице тип, связанный с TEXT или BLOB, также может появиться ошибка 1170. Это происходит в такой ситуации, когда вы указываете столбец VARCHAR в качестве первичного ключа, но ошибочно устанавливаете его длину или размер символов. VARCHAR может принимать только до 256 символов, поэтому что-либо вроде VARCHAR (512) заставит MySQL автоматически преобразовать VARCHAR (512) в тип данных SMALLTEXT, что впоследствии завершится ошибкой 1170 по длине ключа, если столбец используется как первичный. ключевой или уникальный или неуникальный индекс. Чтобы решить эту проблему, укажите значение меньше 256 в качестве размера поля VARCHAR.

Применительно к вашей ситуации - как вы наверное уже догадались поле использует для хранения данных столбец типа TEXT. И данная ошибка никак с самим полем не связана. Вы могли столкнуться точно с такой же ситуацией используя поля Текст, Текст HTML, Список: мультивыбор и любые другие поля, использующие для хранения данных столбцы типа TEXT. При включении показа в фильтре система пытается создать индекс таблицы для увеличения быстродействия при фильтрации. И очевидно в коде системы, отвечающем за создание индекса данная ситуация не учтена. Я думаю вашему вопросу самое место на гитхабе. Я несколько раз сталкивался с подобной ситуацией(с абсолютно разными полями), однако понять природу ее возникновения у меня не получилось. Впрочем и цели докопаться до истины не было, проще было удалить поле и создать его заново. Ошибка в этом случае исчезала и ломать голову не было нужды.

Как вы можете повлиять на ситуацию?
1. Вы можете удалить и создать поле заново(если данные данного поля пока отсутствуют либо не важны)
2. Вы можете запретить создание индекса для данного типа поля. Для этого вам необходимо открыть файл system/fields/unilist.php, найти в нем строку
и заменить ее на
По желанию - после того как поставите нужную вам галочку "Показывать в фильтре"можно опять вернуть true на место.