Автозапчасти да - их тыщи. Радиодетали там итп.
И тут надо сразу думать как это все переваривать, то, что первоначально у людей было 100 позиций кажется мне крайне удивительным.
Но всё, что ближе к "куртка женская" "слон синий" редко имеет столько разновидностей.
Да и миллион можно. При наличии индекса из базы все забирается почти мгновенно.
Дольше весь этот php стартует.
Ну давайте посчитаем. 20.000 товаров. По 50 байт. 1.000.000 байт.
Насколько сожмет его зип ? Надо конечно попробовать, но если в 5-10 раз, то 200кб один раз юзеру можно и "залить".
Особенно если асинхронно.
Больше - хуже. Действительно придется заливать то, что остается после ввода скажем 3х символов.
Но это всё уже "несколько на грани фола".
Для сотен и тысяч товаров можно многое выгрузить на клиентскую сторону, для десятков тысяч уже не выйдет.
Интересно составлят ли ИМ и CMS с >10.000 документов хотя-бы 0.1% от общего числа...
А в БД фигачат 99%...
Так онаж не для специалистов, а для неспециалистов.
Экономия-то какая... можно никого не нанимать, а самому, ну или вон "надька с ресепшена" сделать.
А главное - всёж бесплатно :)
Страшно не то, что WP такой... они все такие... увы.
Стандартный сервис, это "как-то так"
/ru/forum/comment/15436308
Я лично встречался с "решениями", которые писали аналитику (ну типа что там сколько загружалось в каких плагинах) в БД товаров :).
И это не мешает входить таким решениям в пятерку лидеров по миру...
logrotate... не - это слишком, слишком сложно для настройки и понимания.
А нигде не храню.
Если человеку нужна красная, то пусть оформит заказ, а :) ?
Нет, свинство, но я ему(не я конечно - менеджер) предложу сам "красную найк" вместо "красной адидас", чего его отшивать-то сразу.
На самом деле у меня ситуация такая, что люди согласны подождать.
Это что такое ?
Оно как-то от посетителя зависит, да ? (шучу, но отчасти)
Слышал амазон так делает, зачем ему понятно, но как это может работать для небольшого магазина-то ?
Алгоритм какой ?
В некоторых нишах еще можно... скажем "вы тут месяц назад покупали подгузники - может еще надо ?",
но в моём случае предложить нечего.
Для магазина курток что вы собрались юзеру толкать ?
Показать "нет товара" = избавиться от клиента :) ?
Второе полезно не всем, мне не полезно, если бы было надо - вынимал бы микроскопическим аяксом асинхронно.
Вся страница статика - этот блок "потом" приезжает и вставляется.
Не держу у себя локальных отзывов, ибо не считаю полезным и честным инструментом.
Где есть - это отзывы от фейсбука-вконтакте, они берутся оттуда прям.
Если держать локальные, то яб добавлял их в текст страницы прям сразу, при генерации страницы с товаром.
Зачем ждать, пока кто-то напишет нужное :) ?
В крайнем случае отдельно складывал-бы, как вы написали, тоже нет ничего сложного абсолютно.
Не стояла задача. Проблем сделать не вижу. Спасибо, кстати, за идею.
А, о... найдет. Дело в том, что в моей схеме "Куртка адидас женская 30го размера" будет так и называться
"Куртка адидас женская 30го размера - красная" "Куртка адидас женская 30го размера - синяя", т.е. в товары
добавляются всё признаки.
И при попытке набрать "кра" вы увидете в выпадающем списке подсказок
"Куртка адидас женская 30го размера - красная"
"Красные огурцы"
итд итп
Вот словоформы нет, не обрабатываю. Но тоже можно сделать в принципе.
Пока вводимое в эти поля (оно всё-таки посылается на сервер для статистики) не показывает проблем.
Не успевают набрать - выбирают из подсказок.
Подсказки, разумеется, генерируются налету клиентом, список всех товаров у него есть.
Проблем с количеством параметров при небольшом (сотни-тысячи) количестве товаров не вижу,
хранится в локалсторейдже, достается асинхронно один раз, чекается версия итп.
Это еще и экономней по траффику выйдет, чем сервер дергать каждый раз до довольно больших выборок,
сейчас там json, но для больших яб зиповал по пути, раз в 10 поди сожмется.
Параметрический поиск не везде переделан, врать не буду, но это всё "наследия" исключительно.
Надо бы доделать.
Это весьма затруднительно.
Дело в том, что настройка готовых решений "на выходе" как правило не дает даже близко годного результата.
Разумеется "размороженная" еда гораздо дешевле приготовленной лично для вас.
Не знаю нашел бы я в себе силы оплатить всё это...
Знаю только, что после "настройки готовых решений" я всё-таки в какой-то момент психанул, выкинул всю
сделанную работу и написал только нужное.
Разумеется - это роскошь. Могу себе позволить. Но как люди работают с "готовым" я честно не понимаю.
У меня глаз дергается, когда я вижу что выдает им "готовое" в виде страниц.
Пока пользовался, неоднократно "попадал" в "интересные положения".
(люблю рассказывать, как один довольно популярный ИМ будь он проклят сообщал моему клиенту "пошел нахрен", на попытку оставить
заказ с доставкой на 40000руб что-ли... прям стояла проверка, у кого >40000 - тому ошибку с дебильным содержанием, прям в поставке такой получил, прям модуль с такой "заботой" :).)
С регистрацией увы приходится некую динамику обеспечивать, хотя от неё в ряде случаев удалось отказаться.
Анализ показывает, что часто она не нужна нафиг никому (регистрация сама). В общем-то можно было бы сделать
и на статике, в чём проблема-то ? :) Думается даже переделаю. Что такого динамического в кабинете пользователя ?
Поиск и фильтры отлично работают на клиентской части. Если товара не очень много, сотни позиций.
Для десятков-сотен тысяч да - пришлось бы что-то делать на сервере.
Однако ВСЁ остальное прекрасно будет чувствовать себя в виде статики и при 100 товарах и при 100.000.
Много.
Фишка в таких самописах в том, что они делают только то, что нужно :).
Специалист любой сможет поддерживать. Специалист я сказал :).
По факту не вижу проблемы с подержкой
10.000 байт css стилей
50.000 байт JS сценариев
50.000 байт php кода
30.000 байт шаблонов
Это неминифицированных.
По крайней мере то, что год не трогал, через год возникло желание слегка отрефакторить... и ничего, как по маслу.
Года два назад скрепя сердцем вставил какой-то могучий "готовый" слайдер для первой страницы... 80кб на JS.
Оказалось, что достаточно 1382 байт для его замены :).
Вам правда интересно ?
Третий день пытаюсь понять, что конкретно имели в виду индийские программисты (они правда из индии)
написав 100500 строк кода там, где было бы достаточно 50ти. Пока удалось выкинуть процентов 60 только.
И вроде-бы начинает работать :)
С годами дебилы начинают не умилять, а раздражать.
ЗЫ. И да... если чё: я не позиционирую себя как какого-то гуру именно в вебразработке. Так... имею опыт.
У вас конкретно говнорешение говнозадачи.
Хотите подсвечивать что-то, напишите ексель-моксель на JS десять строк кода и подсвечивайте. Без этих бесконечных простыней.
Логика должна быть следующая.
После загрузки страницы Для всех ссылок на текущую страницу (или не для всех, так как надо) Проставить класс active
На jquery это даже менее 10 строк, можно и в пару уместить, но я люблю форматировать.
И исполняться всё будет со стороны клиента, а не сервера.
И грузить клиента, а не сервер.
Еще раз задумайтесь: почему ради того, чтобы клиент увидел визуальный эффект вы что-то там каждый раз на сервере пересобираете ?
У вас что, сервер резиновый ? Делать ему нехрен :) ?
Собственно, это пример того, от чего лично я бегу как от чумы. В современных движках подобных решений немало.
Толстый клиент ей богу лучше.
ЗЫ. И да... первый признак говнокода - copy+paste
"А чё, так нельзя что-ли ?" :)
К сожалению, ситуация довольно типичная.
Я так пытался "окультурить" очень модный и современный движок ИМ.
Вначале скальпелем вырезал... потом две недели топором махал.
Потом посмотрел... и увидел, от него ничего уже почитай и не осталось...
Но клиента во всём этом не убедить. Так и сдают "чудовищные глючища". Зато дешево.
Похоже у вас выход только один: убить все не необходимые плагины, а необходимые либо подобрать такие,
что будут не очень всё грузить, либо чуток исправить вручную. Будет ли это быстрее, чем сделать самому
неизвестно, зависит от конкретных задач.
Не бывает так. Не бывает.
В реальности никогда не бывает так, чтобы сегодня 100, а завтра 1000000.
И не будет работать НИХРЕНА если аяксом выгребать из базы на 1000000 при каждом нажатии клавиши. Ляжет всё. Задолго до того.
Нет, когда надо впарить - это хорошая речевка
"мы сделаем вам хреново, но если потом, ведь у вас бизнес в 100000 раз укрупнится, то всё будет ок".
Ну ктож откажется от 100.000 раз укрупнения-то :) ?---------- Добавлено 18.01.2018 в 15:14 ----------
Я одного не понимаю: что вам мешает разбить страницы на содержимое и шалблоны и статически их собирать ?
К чему вам вообще что-то на php. Зачем вы его стартуете для выдачи чего-то конкретному юзеру ?
С навигацией нифига не понял, но похоже вам надо освоить JS...
---------- Добавлено 18.01.2018 в 15:16 ----------
Понимаете... я не смогу никого разводить, основной заказчик всего этого самописа я сам.
И да, у меня были сайты на модных движках, на модных фреймворках... и вот до статика докатился... и стал счастлив.
Вот ей богу, я не люблю велосипеды, но то что проталкивают как годные решения - это такой "треш и содомия",
что ну его нафиг ей богу.
Сайты безусловно примитивные, интернет-магазины там всякие итд итп.
Самодур конечно. Как посмотрю что предлагают в виде CMS, так понимаю: ну его... лучше пускай меня хоть педерастом
называют, чем я этим всем пользоваться буду.
PS. Неоднократно писал и продолжаю писать: самописы подходят только для специалистов.
Всем остальным от них надо держаться как можно дальше. Самописы написанные не специалистами
еще больший "угар", чем современные фреймворки и CMS
Надо как-то получить лог запросов и потихоньку его разбирать.
Но уверяю вас, гораздо продуктивнее будет сверстать 22 страницы в нотепаде и выкинуть весь движок со всеми проблемами...
Я так "топором" две недели вырубал лишнее дерьмо, но его там столько, что хватит и на два года.
Тот случай, когда свой велосипед проще и быстрее сделать.
Либо другой вариант: арендуете некислый сервер... и смиряетесь
Либо третий: настраиваете кеширование, делаете простой скрипт, который перегенерирует эти все страницы
и запускаете его один раз после каждого редактирования. Клиентов обслуживаете из кеша.
