Как не называйте, а решение, что делать с сущностью на основе запроса у вас принимает модель. А должен контроллер. --- Добавлено --- Да мне разбираться не обязательно, я уже увидел код, и использовать двиг, конечно, не буду, после того, что увидел И к тому же мы сейчас не занимаемся магазинами. Просто странно, почему именно такое решение принято, а не традиционный, понятный и работающий метод разбора урла
Уточнять экшин в контроллере вполне допустимо, но зачем это называть моделью?! У вас обычные ТТК с таким же тупым разруливанием экшинов.
Если вы привыкли к своим фреймфоркам и их структуре, то я прошу, не нужно за 5 минут просмотра кода делать какие то выводы. Если не нравится, просто пройдите мимо. Это будет гораздо культурнее. Я не первый день к коде. Я не обязан в своем проекте следовать шаблонам, которые вам привычны, а вполне могу делать свое видение проекта. Иначе в итоге получим копию какого-то известного фреймворка/проекта/cms. Я очень надеюсь, что все мы здесь культурные люди, и будем искренне стараться друг другу помочь. Спор на основе MVC не для этой темы, как мне кажется. Один только спор что такое MVC займет десятки страниц срача.
Причем тут это? И, да, реализации MVC могут очень сильно различаться. Но зачем топтать саму идею?! Придумали бы какое-то свое название или что-нибудь составное типа «как бы модель» Все исключительно ради того, чтобы вам помочь. Если вы где-то увидели намек на плевок, вам показалось. Это ни о чем. Вы изобрели какую-то странную конструкцию. Раз вы сами этого не видите, приходится помогать. Не хочу, чтобы вы через N лет себя ругали. Все замолкаю.
Очень хорошо что есть реальная заинтересованность помочь. В проекте достаточно понятная реализация MVC, которая подробно расписана на блок-диаграмме на GitHub. Я допускаю что многие могут не понимать сути тех или иных действий или самой структуры с первого подхода, но тем не менее это вполне соответствует логике MVC в широком его понимании. Я не рассчитываю на одобрение структуры проекта сразу, но надеюсь что рано или поздно многие вопросы прояснятся. Всегда приветствуется конструктивная критика, предложения и вопросы, так как это поможет развитию проекта. Если мне хватит терпения, нервов и времени, то я надеюсь что смогу разъяснить многие вопросы по проекту, которые этого потребуют. Одна голова хорошо - а сотня всегда лучше. Тем более сотня свежих голов, от которых могут поступить интересные идеи.
Вот и объясните, ради чего вам потребовалось так искажать понятие модели. На данном форуме этому самое место. Можно прямо в этой теме. Вдруг это и прям какое-то божественное решение, которого никто не понимает. --- Добавлено --- Пока что даже ваши многочисленные комменты «вернул в контроллер» намекают на то, что у вас имеются большие сомнения по поводу разделения логики между контроллерами и моделями.
ОК, пошел думать Но это будет долго. Я вот уже час думаю, зачем вам в адресе карточки товара числовой category_id, но так ничего вменяемого и не придумал. Наверное, тоже что-то божественное
Наверное потому что у категории есть id? Можно еще час обдумать почему он там, это весьма развивает логику и воображение.
А у товара есть category_id? Если судить по адресу карточки, может сложиться впечатление, что нету. Или что у вас идентификация товаров не сквозная относительно категорий.
А, я понял, зачем в адресе карточки товара category_id. Затем чтобы не вываливалось это Где ваши логика и воображение? Не развили?
Товар находится в категории, у которой есть свой id. В большей части магазинов такой принцип, только не всегда это явно видно по URL из за ЧПУ. Это банально чтобы вообще про это говорить. Это нужно смотреть в БД в таблице на товар. То что вывалился репорт при вбивании чуши в урл, это наверное потому что: Development in error_reporting(-1) mode; Сделать заглушку можно за 10 минут, но на продакшене а не на бете. Может и это объяснять или воспользуетесь гуглом? Я вижу что теряю время попусту потому что это тролинг, или нолинг.
Я вообще-то не про это спрашивал. Вы или не поняли элементарный вопрос или не удосужились даже его нормально прочитать, чтобы понять. Этой «чушью» было убирание category_id из адреса карточки, чтобы попытаться понять, нафига этот параметр вообще нужен. Оказалось, что карточка все равно выводится норм. (в том числе и имя категории подтягивается), не считая показанного мной сообщения. А я вижу, что вы так ничего и не поняли. Мог бы сразу плюнуть и пройти мимо, как вы того хотели. Но обычно делаю несколько попыток призвать к разуму. Я их сделал. Успехов.
Хорошо, я опишу для чего он нужен подробнее. Точнее опишу почему товар показался и вроде бы нет изменений, если не присмотреться поближе. Товар отображается по id товара, но его категория в breadcrumb не отображается если убрать id категории. Посмотрите внимательно и я думаю Вы это заметите. Также не раскроется меню категорий на нужном уровне, так как Вы не дадите ему id категории, в котором лежит этот товар. Если мы друг друга не поняли, и Ваши цели были действительно продуктивны, то я надеюсь мы поладим.
Похоже, только для вас это проблема. Что мешает брать category_id из записи товара, а не из адреса его карточки? Зачем городить костыли на ровном месте?
Не вижу проблемы. Решений как это сделать можно еще десяток привести. Если это принципиально, то я могу выдрать его и из товара. В чем будет профит кроме более короткого url? Если аргумент действительно принципиальный, то можно переделать. Просто легче взять id из урла чем прописывать в каждом лайере объект. Кстати еще в титле id категории есть.
Кстати, так-то товар может быть в нескольких категориях каталога (не про этот движок, в этом не смотрел).
Пока такого нет, но думаю можно такое сделать. Если потребность такая будет, то реализовать вполне можно.
Готов пожертвовать клиентами, которым это «надо». Или речь просто об участии товара в разных «таксономиях»? --- Добавлено --- Также можно аналогом тегов связывать товары, т.е. без иерархии.
И это не только про реализацию. Не хочу выслушивать вой по поводу дублей карточек в разных ветках каталога. На серче такое периодически наблюдал. --- Добавлено --- Проще и логичнее сделать «товары-ярлыки», чтобы угодить всем.
Можно parent_id для товара перевести на json тип поля, как это у меня работает в качестве noSQL повсюду, и забить любое количество категорий. Такой аналог алиаса. Но больше будет работы как это красиво добавлять. Придется выводить еще раз дерево и в нем выбирать нужные категории. Если будет спрос, то можно, а так лучше более полезные вещи сделать за то же потраченное время. Да и согласен, может начаться вой, так как начнет в поиске выводить множество дублей и т.п.
Да, собственно, в своё время так и делали, у товара была основная категория и ссылки на него из других категорий. В поиске "ярлыки" не участвовали, если ничего не путаю.
Так как поступило много вопросов по безопасности приложения от русскоязычных и зарубежных коллег, то я подготовил страницу в WIKI проекта. Многие не понимают есть ли вообще какие то защиты или их нет, так как глубоко не копались еще в коде. WIKI - https://github.com/musicman3/eMarket/wiki/Protective-measures Там перечислены основные меры безопасности, которые приняты в приложении. Это должно снять основную массу вопросов. Также приветствуются советы, которые позволят еще больше поднять безопасность приложения. Если где-то найдется уязвимость, то пожалуйста, сообщите о ней если точно уверены что она есть и ее можно воспроизвести.
Сделан помощник установки (легкая инсталляция). Помощник автоматически скачает последний релиз с GitHub и распакует его на сервере. После распаковки будут удалены все вспомогательные файлы и произойдет редирект на страницу установки магазина, где необходимо ввести данные по серверу и завершить установку. Таким образом мы избегаем битых файлов при копировании на сервер (если конечно они не в .zip с последующей распаковкой силами сервера), и существенно ускоряем заливку файлов на сервер. Это бывает частая проблема у новичков. А также имеем один маленький файл, который всегда распакует последний релиз магазина с GitHub. Скачайте файл помощника: https://github.com/musicman3/eMarketHandler...ain/install.zip Ознакомиться с кодом файла можно тут: https://github.com/musicman3/eMarketHandler/blob/main/install.php Так как файл одиночный на пустом сайте, то конечно же никаких классов в нем быть не может. Только функции. Файл простой, можете применять для своих проектов. Всегда скачает и распакует последний релиз и подчистит за собой, в том числе и себя удалит. Как пользоваться: Распакуйте файл install.php в пустой корневой раздел сайта и откройте страницу http://localhost/install.php Подробнее: https://github.com/musicman3/eMarket/wiki/Installation
Доработал помощник инсталляции так, чтобы он теперь устанавливал отдельно zip-файл проекта с GitHub и отдельно пакеты composer. Т.е. теперь на гитхабе не нужно хранить в папке vendor пакеты composer. Это все теперь автоматически скачивается при инсталляции и устанавливается в соответствии с правилами composer.json из репозитория пакетов. Если хостинг не поддерживает команды для выполнения программ в PHP (типа system, exec и т.п.), то composer.phar вначале распакуется на сервере, а затем уже локально подключатся классы композера и выполнится локальная команда composer install. После установки все подчищается. Кроме того теперь есть визуализация прогресса при инсталляции с описанием текущего действия во время инсталляции.