> Селекторы(подмножество jquery)
Позволю себе пару замечаний. Они не то чтобы очень важны, но, как мне кажется, полезны.
Во-первых, sizzle - это не подмножество jQuery, это вполне себе самостоятельная библиотека, которая, да, входит в состав jQuery.
Во-вторых, для работы с DOM в Angular по умолчанию используется jqLite (https://github.com/jstools/jqlite), библиотека, которая, хоть и воспроизводит методы jQuery (не все, и с некоторыми ограничениями), не является собственно jQuery, её частью или форком.
Сергей Протько: >, конкатенация это заимствованное слово, которое используется для описания проблемы сцепления линейных структур. В частности в нашем случае - строк.
Я умею читать, и мне, как правило, достаточно одного раза =) Уважаемый, я не говорю про иные контексты. Я говорю про этот контекст. Чем фраза "объединение css-файлов" хуже и непонятней, чем "конкатенация css-файлов"?
Сергей Протько: вообще-то слово "объединение" полностью подходит в нашем случае (если нет - обоснуйте), но если оно вам так не нравится, используйте "склеивание". Реально не понимаю, зачем использовать инородные слова там, где есть прекрасная возможность обойтись без них.
Руслан Макаров: я догадался. Вот это вот - "$var = " - скажем так, небольшой хинт, упрощающий жизнь. Как выше написано, в два раза меньше обращений к функции будет. Еще к вопросу об оптимизации: если все эти мета поля относятся к одному посту, то не дергайте по сто раз get_post_meta, соберите все метаданные в одну переменную с помощь get_post_customs, с ней и работайте.
Кроме того, не забывайте про
а) memcached
б) OPcache
в) Финальное кеширование фронта в статические файлы. Этот вопрос уже решается плагинами, самые популярные, вроде бы - WP Total Cache и WP Super Cache (последний - непосредственно от Automattic, но попроще).
Я скажу так: 30к в сутки - это совсем немного для вашего сервера. Вот совсем немного. Со всем кешированием и отдачей статики через nginx, он и сто-двести тысяч сможет обслуживать без проблем. Может, и больше, но у нас таких клиентов еще не было, поэтому тут опыт заканчивается =)
Дмитрий Бойко: имхо, оптимальным вариантом было бы рисовать так, чтобы на вашем мониторе было нормально. Но при этом хотя бы в голове себе представлять, каким образом это всё будет ужиматься до 700 пикселей, к примеру. Ну, и в обратную сторону, до высоких разрешений, тоже. Если же версткой будет кто-то еще заниматься, то нужно сделать два-три макета для разных разрешений, чтобы верстальщику было от чего отталкиваться. Впрочем, тут уже зависит от сложности первого блока и его насыщенности элементами.
> div нехорошо в < a >
у вас устаревшие данные. В HTML5 тег < a > (дурацкий тостер, ну не могли они простой маркап прикрутить?) формально более не является инлайновым и вполне может содержать любые другие теги: www.w3.org/TR/html-markup/a.html#a-changes
GaserV: магии никакой нет. Важно, что именно вы передаете в функцию. E - это хз что такое. event - это глобальный объект window.event. В самой функции буква e - это просто название входящего параметра, вы можете называть его как угодно. Хоть е, хоть glavryba, как угодно, всё равно этот параметр будет виден только внутри самой функции. Почитайте про замыкания.
>если скрипт запустится до вывода переменных, переменные доступны не будут.
С чего бы ему запускаться до? Или вы не умеете управлять приоритетами? =)
>который решил переместить скрипт в head.
Сам себе злобный буратино?
Дело не в убеждениях, дело в чистоте и семантике кода. Еще раз повторю: wp_localize_script - это один большой костыль, о чём разработчикам прекрасно известно.
dimasmagadan: драгоценный, кодекс мною за пять лет вызубрен от корки до корки. И уж поверьте, мне прекрасно известно, что если про костыль написано в этом самом кодексе, костылём он от этого быть не перестаёт. Нет, это неправильный способ. Неправильный, нелогичный, несемантичный.
>что с вашим подходом данные будут доступны скрипту.
Бгага, с чего бы?
