http___blog.pvalley.info__p_133_1.xml
https___michaelrawlins.co.uk_2014_08_dealing-wp_commentmeta-moving-wordpress-databases_.xml
1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 4.1 5.1 5.2 6.1 6.2 6.3 6.4 7.1 8.1 9.1 10.1 11.1 11.2 11.3
Нали знаете какво е убило котката – любопитството. При мен това доведе до над 53 000 спам коментара. Как? Ами цъкнах на една връзка, която ми се стори интересна, въпреки, че знаех, че има риск спамера да разбере, че сайта е активен. Просто бях твърде любопитен. И така, няколко дни след като любопитството надделя над здравият разум, получих email от блога си, че има някакъв коментар за одобрение. Влязох в блога и какво да видя, Aksimet решил, че около 53500 коментара не са спам т.е. нуждаят се от одобрение (както съм настроил блога). Въпреки, че го обнових до последна версия, натискането на бутона „Провери опашката за спам“ не доведе до очакваният резултат. И така бях принуден да разчитам на стандартните инструменти на WordPress. Но изтриването на над 2675 от WordPress трябва да стане страница по страница. Аз определено нямам толкова търпение, за това бързо се отказах. Все пак в категорията спам има бутон „Изтриване на спама“, който трие всички писма в нея. За това реших да направя следното: UPDATE wp_comments SET comment_approved = "spam" WHERE comment_approved = "0" По някаква причина заявката не мина от раз. Останаха около 13 000 коментара и се наложи да я пусна втори път. И така стигнахме до бутона „Изтриване на спама“. За съжаление той не сработи според моите очаквания. След две натискания бройката на коментарите беше намаляла с една 300, а времето което отнемаше за зареждане на страницата след всяко натискане не беше в категорията приемливо (т.е. повече от секунда-две). Поради, което прибягнах до следната заявка DELETE FROM wp_comments WHERE comment_approved = "spam" Разбира се, можеше още от началото да направя, това което ме съветваха сайтовете: DELETE FROM wp_comments WHERE comment_approved = "0" Но нали ми е твърда главата. Разбира се проблемите ми не свършиха до тук, защото базата ми реши да умре малко след това. Но какво да се прави – кофти конфигурация. Едно обаждане до поддръжката и проблема беше решен за секунди.
1.1 1.2 1.3 2.1 3.1 3.2 4.1 5.1 6.1 7.1 8.1 9.1 10.1
I’ve spent a few days moving WordPress sites around between servers recently. A relatively simple if not mundane task, copy all the files from one server to another using SCP in terminal then moving the database, link the two up and all is well. You can move SQL by using command line in terminal, but I prefer to download it, then create a new database & user and upload it to the new server. While I was moving stuff around I noticed that the wp_commentmeta table on some of the sites was particularly big and cumbersome, like 50mb cumbersome So I did a bit of poking around and found that even after comments had been sent to spam and deleted there was still a chunk of information about them sitting in the wp_commentmeta table. After a bit of asking Google and my basic SQL knowledge, I did a comparison of what was in wp_commentmeta and not in wp_comments. To find this out I ran the following query in PHPMyAdmin Select * FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments) I found on one site that had been subject to quite a lot of spam that there were 70,000+ entries in the meta table that didn’t have a comment in wp_comments, this accounted for several mb of data that I really didn’t need to be moving so I took a chance on a site that didn’t matter if I broke it, at deleting anything that was in wp_commentmeta but not in wp_comments by running the following command DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments) it seemed to do the trick, reduced the size of the database significantly and everything continued to work after my mass deletion. So if you find that you have a particularly oversized wp_commentmeta table, maybe this will help you out. Remember, always back up your database before performing any kind of open heart surgery on the tables.