ТёмнаяМатерия: да, примерно так) А насчет второго - тут все зависит от архитектуры проекта в целом) В принципе, если за обработку действий и вывод самой формы отвечают разные части приложения, проблем быть не должно, т.к. есть четкое разделение.
ТёмнаяМатерия: нет, в том и суть, что он должен быть одноразовым. Сессия может быть долгой, и вполне можно каким-либо образом получить токен. В целом да, можно менять при каждом обновлении страницы.
Владислав Старцев: это невероятное количество лишних, ненужных и раздражающих операций. Хотя когда заходит речь о лишнем клике в интерфейсе, или паре лишних строчек кода, сразу начинается - и конверсия у них снижается, и код становится с душком... вся суть
MonkAlex: суть не в переключении, а в том, что он переключает автоматически не там, где надо. Пишешь css-правило, а он в этот момент транслитерирует его в кириллицу. Вырубать программу для всей IDE совершенно не хочется, потому что часты случаи, когда нужно переключение с кириллицы на англ (например, я искал что-то в гугле на русском). Это, конечно, мелочи, но это очень удобно, когда работает как надо. Люди порой оптимизируют куда менее значащие вещи.
MonkAlex: поверьте, постоянно переключать раскладку - это лютая боль. Это как спокойно писать код на чистом css и не напрягаться, а потом попробовать препроцессоры.
Денис Аникин: правильно оставлять языковые файлы в папке плагина, т.к. папка в wp-content не для этого. Плагины от сторонних разработчиков локализуются через папку {plugin-name}/languages, как я и подсказал изначально. Вы же не будете каждый раз таскать файлы из плагина в wp-content вручную, при обновлении или переустановке? Раскидывать файлы компонента по папкам, как в Джумле, в WP, к счастью, не принято.
Если это не ваш плагин, можете даже указать автору на его ошибку, законтрибутив изменения на гитхаб. Думаю, он будет рад)
Денис Аникин: зачем тогда спрашивали?) Работает - не трогайте. Nariman Nourgaliev все дело в том, что когда плагин создан корректно и в соответствии с кодексом, локализация не будет работать без корректного именования, т.к. предполагается, что автор использует load_plugin_textdomain. Но к сожалению многие плагины даже js \ css подключают некорректно, что уж говорить о локализации. Тот же akismet, посмотрите, как он сделан.
index0h: но смотрите: в обычном проекте среднего размера true-way, как правило, представлен десятком переменных в variables.scss. В каждой переменной - глубина определенного элемента, например, $depth-modal: 1000, $depth-main-menu: 100, и так далее. Чем больше проект, тем больше этих переменных, приходится беспокоиться о том, как бы не нарушить порядок, если нужно встроить новый элемент между ними. Это некрасиво, и это геморрой, и в целом у меня данный подход не вызывает энтузиазма.
В описанной мной концепции работа с глубинами не потребует усилий от разработчика. Ни одной переменной. Просто функции, которые при компиляции будут генерировать нужные значения. Разработчик просто единожды укажет, ниже какого слоя должен располагаться данный элемент, и все, можно забыть об этом. Даже если появится еще несколько слоев, при компиляции значения будут перерассчитаны. Например.
.selector { // ... }
.selector2 {
z-index: above(.selector); // тут будет 1, т.к. у .selector z-index по умолчанию auto, что можео расценить как 0
}
Как-то не верится, что такого не существует, наверняка есть минимум одно решение с хитроумными названиями. В 6000+ плагинов-то...
Чтобы в less \ sass работало то, что я ищу, нужно, чтобы была функция, позволяющая вытягивать какое-либо свойство из селектора в переменную. Хотя бы. Но такого там нет.
Но там нет подобной функции. Даже если извратиться и сделать сложный миксин, это все равно не будет тем, что нужно - придется где-то задавать и явно передавать глубины. Или я не прав?
