Модератор
Юрій
(@yube)
Сейчас придет злой Atrax и пошлет к кактусу с кактусовой сборкой :))))
Не надо удалять все данные! Жалко же.
У Вас еще есть вордпрессы на этом хостинге? Понимаете, за три с лишним года я только один раз встречался с ситуацией, когда чистый, без плагинов и прочих довесков, WP делал неправильные выборки из базы, и это была дремучая версия движка на чуть ли не бета-версии mysql. Поэтому хостинг на последнем месте в ряду подозреваемых. Но если все остальные подозреваемые не виновны, то…
Не знаю. Сдаюсь.
Нет на этом хостинге больше нет сайтов! Другие на другом хостинге! Так прочто я ж не смогу перезалить бекап с этого хостига на другой, для пробы, там же домен тоже другой?
А почему оно работает, когда пользователь залогинен, может от этого надо думать?
Модератор
Юрій
(@yube)
А почему оно работает, когда пользователь залогинен, может от этого надо думать?
Оно-то так, но я даже примерно не представляю, каким боком юзер может влиять на подмену условия «post_date =» на «post_date <«. Хорошо бы посмотреть, какие SQL-запросы порождаются.
Кстати, влияет «юзер залогинен», «смотрит автор постов» или «админ на сайте»?
Любой залогинен пользователь, даже если подписчик заходит, то всё работает!
Скажите пожалуйста в каком файле прописывается «post_date =»? Может как-то цикл начинается, но не заканчивается и тогда работает до конца!
А как посмотреть, «какие SQL-запросы порождаются»?
Модератор
Юрій
(@yube)
То я условно написал, что = меняется на <. Реально там всё гораздо страшнее:) Запрос формируется в /wp-includes/query.php из кучи мелких кусочков, типа
where .= " AND MONTH($wpdb->posts.post_date)=" . substr($q['m'], 4, 2);
Посмотреть можно двумя способами: плагином wp-tune (кажись так) или установкой константы SAVEQUERIES в true и выводом в шаблоне массива $wpdb->queries (пишу по памяти, могу буковки перепутать).
Поставил плагин, что там надо смотреть или делать? Вот что он выдаёт:
WP Tuner
This plugin is only visible to site admins. (Update settings here; Visit MrPete at ICTA for bouquets/brickbats/help. Love it? Fill the Tip Jar.)
Analysed in 0.003 seconds.
Время рендеринга: 0.287 секунды cpu (97% загрузка, 0.062 запуск). Время: 0.294 секунды (1.4% на запросы). Запросы БД: 8, нет дефективных, нет > 0.500 секунды. Память: 24.6MB
Анализ производительности
Запросы, вызываемые плагинами вызывают функции Ядра относятся к: Плагин
Строки, подсвеченные желтым показывают медленные элементы (более чем 0.500 секунд)
Производительность генерации страницы (Порядок: хронологический)
(Техническое примечание: Если буферизация вывода (OB) не включена при инициализации, WP Tuner включит его чтобы отслеживать размер вывода.)
Index Marker %Time %DB Time %DB Count Time DB Time DB Count Memory Output
(милисекунд) (милисекунд) (kb) lev(bytes)
0 Start 49 40 13 144.3 1.7 1 ?
1 plugins_loaded 28 23 25 82.0 1.0 2 15,035.4 0()
2 widgets_init 1 0 0 2.4 0.0 0 20,918.7 0()
3 init 18 20 25 52.1 0.8 2 21,055.7 0()
4 admin_init 1 7 13 4.3 0.3 1 24,952.5 1(0)
5 admin_head 2 5 13 5.7 0.2 1 25,056.9 1(1521)
6 admin_notices 1 5 13 3.0 0.2 1 25,135.3 1(13312)
7 admin_footer 0 0 0 0.1 0.0 0 25,110.8 1(25058)
8 Стоп 25,112.6 1(25058)
Total 100 100 100 293.9 4.2 8
Производительность SQL запросов плагина / темы (Порядок: Время DB)
Code Name %DB Time %DB Count DB Time DB Count
Рубрика (msec)
-Ядро- (другое) 40 13 1.7 1
-Ядро- wp-admin 37 63 1.5 5
-Ядро- wp-settings.php 23 25 1.0 2
Total 100 100 4.2 8
Производительность таблиц SQL (Порядок: Время DB)
(Техническое примечание: Первая таблица в запросе регистрируется здесь; комплексные запросы могут содержать много таблиц.)
Table %DB Time %DB Count DB Time DB Count
(милисекунд)
wp_options 53 38 2.2 3
wp_usermeta 21 38 0.9 3
wp_users 14 13 0.6 1
wp_comments 11 13 0.5 1
Total 100 100 4.2 8
Анализ SQL запросов
8 корректных запросов. Нет медленных, нет некорректных. Показ нормальных запросов отключен.
Модератор
Юрій
(@yube)
У плагина где-то включается вывод самих запросов.
Я обычно делаю так: получаю запросы, сформированные движком (не только WP, а вообще), потом выполняю их в phpmyadmin и смотрю, чего получилось на выходе.
Запросы — это что-то такое:
UPDATEwp_optionsSEToption_value= '1' WHEREoption_name` = ‘wptuner_bShowAll’
[wp-content/plugins/wptuner/wptunersetup.php(349): update_option()]`
Но что с ними далее делать, я так и не понял. Я почти ничего не понимаю в php и в MySQL
Модератор
Юрій
(@yube)
Запросы — это что-то такое:
Да. И нас интересует что-то типа
SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts WHERE 1=1 AND YEAR(wp_posts.post_date)=’2010′ AND MONTH(wp_posts.post_date)=’10’ AND wp_posts.post_type = ‘post’ AND (wp_posts.post_status = ‘publish’ OR wp_posts.post_status = ‘private’) ORDER BY wp_posts.post_date DESC LIMIT 0, 10
Особенно интересен фрагмент YEAR(wp_posts.post_date)=’2010′ AND MONTH(wp_posts.post_date)=’10’ Как несложно догадаться, тут написано, что выбирать нужно те записи, у которых дата публикации имеет год, равный 2010, и месяц, равный 10. (Помните, я писал про = и <? Вот это то самое равно.)
Я почти ничего не понимаю в php и в MySQL
Это очень плохо. Я не умею решать такие проблемы терапевтическими методами, только путем вскрытия.
Ещё проблема в том, что эти запросы видно только для Администратора, а когда я захожу на сайт, как Администратор, то всё и так правильно работает. Как же мне их увидить, когда я не залогинен?
Модератор
Юрій
(@yube)
Хороший вопрос. Видать, придется вторым способом. Хорошо бы на время опытов закрыть сайт от посторонних глаз, поставив пароль через админку хостинга (если знаете, как это сделать). А дальше корневой index.php приводим к виду
<?php
define('WP_USE_THEMES', true);
define('SAVEQUERIES', true);
require('./wp-blog-header.php');
print '<pre>';
print_r($wpdb->queries);
?>
открываем страницу архива, находим внизу кучу полезной инфы и, если не «спрятались», быстренько копируем запросы и возвращаем файлу первозданный вид. Если «спрятались», можно сильно не торопиться.
Всё сделал, но что там точно надо увидеть, то я точно не знаю! Может вы сами гляните, если не сложно!
Модератор
Юрій
(@yube)
Посмотрел и сохранил. Можете убирать отладку.
Вот что мы хотели увидеть:
SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts WHERE 1=1 AND YEAR(wp_posts.post_date)=’2010′ AND MONTH(wp_posts.post_date)=’8′ AND wp_posts.post_type = ‘post’ AND (wp_posts.post_status = ‘publish’) ORDER BY wp_posts.post_date DESC LIMIT 0, 7
Это август, там должно быть два поста. По идее. Дальше стоит выполнить этот запрос в phpmyadmin и посмотреть на результат.
Кстати, обратите внимание, что этот запрос от админского в моем примере отличается только условием wp_posts.post_status = ‘private’, которое на выборку по дате никак влиять не должно.
