Спасибо

Слышал про такую. Но мне кажется это более громоздкий подход чем такой. Не?

Если создать артикли для опций и в зависимости от опции цена плюсуется . Например айфон 10 64 гб белый, Есть базовая цена, за самую дешевую единицу
например 1000 баксов + 100 баксов за розовый цвет или 120 за спейс грей. Т.е. цена за белый будет 1000, за розовый 1100, а за спейсгрей 1120. Опция 64гб не добавляет цену к товару, а если выбирается опция на 128гб, то цена возрастает на 200 бачей к примеру. И того за 128 гб цена на белый айфон будет 1200, на розовый 1300, а на спейс грей 1320. По такому принципу думаю сделать

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

Не нужно — так не нужно.

Раз не нужно, то виллкоммен цум https://github.com/DarkaOnLine/L5-Swagger

Мы этим и пользуемся

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

То что ты предлагаешь реализует этот пакет. Какой смысл делать то же самое?

Я ничего не предлагаю

Именно что предлагаешь:
https://t.me/laravel_web/275666

Я писал как будет работать пакет, но ты настаиваешь на своём варианте.

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

что такое билды товаров?

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

Например на белом Айфоне 64 гига, есть кнопка на 32 и 128 которая ведёт на другую карточку, и так же с цветом и т.д.

Скину чуть позже пример, сейчас в метро

А где тут я что-то предлагаю?

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

Я ни на чём не настаиваю, а просто сравниваю варианты. Я понимаю к чему нужно упрощение подхода.

Мне какая разница как ты будешь реализовывать то что тебе нужно?

Можешь мне в личку или сюда скинуть ссылку интернет-магазина где ради комбинаций делали отдельные карточки товаров?🤔

Я тебк больше скажу - openapi ничего не реализует. Это задокументированный стандарт, в котором написано кто что может принять, кто чей наследник и прочее. Всё.

Это сделано для того, чтобы   привести к общему виду разные варианты документаций.

А то КАК и ОТКУДА это инфа будет браться - их не волнует. Спецификация OpenAPI распространяется на структуру конечного файла.

Я в курсе. Я понимаю что на выходе у того же l5-swagger — json документ по стандарту openapi. Они только постарались свои докблоки сделать согласно той же openapi спецификации.

Не совсем. Они написали для себя хелпер для парсинга аннотаций. Это как фреймворк для ЯП.

В моём же случае большинство этих данных будет добываться автоматически.
Да, часть данных придётся так или иначе прописывать в док-блоки, ибо без этого никак. Но не всю инфу, как требует тот пакет.