Александр Мельник

Добавлю немного картинок, текст это всегда скучно)

только сейчас «догнал» что под строкой «536870911» вы имели ввиду длину данных в sql, а не строку, которую вы пытаетесь сохранить в это поле.

тоесть поведение изменилось? До этого вы вставляли длинную строку и говорили что она ОБРЕЗАЕТСЯ, а теперь вставляете короткую строку и пишите, что она НЕ СОХРАНЯЕТСЯ совсем?
Выглядит странно, по идее Денис все верно сказал, нужно изменить тип поля value. На самом деле максимальную длину хранимых данных данных можно и не указывать, будет выделено 65 килобайт под каждое значение.
По идее, вам и стандартного mediumtext должно было хватать, под него выделяет 16 миллионов символов, ну неужели ваш json был больше.
Проверяйте ошибки в логах, как в браузере в момент сохранение, так может и логи на сервере.
У меня родилась теория, что ваш json мог обрезаться не по причине длины строки, а по причине того что в его тексте встречался какой то запрещенный в sql символ, хотя это не поясняет ту ситуацию что вы описали в последнем коменте — не сохраняется даже простая строка «536870911»

плюс лично мне очень не нравится сама идея, когда ajaxForm (и fetchIt я думаю делает так же), хранит данные для форм в сессии.
Вся эта идея с генерацией уникального ключа для каждой формы, помещения по этому ключу данных в сессию, при отправке формы считываная этого с сессии… вызывает ощущение дикого костыля. Да, я вынуждем признать, что когда я писал свой аналог ajaxForm я тоже не придумал ничего лучшего и использовал этот же костыль.
Может быть, отчасти, именно поэтому я все реже и реже использую ajaxForm и его аналоги на сайтах и предпочитаю оставить форму в верстке, написаь свой js обработчик и свой php контроллер для отправки.

Вот видите как иногда полезно узнать чужое мнение. А то каждый «в своем мирке» и привыкает использовать инструменты только для каких то строго определенных целей. Я вот например использую ajaxForm (да я понимаю что речь идет о fetchIt, но задачи у них общие) только для примитивных форм в модалках, типа — заказать обратный звонок и так далее. И там необходимо, чтобы данные очищались. Если уже делать что то более серьезное, например личный кабинет о котором говорил Артур, то я предпочту писать все сам, благо сейчас на чистом js очень просто и подписаться на событие submit формы, и собрать данные через formData и отправить их на сервер через fetch и дождаться ответ через promise. Это приносит огромное ощущение удовлетворенности, что каждая строчка кода в личном кабинете написана тобой, что ты именно Разработчик, а не собиратель конструктора из чужих пакетов. Спасибо за ответы, я правда не мог подумать о таких способах применения этого пакета.

Прямо и восхищение и удивление у меня возникло.
Удивление вызвал Константин, вот прям интересно стало, зачем может понадобиться не очищать форму, после того как она отправлена? Это вроде бы такое странное поведение, все равно что пригнать машину на мойку, но попросить оставить грязным две двери) Ну тоесть теоретически там может быть, но зачем.
Расскажите пожалуйста, Константин, побалуйте пожалуйста мое любопытство, для каких целей форма должна оставаться с отправленными данными…
Ну а восхищение вызвал Баха, которые несмотря на нелогичность этого действия, даже добавил в сниппет параметр, за это отвечающий.

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

так как для проекта для которого он разрабатывался этого не нужно

Вот вот! Я так сразу и подумал, что родился этот компонент исключительно под требования какого то одного заказчика. Ему требовалась конкретная бизнес логика и вы ее реализовали.

Поэтому и есть некое ощущение оторванности от всего остального мира, поскольку сделано под конкретные нужды.
Но это не значит что компонент плохой, ни в коем случае.

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

А вот когда в документации помимо сухих технических данных, есть человеческим языком написанный текст, что мол после установки вы сможете решить такие то и такие то свои проблемы, вот это и это станет делать более просто и так далее — это же прекрасно.
Вот для примера, компонет в магазине (да простит меня автор)
modstore.pro/packages/alerts-mailing/socialtools
Название — Компонент с социальным функционалом
Описание — SocialTools — это компонент с социальным функционалом для CMS / CMF MODX. С помощью него можно отправлять и читать сообщения

Ну жесть же. Компонент с социальным функционалом, который позволяет читать и отправлять сообщения. Какие сообщения? Где читать? Куда отправлять? Чьи сообщения… А ниже только примеры вызовов сниппетов. Ничего не понятно, ни варианты использования, ни решаемые компонентом задачи. С таким же успехом название и описание можно было написать на латинском языке или на суахили, ничего не изменилось бы.

Ну это я так, бурчу от старости)

