Я и не говорил, что придумать удобство - задача разраба. Задача разраба - реализовать удобства, согласно ТЗ. (на практике же - подобрать "типовой проект", согласно ТЗ и скорректировать под нюансы/хотелки)
АПД. Но нормальный разраб ИМа всё-таки должен понимать задачи заказчика, а значит и удобства :)
Половина заказчиков с тобой не согласна :)
80% из оставшейся половины не нужно 50% того, что несут на борту универсальные ИМ движки. И хорошо, если это не мешает.
Но вот опя же из практики - даже текст письма покупателю ИМа мало кто проверит. А есть ещё и более "тонкие материи", о которых владелиц ИМ даже не подозревает. А их нужно настроить, и сделать это может только владелец. А разрабы или не хотят ему об этом говорить или даже не знают об этом. Но тут опять же не столько вина разрабов, сколько ограниченность бюджета заказчика.
Абсолютно верно! Хотя ТЗ никто не отменяет ;).
Но я о том, я что у большинства разборов на слово "ИМ" тут же моментальная - _единственный_двидок_который_я_знаю_, а ещё лучше - самописЬ:)
Вот тут есть нюанс. И достаточно серьёзный в плане отношения к понятию "ИМ".
Как далеко не всем офлан-продавцам нужны огромные торговые площади, развитая логистика, склады и собственные банки, так большинсву онлан-продавцам не нужно ПО, все это дело разруливающее.
ИМ может быть совсем простой, и даже без корзины, но это всё равно будет ИМ.
И он даже может приносить дохода больше, чем самый навороченый скрипт ИМа со штатом менеджеров и уборщиц. (продать одну яхту в год или продать 100500 канцтоваров на ту же сумму в от же год - разница в трудозатратах и содержанию биза огромна)
Ой, да чего только не доказывают заказчики. Особенно почитав СЕОшников и др аудиторов :)
Файлы - не готовые решения?
А как, интересно, посмотреть логи почему БД рухнула или тупо при не хватке памяти/потоков на запись 🍿
я тебе открою страшную тайну - они и не должны это знать. Не их это дело. Они должны уметь продавать. А ИМ - всего лишь один из инструментов, призванных помочь им в этом. Вот насколько удобен этот инструмен и как будет справляться с задачами - это уже задачи и даже проблема разрабов. А разрабы в большинстве своём (как видно по многочисленным топикам на сёрче) не понимают
, кроме как наличием корзины. :)
Вот тут-то заказчик и попадает. Но тут он на 90% виноват сам. Какое ТЗ и бюджет - такой и результат.
Впрочем, как показывает всё та же практика, подавляющее число заказчиков думает - "вот ща заимею ИМ и тут же обогащусь". Так что в среднем по больнице то на то и выходит :)
Использовать нормальные винты и универсальную кодировку.
Можно периодически архивировать и пересылать на др сервер/мыло.
Не любой, а дефолтный.
Обратиться к хостеру, что бы отключил вилкард-поддомены.
Сегодня разный, завтра ЧПУ захочется сменить - и?
Ещё раз - если бы движок не позволял гибко менять правило ЧПУ, то да, это однозначно разные урлы. Но раз позволяет (да ещё и изменять иерархию контента) - это такая защита от совпадений разных страниц по одинаковому урлу.
Это "задача" - следствие СЕО-заблуждений :). Я бы даже сказал неграмотности. Нужно просто научится смотреть выдачу и тогда не будет ни волнений по пустякам ни поисков костыльных "решений".
Можно так или так, а можно и по другому. Зависит от задач. (меня вообще смешит слово "интеграция" в приложении к почти сферическому вакууму)
Уже очень неплохо, если это понимаешь. Значит готов решать их, а не валить на движок.
А не по технической, но зависимой?
ИМ - это не только и даже не столько движок. Движок для среднестатистического ИМ - это больше личные предпочтения, слухи и заблуждения "опытных". Поэтому в твоём случае - пофик. Бери и пробуй. Что понравится - то и твоё.
И это есть правильно с точки зрения движка с гибким управлением ЧПУ - слаги (ярлыки) должны быть разные. У всех сущностей. Ибо ЧПУ может поменяться и случится коллизия.
Однако я не вполне уверен, что не существует костылей, позволяющих это обойти. Но я бы не рекомендовал ими пользоваться - при очередном обновлении может что-то поменяться и это полетит.
Короче - не заморачивайся ерундой :) Можешь изменить правила ЧПУ, добавив в слаг например, дату или ИДшник.
