Александр Лебедев: вопрос - это у вас просто файлы в папке? они не отдаются веб-сервером? если да - то в этом причина - такие действия запрещены браузером. В консоль посмотрите, должен ругаться
Александр Лебедев: вообще да. вот пример норм того, что должно выдаваться в заголовках ответа чтоб сразу все подхватилось:
Content-Type:application/json; charset=UTF-8
у Вас скорее всего выдается так:
Content-Type:text/html; charset=UTF-8
из-за этого и не получается. Проверяли с примером что я писал выше?
Михаил Аброскин: "ни каких доп библиотек цеплять нельзя" - это почему же?
"смысл изза простейшей задачи сразу цеплять сторонние библиотеки? " - я к примеру ленивый, и на такую мелочь писать свои обертки мне лень. Если там пара полей - то ок, но если больше - возьму лучше такой компонент и буду радоваться.
по безопасности - светить методы бэкэнда в формах как-то странно.
лучше бы спросили, не просто так пишу же что такое решение лучше выкинуть. Гляньте в логи чтоль, вы в статическом методе вызываете $this->method
если хотите передавать значение снятого чекбокса - перед ним ставьте поле hidden с тем же аттрибутом name
еще ссылка - php.net/manual/ru/function.filter-input.php
еще эпизод - мне никто не мешает поменять код в html на
и радоваться рекурсии без выхода
Карл Кремень: напрямую вы не запретите дергать что угодно, что есть в системе. Если хотите ооочень жестко проверять что модуль действительно будет использовать только то, что есть в системе и ничего более, то смотрите здесь - php.net/manual/ru/book.reflection.php. можно проверять заданы ли соответствующие свойства, определены ли нужные интерфейсы и много чего еще. В случае несоответствия выбрасываете исключения, но даже так это можно обойти.
или же смотрите в сторону https://zephir-lang.com/ и оформите свой код как расширение, так точно скроете детали реализации, а интерфейсы подскажут конечным пользователям что нужно реализовывать в рамках модуля и что они могут использовать
Карл Кремень: смотрите, к примеру есть у вашего модуля один контроллер. Хорошо, он должен делать что-то полезное и как можно меньше знать о всей остальной системе. Ему нужно брать данные для работы откуда-то, так что ему нужна какая-либо связь с хранилищем.
Далее - ваш репозирорий/модель для модуля/сущность active record/что-то что общается с хранилищем должно данные откуда-то доставать и не знать ничего более.
Получается, что ваше ядро создает экземляр вашей сущности для работы с данными, передает ей с какой таблицей оно работает, передает ей что-то что может достать данные из хранилища. После всю эту сущность передаем контроллеру модуля, который уже будет дергать методы этой сущности.
Если хотите как можно сильнее ограничить модуль, то можно написать интерфейсы для сущностей, на их основе реализовать такие базовые сущности для таблиц, с которыми будут работать модули, а потом с помощью контейнера зависимостей объявить связи сущностей с интерфейсами и уже их передавать в типа контроллер модуля. тогда можно будет обойтись одним файлом
например выйдет так https://gist.github.com/MetaDone/4ad23763b3027e116...
junothan: тогда второй в списке - там все прицеплено к WooCommerce, а в нем есть события и фильтры на каждый чих - можно подцепиться на любом этапе и сделать что задумали
Сергей Протько: В gearman тоже можно сбагрить все задачи в одну очередь, да и он простой очень. В контексте изначального вопроса - без разницы что выбрать, в остальных случаях - по ситуации наверно
alovanton: на основании той информации что есть подробнее сказать пока не могу, могу порекомендовать переписать конфиг nginx по образу и подобию рекомендаций из документации https://codex.wordpress.org/Nginx
большую базу лучше из дампа залить так