Вот и я не понимаю. На самом деле у меня другая проблема, которая волнует - это долгая работа wp_list_comments() - она 50 комментариев к записи выводит по 3-4 секунды (первый раз), почему так долго - понять не могу, пробовал даже древовидные комментарии отключать, вообще толку нет. Мощности сервера избыточные, пхп 7.1, на сайте есть более сложные задачи с которыми проблем нет. Вот я и обратил внимание на эту таблицу, может с ней что не так у меня, больше вообще ума не приложу что может быть. Но по wp_list_comments() я отдельный вопрос задам, как сам все возможные варианты проверю.
Единственное, при анализе запроса (и с моим и с вашим) в 1ом пункте вижу: Using filesort - это вроде как не очень. Можно такое как-то избежать?
1 PRIMARY wp_day_download Using where; Using temporary; Using filesort
2 DEPENDENT SUBQUERY wp_term_relationships Using index; Using where
3 DEPENDENT SUBQUERY wp_term_taxonomy Using where
В таблице wp_day_download у меня есть тип индекса: уникальный по post_id и date. Мне надо сделать такой же индекс, только тип не "уникальный" а "индекс"?
Круто, спасибо! Заменил t3.term_id = 179 на t3.term_id IN (179) - т.к. может быть массив и GROUP BY t1.post_id на GROUP BY t1.post_id ORDER BY SUM(t1.dl) DESC LIMIT 6
$mysite = "site.ru";
preg_match_all('~(.*?)~s', $content, $links);
foreach ( $links[1] as $l ) {
if ( !strpos($l,$mysite) ) {
$content = str_replace($l,'/out.php?url='.urlencode($l).'&id='.$post->ID.'" target="_blank" rel="nofollow', $content);
}
}
Получилось все точно как я хотел и все работает.
К сожалению с preg_replace_callback я не разобрался. Я, если честно, вообще пока что не могу понять регулярки... Подходящий для себя пример нашел только с preg_match_all. Насколько это менее производительно?
Александр N++: Так под "проблемами" я подразумевал вот что: иногда ходят во сайту всякие школо-хакеры и смотрят доступ к файлам, например открывают /wp-content/themes/моя тема/functions.php и тогда им показывается ошибка 500. Если я сделаю сраницу с авто-обновлением на ошибке 500 - не создадут ли такие "хакеры" какой-то нагрузки на сервер?
Хм. А что если ошибка будет не такая как приведена выше, а если школо-хакеры полезут по каким-то скриптам / папкам (тогда ведь то же бывает ошибка 500) - не создаст ли такая страница проблем?
Игорь Воротнёв: Я извиняюсь, но мой уровень это "скопировал - вставил - отредактировал" вы предлагаете в таблицу с рейтингом записывать каждый рейтинг вида: id | user_id | date | exp и получится что, например: если я опубликую 10 постов, 10 комментариев, 10 сообщений на форуме и так до 10 разных типов рейтинга - в этой таблице будет 100 записей только для меня? И потом мне брать тупо всю таблицу за промежуток времени и уже на php считать кто сколько набрал?
У меня пользователи могут публиковать записи, но с модерацией. А вот редактировать могут их уже без модерации. Так что:
1. Если убрать $old_status != 'publish' - тогда каждый раз когда юзер отредактирует свою запись, пост опубликуется
2. По сути я знаю как добавить галочку, но я не знаю как ее использовать... т.е. сам html в нужное место я вставлю, а дальше беда
3. Я не знаю про save_post, это получится что каждый раз при сохранении поста будет какая-то проверка выполняться, а сейчас только если статус поста меняется.
Вообще вся проблема в отправке, в плагине EVC есть такая кнопка, но я не смог оттуда позаимствовать её работу. Там вставляется галочка с ID и затем уже в проверке идет такая фишка
if (($new_status == 'publish' && $old_status != 'publish') OR $_POST['ID галочки'] = че-то там )
Вот я не понимаю как получить этот $_POST['ID галочки']
Игорь Воротнёв: А что по таблице с суточным рейтингом для каждого юзера: обязательно ли создавать столбец id? Сейчас я сделал ее из 3ех столбцов: user_id | date | exp и создал уникальный индекс по 2ум столбцам user_id | date (туда я вставляю данные каждый раз при публикации поста, комментария и т.п. с использованием ON DUPLICATE KEY UPDATE - т.е. если данных за текущую дату для пользователя нет - создаем, если есть - прибавляем эксп)
Спасибо за ответ. Использовать стандартные таблицы под это я не хочу, ибо, например: если я захочу где-то показать общий ТОП пользователей за все время - мне придется работать с большой таблицей wp_usermeta, а если у меня будет таблица total_user_exp - я просто отсортирую данные по колонке exp и получу ТОП пользователей. Так же там придется хранить кол-во опыта за каждый из предыдущих 7 дней (минимум, может я захочу больше) а это под каждого пользователя создавать по 7 доп. строк, а что бы делать выборку - опять же получиться более громоздкая работа для mysql, нежели если будет отдельная таблица в которой я все сгруппирую и отсортирую. Или я ошибаюсь? Ничего плохого в своих таблицах я не вижу.
Melkij: "партицировать" - это слишком сложно для меня. Сейчас я пробую добавить в таблицу новый столбик - diff, в котором будет разница текущего опыта и вчерашнего. Так думаю будет проще считать. Не уверен что это самый хороший вариант, но пока в голову больше ничего не лезет
Вообщем у меня не работают CURRENT_DATE, если выставить даты в sql запросе руками - то все срабатывает. Но появилась другая проблема: я вывел данные не за неделю, а с 1 по 2 марта, в результате на 1ом месте человек который не заходил на сайт 1го марта и данных за эту дату о нем нет. В результате получается что сколько опыта он набрал с 1 по 2 марта = его текущему опыту. Т.е. мне надо либо для каждого пользователя каждый день ОБЯЗАТЕЛЬНО заносить данные, либо менять таблицу. Буду менять таблицу, т.к. каждый день считать эксп для всех тупо.