Да всё просто. Товары в большинстве случаев (когда товаров много) не вводятся вручную, а импортируются из каких-нибудь файлов. Я как-то делал на друпале импорт десятков тысяч лекарств для аптеки (причем каждый препарат там делился на конкретные поставки со свими сроками годности и прочими параметрами). Кстати, пришлось свой скрипт делать для импорта и записывать напрямую в таблицы БД, т.к. импорт дестков тысяч товаров должен был производиться в пределах минуты-двух, а если через API делать с учетом вызова хуков и пр, то там часами импорт бы шел (опять к самопису приходим :)).
Так вот, эти товары ежедневно перезаписываются, основным источником являются файлы для импорта от поставщиков, управление товарами полностью автоматизированно. И в этом случае лезть в товары с какими то описаниями... - плохая затея.
Простое и надежное решение - сделать независимый каталог описаний товаров и связать его с реальными товарами например через артикул. При публикации карточки товара инфа из самого товара и из каталога описаний собираются вместе и отображаются посетителю. В итоге каталог товаров и каталог описаний полностью независимы друг от друга. При желании вообще можно каталог описаний в отдельный микросервис выделить и несколько магазинов с ним связать...
Честно говоря, я уже не очень понимаю об чем спор. Возможно путаница в разном понимании термина "самопис". Современный самопис на современных фреймворках имеет очень высокие уровни абстракции. Все средства для поднятия админки и прочего имеются в готовом виде.
Меня Джанго десять лет назад напугала. На пхп надо было доработать приложение по анализу логов (деталей уже не помню), заказчик дал мне дамп БД (mysql), который я похоже случайно сохранил в папку с джанго и забыл про него. Потом игрался с джанго и вдруг в админке обнаружил готовое приложение, которое мне предстояло создать: в дминке были классы и объекты пользователей, классы и объекты логов, связи между ними, все необходимые поля и пр. Я вообще подумал, что с ума сошел... Откуда, думаю, это всё появилось, да ещё на питоне??? Только потом догадался, что админка со всеми моделями, объектами и связями сгенерировалась автоматически из дампа базы данных...
В общем "самопис" сейчас весьма условный - это, так скажем, набор больших готовых кубиков, из которых можно вручную и даже автоматически сайты генерировать. А ЦМС - это полностью готовое решение (манипуляции мышкой не в счет).
Так вот, если нужно очень бюджетное максимально дешевое решение, если у заказчика цели неясны и/или не очень серьезны, если его хотелки полностью покрываются коробочным решением (цмс), то конечно на ЦМС лучше делать. Это лучше и для заказчика, и для исполнителя. Сделали и разбежались. Если же нужно что-то серьезное и/или специфическое, если заказчик четко знает, что он хочет, если есть нормальный бюджет, то... здесь без долгосрочного сотрудничества между заказчиком и исполнителем не обойтись. И если такая связка успешно создастся, то в любом случае будет "самопис" - не зависимо от движка, выбор которого подскажут стоящие перед ними задачи.
Скажите, к примеру, можно ли быстро и просто на вордпрессе сделать такую банальную вещь как каталог описаний товаров?
Есть товары (или другие какие-либо сущности). Их много. Товары импортируются скриптом автоматически. Нужно снабдить описаниями некоторые (ходовые) товары. Хочу посадить девочку и пусть она занимается составлением описаний. Как это реализовать в вордпрессе? Только не надо предлагать добавлять описания в сами товары, это глупость. Во-первых, управление товарами происходит полностью автоматически и в этот процесс лучше не вмешиваться, а во-вторых я не хочу давать девочке доступ к товарам.
Можно ли реализовать такую банальную задачу на вордпрессе?
За сам по себе копипаст в таких тематиках санкции не накладываются, поисковики это понимают. Но нужна уникальность иного рода - сервисы, оригинальная подача материала и т.п., чего нет у других. Санкции накладывают не за копипаст, а за неуникальность. Это разные вещи. Копипаст может быть уникальным. И копирайт может быть неуникальным. Попробуйте понять это.
ale5, Ладно, дам совет. Здесь где-то в соседних ветках известный в здешних кругах человек обитает. Программирует лет двадцать. Так вот он долго спорил, что работа программиста по созданию сайта типа вашего (включая программирование) не может стоить больше ДВУХ баксов и что он сам за ДВА бакса всё делает. Поторгуйтесь с ним, возможно он вам скидку сделает. Думаю, вы сойдетесь характерами.
ab -n 1 -c 1 "http://..url../"
Это под линуксом, если апач установлен. С учетом времени пинга, там все страницы похоже целиком закешированы.
Не смотря на кривую верстку, кривые урлы и дизайн из 90-х, всё же этим сайтиком пользоваться весьма приятно. Всё работает просто и быстро. А аналог фасетного поиска там есть (см. "поиск по каталогу"), только сделан он пошагово: производитель > год выпуска > модель авто > категория деталей > список деталей. Всё очень просто. Скорость отклика - всего 9 мс.
Реализуется такой магазин на современных фреймворках очень быстро и просто - быстрей и проще, чем в например в друпале то же самое мышкой накидывать.
А обновлять модуль тогда как? Никак! Нехорошо хакать сторонний модуль под себя. Разве что если только автор модуля пожелает включить данный функционал в свой продукт.
Компонент может быть сложным и очень дорогим. И уж по любому будет на порядки дороже, чем десяток строк наследования и переопределения, чего требуется, если мелочь какую-нибудь добавить надо.
Конечно, всё что угодно можно сделать. Разве об этом спор?
Идем далее. Вот есть (установлен) в системе некий сторонний компонент, он меня в целом устраивает, но мне хотелось бы чуть изменить и расширить его функционал. В нормальной системе я просто создаю свой кастомный класс, наследуя класс готового компонента и переопределяя и добавляя необходимые методы. Т.е. я например могу получить свою кастомную галерею с помощью всего нескольких строк кода. Причем я не лезу в код родительской галереи, я просто в полной мере использую механизм наследования, а основная галерея может спокойно обновляться. Причем наследование и шаблонов касается - я просто наследую имеющийся шаблон и добавляю, что мне надо. Многие ли коробочные движки позволяют такое сделать?
Например, нужно реализовать дерево объектов разного типа (с разным набором полей, методов, с разной логикой работы и отображения), причем для каждого типа надо определить правила: какие типы допустимы в качестве родительских и какие в качестве потомков. Это банальный каталог, но нормальный, без глупых ограничений.---------- Добавлено 07.06.2017 в 18:21 ----------
Зачастую это проще, чем делать на базе коробочной ЦМС. И кода там будет не тонны, а сотни строк всего, ну несколько тысяч.
