Локализация PHP-скриптов WordPress плагина особого труда не составляет. Достаточно много функций на любой вкус в библиотеке WordPress делают этот процесс простым и приятным. Однако со скриптами javascript, которые всё чаще используются в плагинах WordPress, для обеспечения интерактивности, дело обстоит несколько сложнее или, если говорить точнее, не так однозначно. Конечно, если Вы пишете моноязычный плагин, рассчитанный на определённую языковую аудиторию, Вам это не нужно. Но, если Вы расчитываете, что Вашим плагином будет пользоваться всё многомиллионное сообщество пользователей WordPress, стоит озаботиться интернациональностью своего плагина.
Проблема локализации javascript заключается в том, что препроцессор PHP этот скрипт не обрабатывает и, как следствие, динамическая локализация просто невозможна. Таким образом, как Вы уже наверное поняли, вопрос локализации скрипта javascript в WordPress является вопросом передачи данных в скрипт js.
Вопрос этот решается тремя различными методами, имеющими свои преимущества и недостатки. Их мы сейчас и рассмотрим. А какой из них выбрать, это исключительно дело Вашего вкуса, потребностей и возможностей.
Силовой метод
Этот метод хорошо характеризует известная поговорка: «Если гора не идёт к Магомету, Магомет идёт к горе …». Другими словами, если препроцессор PHP не обрабатывает коды javascript, сделаем javascript файл файлом PHP и заставим препроцессор обработать файл на этапе загрузки.
Во-первых, название файла, а точнее, его расширение. Это должен быть файл PHP, например script.js.php или js-script.php и это обязательно.
Во-вторых, файл должен начинаться с PHP-кода и код этот должен задать возможность доступа препроцессора к библиотекам WordPress.
Как видите, всё довольно просто, добавив всего пару строк PHP-кода, мы получили доступ к обширным библиотекам WordPress. Если Вы хотя бы немного разбираетесь в программировании, то Вы уже поняли, что с помощью этого метода можно не только динамически локализовать (подменить строки) скрипт, но и сделать весь скрипт динамическим. Т.е. собирать коды javascript динамически, как пазл, на этапе загрузки, загружая лишь те коды, которые необходимые «в данном месте и в данное время». Всё это естественно относится к плюсам метода.
К сожалению, есть минусы и весьма немаленькие.
Во-первых, как Вы могли заметить, задан явный путь к файлу wp-load.php и изменить здесь что-либо невозможно. Как вариант, можно загрузить wp-config.php и взять из него ABSPATH, но и для включения wp-config.php нужно знать путь к нему … Короче, замкнутый круг …
Во-вторых, загрузка библиотек WordPress — это дополнительная нагрузка на препроцессор, причём, как минимум 250 kb. Согласитесь, при объёме скрипта 1..3 kb загрузка лишних сотен килобайт — это ничем не оправданное растранжиривание ресурсов (хотя и очень удобно …).
Стандартный метод
Этот метод основан на использовании стандартной, малоизвестной функции wp_localize_script. Изначально эта функция была написана именно для получения возможности локализации скриптов javascript, о чём и говорит её название. Однако, способ которым функция передаёт данные в скрипт, позволяет использовать эту функцию для более широкого круга задач.
Как видите, всё очень просто: функция создаёт JSON-объект с данными, заданными в параметрах функции. Этого вполне достаточно для передачи локализованных строк и/или каких-либо других данных Вашему скрипту. Низкая ресурсозатратность этого метода делает его весьма привлекательным. Однако, как Вы понимаете, передача конфиденциальных данных таким способом нецелесообразна с точки зрения безопасности, т.к. эти коды являются открытыми и доступны любому, кто посетит Ваш блог с какими бы намерениями он не пришёл.
Комбинированный AJAX метод
Этот метод реализуется с помощью AJAX запроса.
В скрипте javascript мы создаём ajax запрос и используем полученные данные.
Этот метод использует несколько больший объём кодов, чем предыдущий, но и обладает большей защищённостью данных. К сожалению, у него тоже есть существенный минус, который все же, больше является минусом WordPress. В этом методе, если владелец блога поставил под пароль папку wp-admin, при выполнении запроса пользователь увидит запрос на ввод имени пользователя и пароля для входа в запаролированную папку.
Каждый из трёх методов хорош по-своему и каждый имеет свои недостатки. Каким пользоваться — выбирайте сами …
Проблема локализации javascript заключается в том, что препроцессор PHP этот скрипт не обрабатывает и, как следствие, динамическая локализация просто невозможна. Таким образом, как Вы уже наверное поняли, вопрос локализации скрипта javascript в WordPress является вопросом передачи данных в скрипт js.
Вопрос этот решается тремя различными методами, имеющими свои преимущества и недостатки. Их мы сейчас и рассмотрим. А какой из них выбрать, это исключительно дело Вашего вкуса, потребностей и возможностей.
Силовой метод
Этот метод хорошо характеризует известная поговорка: «Если гора не идёт к Магомету, Магомет идёт к горе …». Другими словами, если препроцессор PHP не обрабатывает коды javascript, сделаем javascript файл файлом PHP и заставим препроцессор обработать файл на этапе загрузки.
Во-первых, название файла, а точнее, его расширение. Это должен быть файл PHP, например script.js.php или js-script.php и это обязательно.
Во-вторых, файл должен начинаться с PHP-кода и код этот должен задать возможность доступа препроцессора к библиотекам WordPress.
Как видите, всё довольно просто, добавив всего пару строк PHP-кода, мы получили доступ к обширным библиотекам WordPress. Если Вы хотя бы немного разбираетесь в программировании, то Вы уже поняли, что с помощью этого метода можно не только динамически локализовать (подменить строки) скрипт, но и сделать весь скрипт динамическим. Т.е. собирать коды javascript динамически, как пазл, на этапе загрузки, загружая лишь те коды, которые необходимые «в данном месте и в данное время». Всё это естественно относится к плюсам метода.
К сожалению, есть минусы и весьма немаленькие.
Во-первых, как Вы могли заметить, задан явный путь к файлу wp-load.php и изменить здесь что-либо невозможно. Как вариант, можно загрузить wp-config.php и взять из него ABSPATH, но и для включения wp-config.php нужно знать путь к нему … Короче, замкнутый круг …
Во-вторых, загрузка библиотек WordPress — это дополнительная нагрузка на препроцессор, причём, как минимум 250 kb. Согласитесь, при объёме скрипта 1..3 kb загрузка лишних сотен килобайт — это ничем не оправданное растранжиривание ресурсов (хотя и очень удобно …).
Стандартный метод
Этот метод основан на использовании стандартной, малоизвестной функции wp_localize_script. Изначально эта функция была написана именно для получения возможности локализации скриптов javascript, о чём и говорит её название. Однако, способ которым функция передаёт данные в скрипт, позволяет использовать эту функцию для более широкого круга задач.
Как видите, всё очень просто: функция создаёт JSON-объект с данными, заданными в параметрах функции. Этого вполне достаточно для передачи локализованных строк и/или каких-либо других данных Вашему скрипту. Низкая ресурсозатратность этого метода делает его весьма привлекательным. Однако, как Вы понимаете, передача конфиденциальных данных таким способом нецелесообразна с точки зрения безопасности, т.к. эти коды являются открытыми и доступны любому, кто посетит Ваш блог с какими бы намерениями он не пришёл.
Комбинированный AJAX метод
Этот метод реализуется с помощью AJAX запроса.
В скрипте javascript мы создаём ajax запрос и используем полученные данные.
Этот метод использует несколько больший объём кодов, чем предыдущий, но и обладает большей защищённостью данных. К сожалению, у него тоже есть существенный минус, который все же, больше является минусом WordPress. В этом методе, если владелец блога поставил под пароль папку wp-admin, при выполнении запроса пользователь увидит запрос на ввод имени пользователя и пароля для входа в запаролированную папку.
Каждый из трёх методов хорош по-своему и каждый имеет свои недостатки. Каким пользоваться — выбирайте сами …