Как задавать переменные JS из админки Wordpress?

Question

[Сергей Горчаков]

Для php я создавал специальную страницу настроек в Wordpress, в которой администратор сайта мог указывать переменные параметров и эти переменные выводились бы специальным кодом в нужном месте сайта. Например, есть калькулятор на php. Чтобы админу не лезть в код, он просто заходит в админку, указывает значения переменных калькулятора, меняет цены и всем удобно, всем хорошо.
Сейчас у меня калькулятор на JS. Можно ли как-то аналогично вывести переменные в админку, чтобы админу не пришлось лезть в сам скрипт для изменений?

Answer 1

[Дмитрий Королёв]

Чертовщина какая-то. Зачем локализатор-то использовать, господа? Он нужен, не побоюсь этих слов, для локализации, для перевода. А для вещей, которые хочет сделать ТС, существует такая штука, как JSON.

1. Создаёте в php массив с нужными параметрами.
   
2. json_encode
   
3. Выводите это всё через wp_head
   
4. В JS делаете JSON.parse и радуетесь жизни
   

Так (в смысле - используют json для передачи переменных в JS) делает Google, так делает Stackoverflow (смотрите исходный код), так делают все нормальные люди. И вы так делайте.

Comments

[Sergiu Mitu]

и все же я не понял чем вам так wp_localize_script не понравился? из за того что в нем есть слово localize? через wp_head тоже можно вывести конечно, но wp_localize_script делает ровно то же самое, только делает он это непосредственно перед указанным скриптом. А данные можно конечно и через json передавать, тут я с вами соглашусь.

[Дмитрий Королёв]

Мне не нравится использование костылей (а wp_localize_script в нынешнем его виде - это один большой костыль, и, уж если его приходится использовать, то желательно только для локализации - и ничего более). Особенно, если есть, скажем так, более правильные способы для передачи с сервера динамических данных.
wp_head был приведен для примера. С тем же успехом можно использовать и wp_footer с высоким приоритетом. Так даже предпочтительней, сайт визуально быстрее будет грузиться, если данных много.

[Дмитрий]

Дмитрий Королёв: вы бы хоть документацию почитали, перед тем, как комментарий писать?

https://codex.wordpress.org/Function_Reference/wp_...
"Though localization is the primary use, it can be used to make any data available to your script that you can normally only get from the server side of WordPress."

именно эту функцию и нужно использовать для добавления данных. это и есть правильный способ.

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

ну и нет гарантии, что с вашим подходом данные будут доступны скрипту.

[Дмитрий Королёв]

dimasmagadan: драгоценный, кодекс мною за пять лет вызубрен от корки до корки. И уж поверьте, мне прекрасно известно, что если про костыль написано в этом самом кодексе, костылём он от этого быть не перестаёт. Нет, это неправильный способ. Неправильный, нелогичный, несемантичный.
>что с вашим подходом данные будут доступны скрипту.
Бгага, с чего бы?

[Дмитрий]

Дмитрий Королёв:
> Бгага, с чего бы?
с того бы.

если скрипт запустится до вывода переменных, переменные доступны не будут.
не все скрипты должны срабатывать по $(document).ready некоторые нужно запускать раньше. с вашим подходом будет ошибка.

ну и представьте ситуацию:
вы делали сайт, сделали там вывод переменных по своему, прицепили к футеру и скрипт и, чуть выше в футере, свой чудо-код.
после вас пришел другой разработчик, который решил переместить скрипт в head. С вашими гениальными наработками он не знаком, читал только кодекс WordPress.
Угадайте, будет ли скрипт работать, если подключить его в хедере, а переменные вывести в футере?

Да, эту ошибку поправить можно, но при использовании wp_localize ее бы вообще не возникло.

"гениальные" решения хороши, но в обычной жизни стоит использовать то, что написано в документации. Даже если это входит в противоречие с вашими убеждениями.
Следующий программист, взявшись за работу над сайтом написанным строго по документации, скажет вам спасибо.

[Дмитрий Королёв]

>если скрипт запустится до вывода переменных, переменные доступны не будут.
С чего бы ему запускаться до? Или вы не умеете управлять приоритетами? =)

>который решил переместить скрипт в head.
Сам себе злобный буратино?

Дело не в убеждениях, дело в чистоте и семантике кода. Еще раз повторю: wp_localize_script - это один большой костыль, о чём разработчикам прекрасно известно.

[Дмитрий]

Дмитрий Королёв:
>Или вы не умеете управлять приоритетами?
я умею. вы тоже. но в интернете кроме нас есть еще программисты, некоторые могут это не уметь. зачем создавать проблему на пустом месте для них?

>>который решил переместить скрипт в head.
>Сам себе злобный буратино?
в конце концов, сам заказчик может решить переместить скрипт (например, ему кто-то сказал, так будет лучше).

wp_localize_script решает все эти проблемы (данные всегда будут перед скриптом, не нужно изучать кастомный код).

опять же, уже писал. может быть своя логика подключения скриптов.
например, показывать скрипт только на одной странице, и только для зарегистрированных пользователей.
с вашим подходом этот код нужно будет дублировать в функции для вывода переменных.
Это так для дополнительной чистоты кода делать нужно?

и чем вам кажется "не семантичным" или "не чистым" тот код, что выводит wp_localize_script?
Что по вашему не так с функцией? Хотите в json данные выводить - берите массив, кодируйте его в json, цепляйте к этой функции, В чем проблема?
она работает, описана в документации, работу выполняет отлично, никаких дополнительных странных действий делать не нужно. почему "костыль"?

не нравится название, сделайте функцию-обертку wp_add_var_to_script, которая будет вызывать wp_localize_script)

Answer 2

[Дмитрий]

не обязательно использовать произвольные поля.
если значения хранятся у вас в опциях, выводите их сразу из опций.

страницу с опциями можно создать тут:
wpsettingsapi.jeroensormani.com

если скрипт калькулятора у вас добавлен корректно (через wp_regisrer_script или wp_enqueue_script), то добавить переменную к этому скрипту нужно через wp_localize_script

добавлять лучше не по одной переменной, а сразу все в одном массиве. например так

wp_localize_script('main','os',array(
	'ajaxurl'=>admin_url('admin-ajax.php'),
	'tClose'=> __('Close (Esc)','text_domain'),
	'tLoading'=> __('Loading...','text_domain'),
	'tError'=> __('Unable to load <a href="%url%">link</a>.','text_domain'),
	'tPrev'=> __('Previous (left)','text_domain'),
	'tNext'=> __('Next (right)','text_domain'),
	'tCounter'=> __('%curr% from %total%','text_domain')
	)
);

в этому случае они будут доступны в таком виде
os.ajaxurl, os.tClose и тп

если же скрипт вы добавили напрямую, в код, то добавить переменные можно добавив action к wp_header. так делать не правильно, но, если по какой-то причине не можете сделать вывод скрипта через стандартные функции, подойдет.

Answer 3

[Sergiu Mitu]

Произвольные поля + wp_localize_script

Пример использования через ACF

wp_localize_script('script_name', 'variable_name', get_field('field_name', 'options'));

Comments

[Дмитрий Королёв]

Использовать локализатор для задания переменных? Вот уж костыль из костылей.

[Sergiu Mitu]

Дмитрий Королёв: ваш комментарий очень полезен, спасибо.
Предложили бы лучше вариант 'без костылей'.

[Дмитрий Королёв]

Сергей: я знаю правила интернетов, не переживайте. Мой вариант ниже.