Накидайте актуальные CMS без БД

У вас магазины без поиска, фильтров, регистрации пользователей? Или вы эти странички тоже в статику генерируете?

Если вы сам себе заказчик - то понятно, а если кому-то разрабатываете, то много ли найдется специалистов поддерживать это если вас, ттт, автобус собьет, например. bus factor т.е.

Зачем делать дублирование, когда я показал как правильно это сделать?

Сделайте как я показал, и не будет проблем.

Глобальные переменные, которые устанавливаются в различных файлах - вызывают проблемы при расширении\поддержке кода. Наступает момент когда непонятно почему переменная $var равняется 'one', а не 'two', так как где-то, в одном из подключенных файлов, ее что-то перезаписало.

С регистрацией увы приходится некую динамику обеспечивать, хотя от неё в ряде случаев удалось отказаться.

Анализ показывает, что часто она не нужна нафиг никому (регистрация сама). В общем-то можно было бы сделать

и на статике, в чём проблема-то ? :) Думается даже переделаю. Что такого динамического в кабинете пользователя ?

Поиск и фильтры отлично работают на клиентской части. Если товара не очень много, сотни позиций.

Для десятков-сотен тысяч да - пришлось бы что-то делать на сервере.

Однако ВСЁ остальное прекрасно будет чувствовать себя в виде статики и при 100 товарах и при 100.000.

Много.

Фишка в таких самописах в том, что они делают только то, что нужно :).

Специалист любой сможет поддерживать. Специалист я сказал :).

По факту не вижу проблемы с подержкой

10.000 байт css стилей

50.000 байт JS сценариев

50.000 байт php кода

30.000 байт шаблонов

Это неминифицированных.

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

Года два назад скрепя сердцем вставил какой-то могучий "готовый" слайдер для первой страницы... 80кб на JS.

Оказалось, что достаточно 1382 байт для его замены :).

Ясно, спасибо за предельно точный ответ!

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

Ещё раз благодарен! Поступлю, как вы указали. Действительно, ваш вариант кода более красивый и элегантный. У меня, увы, ещё мало знаний ((((

По скольким параметрам у вас фильтры есть? Опечатки обрабатываете? Если я буду искать "красная куртка" текстом, ваш поиск наёдет мне куртки, у которых признак цвет будет красный?

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

Не стояла задача. Проблем сделать не вижу. Спасибо, кстати, за идею.

А, о... найдет. Дело в том, что в моей схеме "Куртка адидас женская 30го размера" будет так и называться

"Куртка адидас женская 30го размера - красная" "Куртка адидас женская 30го размера - синяя", т.е. в товары

добавляются всё признаки.

И при попытке набрать "кра" вы увидете в выпадающем списке подсказок

"Куртка адидас женская 30го размера - красная"

"Красные огурцы"

итд итп

Вот словоформы нет, не обрабатываю. Но тоже можно сделать в принципе.

Пока вводимое в эти поля (оно всё-таки посылается на сервер для статистики) не показывает проблем.

Не успевают набрать - выбирают из подсказок.

Подсказки, разумеется, генерируются налету клиентом, список всех товаров у него есть.

Проблем с количеством параметров при небольшом (сотни-тысячи) количестве товаров не вижу,

хранится в локалсторейдже, достается асинхронно один раз, чекается версия итп.

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

сейчас там json, но для больших яб зиповал по пути, раз в 10 поди сожмется.

Параметрический поиск не везде переделан, врать не буду, но это всё "наследия" исключительно.

Надо бы доделать.

Это весьма затруднительно.

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

Разумеется "размороженная" еда гораздо дешевле приготовленной лично для вас.

Не знаю нашел бы я в себе силы оплатить всё это...

Знаю только, что после "настройки готовых решений" я всё-таки в какой-то момент психанул, выкинул всю

сделанную работу и написал только нужное.

Разумеется - это роскошь. Могу себе позволить. Но как люди работают с "готовым" я честно не понимаю.

У меня глаз дергается, когда я вижу что выдает им "готовое" в виде страниц.

Пока пользовался, неоднократно "попадал" в "интересные положения".

(люблю рассказывать, как один довольно популярный ИМ будь он проклят сообщал моему клиенту "пошел нахрен", на попытку оставить

заказ с доставкой на 40000руб что-ли... прям стояла проверка, у кого >40000 - тому ошибку с дебильным содержанием, прям в поставке такой получил, прям модуль с такой "заботой" :).)

А количество товара вы где храните? Ну т.е. вот куртку красную у вас купили последнюю, другому посетителю её ж не надо показывать уже как "в наличии"?

А рекомендуемые товары для посетителя?

По-моему это вполне себе бизнес-задачи, которые реально полезны магазину.

А отзыв, допустим, оставили на товар, у вас для кадого товара отдельная папочка и потом вы оттуда готовые куски html c отзывами собираете?

Я тут столько вопросов задаю, потому что как такие вещи сделать с БД для меня понятно, а вот на тех же файлах - это какой-то не сильно на данный момент оправданный геморой, поэтому и интересуюсь у активного сторонника - может не всё там и проблематично?

А нигде не храню.

Если человеку нужна красная, то пусть оформит заказ, а :) ?

Нет, свинство, но я ему(не я конечно - менеджер) предложу сам "красную найк" вместо "красной адидас", чего его отшивать-то сразу.

На самом деле у меня ситуация такая, что люди согласны подождать.

Это что такое ?

Оно как-то от посетителя зависит, да ? (шучу, но отчасти)

Слышал амазон так делает, зачем ему понятно, но как это может работать для небольшого магазина-то ?

Алгоритм какой ?

В некоторых нишах еще можно... скажем "вы тут месяц назад покупали подгузники - может еще надо ?",

но в моём случае предложить нечего.

Для магазина курток что вы собрались юзеру толкать ?

Показать "нет товара" = избавиться от клиента :) ?

Второе полезно не всем, мне не полезно, если бы было надо - вынимал бы микроскопическим аяксом асинхронно.

Вся страница статика - этот блок "потом" приезжает и вставляется.

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

Где есть - это отзывы от фейсбука-вконтакте, они берутся оттуда прям.

Если держать локальные, то яб добавлял их в текст страницы прям сразу, при генерации страницы с товаром.

Зачем ждать, пока кто-то напишет нужное :) ?

В крайнем случае отдельно складывал-бы, как вы написали, тоже нет ничего сложного абсолютно.

Я вас понял, спасибо за ответы.

Да все ок. Если время есть, то стоит учиться на своих ошибках. Пока сам не сделаешь криво, и не увидишь к чему это приводит - никакие нравоучения не помогут. Только собственный опыт позволяет понять всю боль кривых решений (а-ля самопис на инклудах).