I am working on a plugin that needs to run many different queries. I created a class that has many functions and all these functions runs different queries. A DAL basically.

Now when I call these functions in my program, all of them work fine but only one of them runs its query. All other queries in all other function calls don't run.

All the functions run their queries fine if I call only one function in the program.

I cant figure out what the problem is ?

here is some code


These are the real functions that are giving me trouble.

I call all of them, they all work. But only one of them(the one called last) runs its query. They all run their queries fine if I call only one of them.

class seoklaxxdataAccess{

function addKeyword_start($row_id, $row_keyword, $oldKeyword, $seo_pageContents){

        global $wpdb;

        $seo_tblPosts = $wpdb->prefix."posts";

        // COMMENT: gets the length of old keyword
        $org_keywordLength = strlen($oldKeyword);
        $keywordLength = $org_keywordLength+3;

        $seo_checkKeyword = substr($seo_pageContents, 0, $org_keywordLength);


                $seo_pageContents = substr($seo_pageContents, $keywordLength);
            $seo_pageContents = $row_keyword.' - '.$seo_pageContents;

            $seo_pageContents = $row_keyword.' - '.$seo_pageContents;
        //echo $seo_pageContents."<br>";
        $wpdb->update($seo_tblPosts, array('post_content'=>$seo_pageContents), array('ID'=>$row_id));

    catch(Exception $e)
        return "not working:".$e->getMessage();


function addKeyword_end($row_id, $row_keyword, $oldKeyword, $seo_pageContents){

    global $wpdb;

    $seo_tblPosts = $wpdb->prefix."posts";

    // COMMENT: gets the length of old keyword
    $org_keywordLength = strlen($oldKeyword);
    $keywordLength = $org_keywordLength+3;

    $seo_checkKeyword_end = substr($seo_pageContents, -$org_keywordLength);

            $seo_pageContents = substr($seo_pageContents,0 , -$keywordLength);
        $seo_pageContents = $seo_pageContents.' - '.$row_keyword;

        $seo_pageContents = $seo_pageContents.' - '.$row_keyword;
    $seo_sqlcommand = "UPDATE ".$seo_tblPosts." SET post_content = '".$seo_pageContents."' WHERE ID = '".$row_id."' ;";
    //SELECT * FROM wp_seo_keywords WHERE id = ".$row_id.";";
    //echo "done".$seo_pageContents."<br>";


This how I instantiated the class

$seo_dataAccess = new seoklaxxdataAccess();

and this is how I am calling the functions

$seo_dataAccess->addKeyword_start($row_id, $row_keyword, $oldKeyword, $seo_pageContents);

$seo_dataAccess->addKeyword_end($row_id, $row_keyword, $oldKeyword, $seo_pageContents);

$seo_dataAccess->addKeyword_middle_bold_linked($row_id, $row_keyword, $oldKeyword, $seo_pageContents);
  • 2
    Any reason you're not using $wpdb->prefix for your table names? – mor7ifer Feb 28 '12 at 13:04
  • Welcome to WPSE. Notes: wp_posts would $wpdb->posts... And you should really use prepare() and like_escape(). Examples can be found in pack of dozens all over the site. Also: Please show your whole class and how you call the class methods. – kaiser Feb 28 '12 at 13:52
  • @m0r7if3r - No reason, just keeping the code simple. Does that make any difference ? – Atif Feb 28 '12 at 14:46
  • 1
    You've not included addKeyword_middle_bold_linked nor have you included the adjustments we've recommended. – Tom J Nowell Feb 28 '12 at 16:38
  • 1
    I would also recommend that you separate out the post update part into another function as you're re-implementing it in each function differently introducing inconsistency and potential errors – Tom J Nowell Feb 28 '12 at 16:40

Don't bother using wpdb to update post content, use wp_update_post instead!


Instead of

$wpdb->update($seo_tblPosts, array('post_content'=>$seo_pageContents), array('ID'=>$row_id));


// Update post 37
$my_post = array();
$my_post['ID'] = $row_id;
$my_post['post_content'] = $seo_pageContents;

// Update the post into the database
wp_update_post( $my_post );

As a side benefit it fires all the hooks so caching works as it should, RSS feeds get refreshed, etc

There's very, very few reasons to manipulate the post table using wpdb. There are many, many good reasons and advantages to using the WP Core post editing functions instead.

And as always, practice safe data handling by validating sanitizing and escaping your data, else automated programs may test your site and find horrible horrible security holes and break everything horribly.

| improve this answer | |
  • thank you Tom But the problem is still there :( – Atif Feb 28 '12 at 16:22
  • 1
    can you give us the output? your catching exceptions but you've not posted what the message is when it fails, all we know is that "if fails" – Tom J Nowell Feb 28 '12 at 16:33

Why you really should take care & stick 100% to the core when doing funny DB stuff

  1. Portability - DB code can and should work everywhere. The wp_ prefix is only a default, which can get changed in the wp-config.php file by every beginner. Plus: It's recommended that you do so. Adding the prefix, will modify the query on the fly and let it proceed also in environments, where you have custom settings.

    // If you're writing plugins, then you have to consider different installations
    // as well as edge cases, customization and other funky things, your users might do
    // So use the following:
    echo $wpdb->posts; // Posts table
    echo $wpdb->options; // Options table
    echo $wpdb->users; // Users table
    echo "{$wpdb->prefix}YOUR_CUSTOM_TABLE_NAME_HERE"; // Custom table
  2. Security Nr. 1 - You don't want someone to missuse your query. FYI: $wpdb->prepare().

    # Basically it's like a "safe" sprintf/printf
    // You can use %d for int and %s for strings
    $wpdb->prepare( "SELECT * FROM $wpdb->posts as p WHERE %d = p.ID", 5 );
  3. Security Nr. 2 - use the esc_* functions to get save input.

    // Normal queries
    $add_query_data = esc_attr( $input );
    // LIKE queries
    $add_query_data = like_escape( $input );
  4. Security Nr. 3 - Showing errors means showing table names, prefixes and else. This is one of the rare situation where "security through obscurity" is a good idea.

    // Don't show SQL errors to anyone except admin users (manage_options capability)
    if ( current_user_can( 'manage_options' ) 

Further Readings…

…about the $wpdb class can be found in the Codex.

| improve this answer | |
  • This is a great post kaiser. I really appreciate your effort. But it dosnt solve any thing for me. I am going to post some more code that might give a real picture/understanding of the code. – Atif Feb 28 '12 at 15:23
  • Oh, great. Why can't you add that code earlier to your Q? – kaiser Feb 28 '12 at 16:12
  • I thought the code I provided initially would be enough to figure out the problem – Atif Feb 28 '12 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.