- wp_register_style необходимо вызывать в хуке wp_enqueue_scripts, иначе могут возникать проблемы - https://core.trac.wordpress.org/ticket/17916
3. $path = get_bloginfo('template_directory') . "/" - зачем такая конструкция? get_template_directory_uri() создана специально для этого.
4. wp_deregister_script('jquery'); - сколько переговорено на эту тему... Вы экономите на спичках, а конфликты у других плагинов с этим бывают. Иногда грузится 2 версии сразу - и родная, и ваша. Иногда плагины просто не видят вашу. Сейчас уже все реже такое происходит, но это есть. Смысл замены jQuery?
5. "У тебя не хватает wp_register_style" - в этом нет необходимости, wp_enqueue_* регистрирует сам, см. документацию и код функции. "Registers the style if source provided (does NOT overwrite) and enqueues."
Это краткий code review без вникания в детали. Вердикт - сильно устаревший подход, применяемый без оглядки на корректное использование API ядра к месту и по сути, с потенциальными гарантированными проблемными местами.
Кроме того, использование одной и той же nonce через 'nonce' => wp_create_nonce('myajax-nonce'), является опасным решением с точки зрения безопасности. Пока оно используется в реальности для 1-2 вызовов каких-то похожих, типа подгрузки постов при скролле - проблемы не будет. Как только функционал растет, и действия на аякс-хуках выполняют разные вещи и требуют разных прав, использование одной nonce может быть опасным.
Евгений Вольф: WP дописывает cache busting сам, по умолчанию - свою версию. Что в данном случае не помогает, конечно же. Поэтому этим параметром можно управлять в функции wp_enqueue_style/wp_enqueue_script - четвертый из пяти аргумент вызова функции - версия файла.
WQP, а кто вам сказал что get_posts очень медленный? Вы код функции смотрели? Она вызывает тот же WP_Query, только с уже предустановленными параметрами. При чем параметрами, которые как раз ускоряют запрос - suppress_filters => true, no_found_rows => true.
Никита Кит: вы бы хоть понимали как работает object cache для начала, да и вообще кеширование разных типов на разных уровнях. В WP в ядре кеширование реализовано чуть более чем целиком. Единственное, что не используется (не навязывается) ни одно конкретное бекенд-решение, именно благодаря этому WP может работать на таком огромном количестве и разнообразии железа и софта самых разных версий. Забросив всего лишь интерфейс для желаемого бекенда в папку wp-content мы получаем возможность кешировать в том бекенде, который нам нужен - memcache, memcached, redis, APC etc. Что является грамотным с точки зрения архитектуры и масштабируемости. В ModX из коробки объектный кеш хранится не в памяти (RAM), а в файлах в папке core/cache что сильно, очень сильно уступает по скорости кешированию в память. Кроме того, в ModX также есть опциональный ключ MODX_CONFIG_KEY в конфиге, который делает ровно то же самое, что WP_CACHE_KEY_SALT - если он определен, то кеш складывается по уникальному адресу для избежания конфликтов - core/cache/MODX_CONFIG_KEY. Подключение кеширования в память в ModX требует заметно больших танцев, чем в WP, порог входа выше. И если его там подключить, то, повторяю, при использовании memcached будет ровно та же проблема - пересечение и конфликт данных от разных сайтов, которые лежат рядом. Потому что это проблема не платформы/CMS, а самого memcached. Например, в Redis такая проблема отсутствует.
Никита Кит: Я вчера поковырял код плагина и свои сайты, которые его используют, и все оказалось проще. Автор вопроса изначально не настроил плагин правильно. Для того, чтобы Memcached Redux корректно работал с несколькими сайтами, достаточно в wp-config.php каждого сайта добавить константу WP_CACHE_KEY_SALT. Этого нет явно в документации плагина, но даже в Changelog есть. У меня они стоят и все работает. Так что проблема не в ломке плагина, а в том, что его попросту забыли настроить. Впрочем, это проблема конкретно memcached и того как он работает, поэтому она касается любых нескольких сайтов на любых платформах/фреймворках/CMS. Если есть данные и таблицы в БД с одинаковыми названиями, они будут конфликтовать между собой. Плагин при наличии константы WP_CACHE_KEY_SALT делает данные уникальными для каждого сайта.
RushV: Так а зачем вы оба фрагмента кода скопировали? Первый - это чистый код для вывода самой ссылки (значения из post_meta) без какого-либо html. Чтобы легче понять. Второй фрагмент - это уже реальный код с html. Удалите первый фрагмент и все будет как надо.
Literator: Хм.. Забавно. Дело в том, что я этот же плагин использую на одном сервере, сразу на нескольких сайтах. И никогда подобной проблемы не возникало.
Дмитрий: get_posts() или new WP_Query() с точно теми же аргументами. query_posts не используйте никогда в жизни. Вот совсем никогда. Забудьте о ее существовании.
Sharapov: Псевдоэлементы для контента в общем понимании использовать не только можно, но и нужно. Собственно, content: "" у псевдоэлементов именно для этого и нужен. Другое дело, что не следует туда писать контент, который должен быть проиндексирован. Если же это наоборот, контент который не должен индексироваться - тогда там ему самое место.
Никита Кит: ssl_ciphers это перечень шифров/сайферов, которые можно использовать. Он имеет отношение к библиотеке opensssl. И да, он может (да и должен) быть одинаковым.
WildJust: Нет, этими фильтрами вы будете модифицировать изначально как раз глобальный, основной $wp_query. На выходе будет именно он, только уже с вашим произвольным JOIN и ORDERBY. И будет вам пагинация, будет все что нужно.
HackOwnB: Дык это надо в задаче писать детально. Вы установили теги PHP и MySQL, логично предположить, что вам нужно удалить это дело средствами PHP. Если же речь идет об удалении кроном, то лучше писать shell-скрипт. Скрипт пусть сканит директорию и формирует временный файл со списком названий файлов для удаления. Далее берем этот файл и удаляем сами файлы с диска + через mysqladmin удаляем нужные записи.
WildJust: нет, в $wp_query не надо. Есть и другие фильтры, но в вашем случае posts_join и posts_orderby - именно то, что нужно. Разберетесь как ими пользоваться? Документация по ссылкам достаточно базовая, но понятная. Если ее мало - гуглите конкретно по названиям этих фильтров, в сети есть тюториалы на эту тему.
Иван: Do things RIGHT. Проблема современной разработки как раз в том, что одни пишут "решения" которые являются костылями, а другие их копипастят не глядя. Хотели как лучше, а получилось как всегда (С) народная мудрость
2. - wp_register_style необходимо вызывать в хуке wp_enqueue_scripts, иначе могут возникать проблемы - https://core.trac.wordpress.org/ticket/17916
3.
$path = get_bloginfo('template_directory') . "/"- зачем такая конструкция? get_template_directory_uri() создана специально для этого.4.
wp_deregister_script('jquery');- сколько переговорено на эту тему... Вы экономите на спичках, а конфликты у других плагинов с этим бывают. Иногда грузится 2 версии сразу - и родная, и ваша. Иногда плагины просто не видят вашу. Сейчас уже все реже такое происходит, но это есть. Смысл замены jQuery?5. "У тебя не хватает wp_register_style" - в этом нет необходимости, wp_enqueue_* регистрирует сам, см. документацию и код функции. "Registers the style if source provided (does NOT overwrite) and enqueues."
Это краткий code review без вникания в детали. Вердикт - сильно устаревший подход, применяемый без оглядки на корректное использование API ядра к месту и по сути, с потенциальными гарантированными проблемными местами.
Кроме того, использование одной и той же nonce через
'nonce' => wp_create_nonce('myajax-nonce'),является опасным решением с точки зрения безопасности. Пока оно используется в реальности для 1-2 вызовов каких-то похожих, типа подгрузки постов при скролле - проблемы не будет. Как только функционал растет, и действия на аякс-хуках выполняют разные вещи и требуют разных прав, использование одной nonce может быть опасным.