Понятно, спасибо.
Честно скажу, мне часто в описании новых компонентов (не обязательно ваших) не хватает «художественной части». Почти всегда все авторы акцентируют внимание на том, как вызвать сниппет, что ему передать и так далее и это правильно.
Но этого мало. Это уже технические аспекты, которые интересны сугубо разработчику.
А вот рассказать — зачем был создан этот компонент, какие задачи он призван решать, как именно он решает эти задачи, чем он облегчит жизнь менеджеру? сеошнику? покупателю? Ведь это важно, чтобы привлечь потенциальных покупателей.

Вот мне не особо понятно, зачем вообще может использоваться деление сайта на филиалы. Я думал, что это даст возможность в рамках одного сайта делать СЕО продвижение сразу нескольких своих филиалов. Но для этого нужны отдельные домены и отдельно ресурсы. Чтобы у филиала А был домен a.site.com и сооствественно СВОЕ содержимое страницы a.site.com/contacts или a.site.com/about
а у филиала Б свое содержимое этих страниц. Но получается что это не так.
Если бы в админке были разделены списки заказов для разных филиалов, то это могло бы облегчить жизнь менеджеров. Раз уж вышло что в рамках одного сайта например должны работать менеджеры 10 филиалов, то им было бы легче если бы они получали на свою почту уведомления о заказах сделанных по их филиалу, видели в админке только свои список заказов. Получается что и для менеджера никаких особых выгод нет.
Пользователю сайта есть небольшой бонус — только если включены поддомены, только если настроен редирект на самый близкий к пользователю филиал, то теоретически он сделает заказ в этом филиале и возможно товары к нему прибудут быстрее, чем если бы он заказал в другом филиале.

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

Если это дополнение все таки нацелено на интернет магазин и мы создаем разные филиалы, то как работает система оформления покупки?
1) пользователь может добавлять в корзину товары из разных филиалов? Я вошел в один филиал (поддомен), добавил в корзину один товар. Потом сразу перешел на второй поддомен и добавил в корзину уже товар из другого филиала? Или программа отслеживает это и не дает формировать заказ из товаров разных филиалов?
2) в документации указано, что есть учет остатков при покупке. Как это работает. К примеру у меня два филиала. А и Б. Насколько я понял из документации у вас товары имеют привязку к филиалу. К примеру у меня есть всего один товар. Назовем его Т. Но он представлен как в филиале А так и в филиале Б. В филиале А его 10 штук, а в филиале Б его 20 штук. Я клиент, делаю заказ. Сначала помешаю в корзину товар находясь в филиале А (a.site.com), потом перехожу в филиал Б (b.site.com) и снова добавляю товар. В корзине два раза товар Т но из разных филиалов. Оформляю заказ. Как будет работать учет остатков? У каждого филиала уменьшится на 1?
2) куда приходит уведомление о заказе? У каждого филиала своя почта для получения? Я клиент, вошел на домен одного филала, сделал заказ. Вошел на домен другого филиала, сделал заказ. Заказы пришли разным менеджерам? Или если одному, то в заказе видно, для какого филиала он был оформлен? Как менеджер филиала в караганде поймет, что это ему нужно идти на склад и собирать товары для этого заказа.

Видео не отображается ни здесь, ни в документации — залито как приватное.

Подскажите пожалуста:
1) вы нигде не уточняете о каких филиалах вообще идет речь? Только из упоминания в тексте о товарах, можно предположить что речь о филиалах магазина.
2) а могу ли я создать филиалы НЕ магазина. Не нужны мне там товары, например у меня бизнес по приемке металла и у меня 20 филиалов в разных странах. Но товаров в этом бизнесе нет. А вот иметь отдельные страницы (ресурсы) у каждого филиала хотелось бы. Тоесть у филиала номер один есть страница контакты, у филиала 2 — нет. Но при этом у филлиа два есть страница — наши преимущества.
3) возможность переключения между поддоменами. Достаточно просто в админке создать поддомен и все рабоатет? Не нужно создавать реальный поддомен? Не нужно вносить изменения в конфигурацию вебсервера? Работает и для apache и для nginx? SSL сертификат сразу работает и на этих поддоменах?
4) «Создание для каждого филиала своего sitemap.xml файла, который содержит только товары филиала». Это еще больше убеждает меня, что под словом «филиал» Вы имели ввиду исключительно филиалы магазинов. Или же я могу сгененировать карту сайта в которой будут не товары этого филиала, а его ресурсы-страницы?
спасибо.

если бы вы использовали синтаксис fenom было бы проще.
Внутри чанка вам доступен номер иттерации. [[+idx]]
вы можете написать проверку, на то что номер иттерации без остатка делится на 3.
если это условие верно, то вы будете знать, что завершилась 3,6,9 и так далее иттерация.
и по этому условию вывести другую верстку.

Вы ведь сделали два разных шаблона, верно?
Один для списка новостей, второй для детальной новости?
В первом вызываете pdoresources а во втором НЕ вызываете его, а просто обращаетесь к полям ресурса через
[[*pagetitle]] [[*content]] и так далее?

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

