Ну так механизм произвольных полей в WP есть, ты можешь через update_post_meta() и get_post_meta() записать и получить любые произвольные поля. И минимальный интерфейс для этого в админке тоже есть. ACF делает ровно то же самое, но оборачивает это в свою дополнительную логику. Но самое важное, что делает ACF - это избавляет тебя от необходимости писать все эти метабоксы для заполнения этих полей в админке. Что, в принципе тоже можно сделать, но ACF дешевле, чем работа разработчика) $50 на покупку PRO версии в бюджет сайта заложить не проблема.
public class OrderService
{
public function create(Request $request)
{
// Создание заказа
// Резервирование товаров
$sms = new RuSms();
// Устанавливаем номер и текст сообщения и уникальный идентификатор приложения
$sms->send($number, $text, $appId);
}
}
А потом вообще в сервисе метод create ничего не принимает и ничего не возвращает.
public function create(): void
{
// Создание заказа
// Резервирование товаров
$this->sms->send($nubmer, $text);
}
Самое смешное когда ты видишь в и-нете примеры реализации, видишь документацию, которой эта реализация соответствует, но у тебя это не работает
Скорее всего вы что-то недопоняли. Подключить скрипт — нет ничего проще. Начиная с того, что можно просто прописать тег script в файле с хедером/футером темы (если речь про плагин, то так не получится), но при этом задать правильный адрес к файлу, что бы он не отваливался.
Или же, если нужно сделать все по-правильному, что бы можно было управлять версиями, зависимостями, порядком, положением (в head или перед /body), локализовать скрипты, кешировать и минифицировать — то нужно использовать register и enqueue script/style. А вам достаточно было написать два вызова
wp_enqueue_script()
БЕЗ использования
wp_register_script()
Если пишите тему, то идете в functions.php и добавляете свой экшн в хук 'wp_enqueue_scripts'
Одно дело если бы вы написали свою абстракцию, которая бы не зависела от CMS/фреймворка. Это было бы оправданно.
Но вы же написали тонну кода поверх существующих абстракций WP. Ваше решение же нельзя перенести на другую CMS/фреймворк без правок вашего класса.
Теперь мы можем сменить WordPress на что угодно и переписать придётся только класс
Registrar, не надо заменять все вызовы wp_register_script и wp_enqueue_script и следовать логике WordPress`а.
И следующий разработчик вместо того, что бы подключить два скрипта характерным для данного фреймворка способом (я уверен, почти везде это две строчки кода) вынужден будет ковыряться в вашем классе и править методы подключения… да он выкинет ваши классы и просто подключит так, как это принято на данной конкретной платформе.
Я бы, если бы был консультантом на стороне заказчика, точно бы не заплатил за время, которое вы потратили на свою абстракцию.
Решение было протестировано для главной страницы и там оно работало, позже выяснилось что для страниц с адресом example.com/about, решение не работало, потому что браузер пытался подгрузить example.com/about/e-cryptex.js и браузер получал — ошибку 404, потому что файл реально лежал в корне — example.com/e-cryptex.js .
про относительный и абсолютный адрес не слышали?
человек не знакомый с WordPress ни чего не поймёт — придётся лезть в справочник что бы понять назначение функций wp_register_script() и wp_enqueue_script()
судя по всему, такой человек именно вы.
явно делается одно и то же два раза подряд, аргументы только разные — нарушается DRY
вытекает из предыдущего. Нет, делается не одно и то же.
Работать «за еду» не стоит никогда, ни в каком случае. Любой труд должен оплачиваться, даже если это «стажировка»
Ну так механизм произвольных полей в WP есть, ты можешь через update_post_meta() и get_post_meta() записать и получить любые произвольные поля. И минимальный интерфейс для этого в админке тоже есть. ACF делает ровно то же самое, но оборачивает это в свою дополнительную логику. Но самое важное, что делает ACF - это избавляет тебя от необходимости писать все эти метабоксы для заполнения этих полей в админке. Что, в принципе тоже можно сделать, но ACF дешевле, чем работа разработчика) $50 на покупку PRO версии в бюджет сайта заложить не проблема.
Потом ожидается в этом методе Request
А потом вообще в сервисе метод create ничего не принимает и ничего не возвращает.
Новичок здесь запутается полностью)
Скорее всего вы что-то недопоняли. Подключить скрипт — нет ничего проще. Начиная с того, что можно просто прописать тег script в файле с хедером/футером темы (если речь про плагин, то так не получится), но при этом задать правильный адрес к файлу, что бы он не отваливался.
Или же, если нужно сделать все по-правильному, что бы можно было управлять версиями, зависимостями, порядком, положением (в head или перед /body), локализовать скрипты, кешировать и минифицировать — то нужно использовать register и enqueue script/style. А вам достаточно было написать два вызова БЕЗ использования
Если пишите тему, то идете в functions.php и добавляете свой экшн в хук 'wp_enqueue_scripts'
Выглядит это, примерно, так
и все.
Одно дело если бы вы написали свою абстракцию, которая бы не зависела от CMS/фреймворка. Это было бы оправданно.
Но вы же написали тонну кода поверх существующих абстракций WP. Ваше решение же нельзя перенести на другую CMS/фреймворк без правок вашего класса.
И следующий разработчик вместо того, что бы подключить два скрипта характерным для данного фреймворка способом (я уверен, почти везде это две строчки кода) вынужден будет ковыряться в вашем классе и править методы подключения… да он выкинет ваши классы и просто подключит так, как это принято на данной конкретной платформе.
Я бы, если бы был консультантом на стороне заказчика, точно бы не заплатил за время, которое вы потратили на свою абстракцию.
про относительный и абсолютный адрес не слышали?
судя по всему, такой человек именно вы.
вытекает из предыдущего. Нет, делается не одно и то же.
Еще, неплохо бы формировать абсолютный адрес для подключаемых ассетов. Сделать это можно через для тем, или для плагинов.
И да, оно того не стоило. Сейчас ваша статья выглядит как — «я не знаю как подключать ассеты в WP, поэтому я изобрету свой велосипед»