simonebiffi

Also, just realized that when trying to edit an image, whether this being cropping, rotating, or else, the system loops on an endless loading process which can be stopped only by swapping to another tab or refreshing the page.

In few words, I can access the Edit Image editor but unable to operate with any of the functions. Help please! ??

Hi there,

I was looking for answer for this problem too and then applied this trick which worked for me. In wp-config.php add this string:

define('CONCATENATE_SCRIPTS', false);

This will prevent WP to load all scripts at once, will surely slow down your admin experience but guarantee that each one of them doesn’t get overlapped in the loading process. Hope it will help.

OK, found the culprit. The Slow Query issue was generated by a bad behaved bot that was trying to copy material from the website. In case anyone stumbles upon it, the mischievous user agent is: BLP_bbot/0.1
The bot consumes your CPU and you surely don’t want to pay any extra exceeded amount becasue of it, right?

Should you have to deal with it you can block it by inserting the following code into the robot.txt file:

User-agent: BLP_bbot/0.1
Disallow: /

And reinforce your defenses by adding the following to your .htaccess file:

#get rid of bad bots
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^BLP_bbot/0.1
RewriteRule ^(.*)$ https://go.away/

And should the bot find a way to break through again, at that point it will be necessary to source its IP and block it in your .htaccess.

Good luck.

Does anybody know anything about it? Help, please ??

OK, since I found mor appropriate to open another more targeted thread on this, I think it’s appropriate to mark this as resolved. Thanks everybody.

OK, after having tried everything, even installed WP Super Cache to improve performances, but still cannot find a solution in regards of the overload.

The only thing I’m left to think of is that the ‘Category’ and ‘Post’ query in the database are the culprit. If someone knows how to ‘clean’ them, without me compromising the entire DB, that would be fantastic!

OK, so not even the JS seems to be the cause and now it’s getting really frustrating… however, since ‘there are no problems, but only solutions’, let’s see if I can find the right one ??

I ran a Slow Query Analysis on the database (MySQL 4.XXX) and following is a report that I didn’t get before:

### 1 Query
### Total time: 2, Average time: 2
### Taking 2 seconds to complete
### Rows analyzed 10871
use chictoday_com_-_daily;
SELECT DISTINCT object_id, post_title FROM wp_term_relationships r, wp_term_taxonomy t, wp_posts p WHERE t.term_id IN (SELECT t.term_id FROM wp_term_relationships r, wp_term_taxonomy t WHERE r.term_taxonomy_id = t.term_taxonomy_id AND t.taxonomy = 'XXX' AND r.object_id = XXX) AND r.term_taxonomy_id = t.term_taxonomy_id AND p.post_status = 'XXX' AND p.ID = r.object_id AND object_id <> XXX AND p.post_type = 'XXX' ORDER BY post_date DESC LIMIT XXX;

use chictoday_com_-_daily;
SELECT DISTINCT object_id, post_title FROM wp_term_relationships r, wp_term_taxonomy t, wp_posts p WHERE t.term_id IN (SELECT t.term_id FROM wp_term_relationships r, wp_term_taxonomy t WHERE r.term_taxonomy_id = t.term_taxonomy_id AND t.taxonomy = 'category' AND r.object_id = 1524) AND r.term_taxonomy_id = t.term_taxonomy_id AND p.post_status = 'publish' AND p.ID = r.object_id AND object_id <> 1524 AND p.post_type = 'post' ORDER BY post_date DESC LIMIT 5;

As suspected there is something to do with the Category terms, which produce the CPU overload… unfortunately my knowledge stops here. If anybody knows how to correctly interpret the report above and offer suggestions, I’d be TREMENDOUSLY glad! Thanks in advance!

Thanks a mille for the tip; in fact by analyzing the CPU weekend report I was astonished to notice that practically all the categories that were simultaneosly queried at once were all those calling a Java Script to display the header dropdown menu. Those not associated with it were in fact behaving as they always did. I’ve been left now but with the option to remove the script (and consequent dropdowns) from the top menu, thus to understand if this could have been the cause. Will need now to double check the report later today to confirm.

This apparently the infamous JS:

<!-- Java Script for Dropdown Menu -->
<script type="text/javascript">
function showmenu(elmnt)
{ document.getElementById(elmnt).style.visibility="visible"; }
function hidemenu(elmnt)
{ document.getElementById(elmnt).style.visibility="hidden"; }
</script>

And here the calls in the header:

<div class="p_wellbeing" onmouseover="showmenu('wellbeing')" onmouseout="hidemen ('wellbeing')" onclick="location.href='https://www.chictoday.com/category/wellbeing/';" >
  <div class="dropdown" id="wellbeing" >
    <div class="dlink"><a href="" class="ddlink">In the Balance</a></div>
    <div class="dlink"><a href="" class="ddlink">Social Trends</a></div>
    <div class="dlink"><a href="" class="ddlink">Intimacy</a></div>
    <div class="dlink"><a href="" class="ddlink">Sustainable Life</a></div>
    </div>
</div>