Не вникал конкретно в вашу ситуацию, но раз вы используете импорты, то необходимо добаввлять атрибут type=«module» у тега script.
Консоль в браузере обязательно должна была вам об этом сообщить.

Человек решил свою проблему, поделился и молодец.
Использовать нам или нет — это уже наше дело. Кто может — напишет лучше. Кто не может — возьмет этот пример. Зачем прям минусовать заметку.

И в ваших словах есть правда.
Видимо мир вообще устроен циклически. Мы сначала изобретаем технологии, чтобы нам проще жилось, а затем технологии отупляют нас и уничтожают.
Ведь получается, что через какое то количество лет и правда появится профессия «оператор чатбота», цель которого будет уже не написание кода, а формулировка правильных вопросов. И тогда человек вообще разучится программировать. Как мы уже разучились считать, после того как изобрели дешевые калькуляторы. Моей маме 80 лет и она прекрасно в уме умножает 3 значные числа, А на листке в столбик может делить огромные числа. А я уже не могу. Чтобы умножить 23 на 56 лезешь за калькулятором. Или когда телефоны были стационарные, я помнил около 30 номеров — друзья со школы, другие важные номера. КОгда появились мобильные и их телеонные книжки — я с трудом вспоминаю свой номер телефона, не говоря уже о 30 других. Мы, как человеческий вид (ну хорошо, не буду говорить мы, скажу — я) тупеем, и это плата за использование технологий.
У Айзека Азимова есть фантастический рассказ, как люди в 2100 году заново изобретали таблицу умножения, видимо фантаст был прав)
Чтобы разорвать этот круг нужно остановится в какой то точке. Вот вы пишите, может гугл запретить. А было бы неплохо. По краней мере для программистов, чтобы гугл предоставлял доступ только к документации. А не к чужому коду и прочему. Хочешь чтото написать — будь добр изучи и напиши.
Но понятно что это мои фантазии…

Знаете, я разуверился в возможности написания «атоматического» спамбота, когда не так давно произошло следующее.
Возникла на работе задача сделать быстрое решени по переносу сайтов с одного места в другое.
Как ее решал я — писал bash скрипты, которые по ssh выполнли создание архивов, дампы баз, потом подключались на другой сервер, туда все копировали, проводили постобработку типа сброса кеша, замены путей в файлах конфигураций и так далее.
Как ее решил мой коллега. Написал на jave программу которая тупо запускает браузер и в нем полностью имитирует все действия человека. Тоесть его программа сначала вошла на хостинг откуда нужно перенести, сама там авторизовалась, сама преешла на нужные страницу в панели хостинга, создала архивы, как это делал бы человек, скачала их. ПОтом авторизовалась на другом хостинге и там создала новый сайт, залила туда архив и так далее. Все это визуально у тебя перед глазами, ты только сидишь и смотришь.
И тут я понял, что при таких возможностях, нет никаких разумных способов отличить бота от человека. Только задавать вопросы боту, на которые ему будет сложно ответить.

но согласитесть, нет разницы, будет в каждой форме в этом инпуте написано одна и таже строка (value='hello world') или генерируемая каждый раз разная строка — на антиспам это не должно влиять. Ведь валидатор проверяет только факт заполненности этого поля.

Приведу пример, почему у меня слегка негативное отношения к чрезмерному использованию интернета и тем более всяких чатов на ИИ в разработке.
Есть коллега, который всегда предлагает самые безумные решения. К примеру, собираемся разрабатывать сложный проект, в сжатые сроки, мы разрабатываем бэк на php. Он же выступает с предложением, а давайте на python. Все такие — как так, никто не умеет python, зачем. Спрашиваем — у вас есть опыт работы с этим языком, говорит нет. Так чего ради все будут сложный проект начинать на совершенно неизвестном языке — ответ. Да что там сложного, все можно нагуглить.
Или аналогичный пример. Этот же человек вдруг посмотрел видео на ютубе и решил, что теперь нужно использовать везде graphQL вместо restapi у нас. Потому что в видео сказали, что это круче. И все, этого достаточно.
В современном мире разработчик вообще перестал думать, что програмирование это вообще то сложно. Что ты должен и мозг затачивать и тренировать определенным образом, и память. Что ты должен учить книги по 600 страниц чтобы разобраться в регулярных выражениях на высоком уровне. Никто не хочет этого делать, все говорят — да нафик, мы пойдем нагуглим. ВОзьмем куски чужого кода, а если возникнут проблемы, зададим вопрос на stackoverflow.
На днях случайно попросил одного человека кое что исправить в своем же коде на js, при открытом экране в скайпе. И человек не смог. Он даже не знает как правильно пишется addEventListener поскольку редактор все время сам ему подсказывает. И это человек с высшим образованием программиста. Без доступа к интернету никто уже не может программировать, потому что се данные не у тебя в голове, а в гугле.
Поэтому в целом, я негативно отношусь к чрезмерному использованию современных технологий в нашей работе.