In case you want to see the code, I can do better than posting the page on wordpress.pastebin.ca; if you want I can upload a .zip of the entire theme onto the server for you to download; just let me know and I will post a direct link to it.

Last but not least, the single function to prevent all the IFs conditions. Forgive my ineptitude on this, but I am confused as per how it would work. From the code above it seems to me that it ought to be created 2 .php files for each individual category? One cattemplate-$catID.php whitin which insert the <?php include function > and the final file which is actually the page that will be ultimately loaded, right (e.g.: article_in_the_balance.php)? If so, I assume I would find myself with quite plenty of files around?

Anyway, let’s see if the JS is the casue, and then I will surely try to implement the suggested function above.

Thank for the hints, vtxyzzy.

Each individual post is always categorized under one sole category, never to two or more.

The ‘global $chic;’ variable is set within an external ‘config.inc’ file that in fact sets individual categories as follows:

$chic['wellbeing_id'] = 584;
$chic['in_the_balance_id'] = 9195;
$chic['intimacy_id'] = 9197;
...etc.

This in fact means that the variable requires every time to reload the categories values from the outside and hence forces to query each one of them every time.

Altough at the very beginning of functions.php it seems that the variable is loaded only once and not repeatedly:

include_once TEMPLATEPATH. '/config.inc.php';
$_SESSION['style'] = $chic['style'];

Do you think I should simply fuse together the two files into the single functions.php?

Oh mamma mia, that’s unfortuntely asking a bit too much of myself, LOL.

I’ve designed and put togheter the entire site by snapping code here and there and knowing some very basics of PHP to ‘survive’, but for as much as I’d love to learn all this very much into depth, I need to realize that am not truly a techy dude ??

Queries vary based on which page is loaded; the infamous function above is actually loaded each single time there is a page/visit request since it’s embedded in functions.php, that’s why the overload, regardless of the area of the website you are in, either landing from referral or inner navigation, the function will always run at request. That’s why am struggling to find a way to bypass the entire get_categories array.

Unfortunately I am running a quite complex website, but if it wasn’t for this very sudden obstacle, I’d say that WordPress really does its work finely. Any help will be TREMENDOUSLY appreciated ??

Thanks for the tips, t31os_, much appreciated.

In fact my fear is that the overload might be caused by the use of “get_category” or “get_cat_name” in the very first parsing of the function.

The variations suggested by vtxyzzy to streamline the entire function work perfectly and slim down the entire block of code dramatically; unfortuntely I would not have a clue as per how to optimize the loop above to prevent it to query each of the categories enlisted.

I tried to search and implement the “get_terms” this way, but it doesn’t work. Unfortunately I’m quite dense at these things ??

$get_post_cat = get_terms(category, $post->ID);
foreach($get_post_cat as $catid ) {
$cat = get_terms(category, $catid);
$the_cat = get_terms(category, $cat->cat_ID);
}

$all_cats = get_categories();
foreach ($all_cats as $one_cat) {
$cat_by_id[$one_cat->term_id] = $one_cat;
}

Any idea as per how this could be optimzed? Thanks a mille in advance.

Is it perhaps possible that the array generated by this script at each visit (request), after the 2.9.1 upgrade, forces the server to write for each individual ‘check-if’ option of the categories enlisted? Is it perhaps that the script needs now to be altered with new WP tags?

global $post, $chic;
$get_post_cat = wp_get_post_categories($post->ID);
foreach($get_post_cat as $catid ) {
$cat = get_category($catid);
$the_cat = get_cat_name($cat->cat_ID);
}

In few words, what I notice from the CPU report is that all categories receive the same amount of hits/requests, as if an automated refreshed action would call them all at once at each single time an individual category is requested.

Besides, before 2.9.1 it never happened that categories’ permalinks requests would write/overload the server at all. I thought it could be any new updated plugin, but now that I removed them all I am left to think that it must be due to the function above? Did you eventually hear of any other similar situation so far? This really is frustrating.

Just received the CPU report and unfortunately it doesn’t seems to get any better. At this point I might even begin thinking that it could be a RSS related issue?

The report shows that all major hits fall on the direct categories permalink, e.g.:
www.domain.com/category/namecategory1/
www.domain.com/category/namecategory2/
, rather than direct request to files.

What frustrates me is that now I literally eliminated all plug-ins (it only uses Disqus Comments and Page-Number), and this problem manifested immediately after the upgrade to WP 2.9.1

WOW, that really shrank the entire function dramatically, and it is working perfectly. Now I will need to wait to check the new CPU report from the server to see if I can notice substantial improvement.

Thanks a mille, vtxyzzy!!! Much appreciated!

Hi Esmi,

Thanks a mille for the prompt reply. Unfortunately it is essential to maintain full and differentiated control for each individual category and post.

As you may see here: https://www.chictoday.com, the entire website runs on a WordPress CMS and each individual channels homepages, categories and especially the individual posts have different layout design also due to advertising and content individuality. And as you can see there are quite a few.

Do you truly think I could achieve the same using body_class()? If so, I think I’d have to reprogram the entire site, that’s my fear. That’s why I was in the meantime looking for a possible ‘shrinking’ optimized solution of the code above.