This is searchable archive of our old support forums, which operated from 2012 - 2016. To find out how to get support for your current theme, please visit our support page.

Incompatibility with MySQL – According to Hosts

  • Creator
  • #8318

    Hey there Jason,

    I have had intermittent database issues with one of my sites.

    When OK:
    When not OK:

    The hosts advised me that “Some of the codes of theme and database seems not compatible with the current mysql version. Please contact the developer to see if there is any server changes we need to make”

    The full reply is below. Any help/advice would be great. Thanks – Catie

    We have set wait_timeout to 100.
    root@dedicated [/home/smartypl/public_html]# cat /etc/my.cnf | grep wait_timeout
    wait_timeout 100
    Please access the site now.
    The other cause can be with the theme (Your Child Theme) used in your wordpress site.
    The mysql version installed in you server is 5.1.68.
    root@dedicated [/home/smartypl/public_html]# mysql -V
    mysql Ver 14.14 Distrib 5.1.68, for unknown-linux-gnu (x86_64) using readline 5.1

    | option_id | option_name | option_value | autoload |
    | 829 | current_theme | Your Child Theme | yes |
    1 row in set (0.00 sec)


    Some of the codes of theme and database seems not compatible with the current mysql version.

    Please contact your developer and let us know whether we have to make an server changes.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Author
  • #8326
    Jason Bobich

    Hello Catie,

    It’s a shame you’re having these repeat problems with your hosting. I’ve honestly never heard of this one.

    I’m no expert on servers or MySQL, but I don’t quite see the logic in something being “incompatible” with your MySQL if the problem is intermittent, coming and going. I can tell you we’re both using MySQL v5.1.x. It seems more logical to surmise that the issue is more something to do with just all the process happening are too taxing on your MySQL database.

    However, contrary to that, the interesting thing here is that your specific scenario does correspond to the one instance in the entire theme framework where we have a custom MySQL statement (opposed to with everything else, we’re just tapping into WordPress’s built-in functions).

    Here’s the specific code that is accessing your database to determine the current layout ID. If this function does not get the correct post ID from your database, you would be theoretically ending up with the “Invalid Layout ID” error you’re seeing.

     * Retrieves a post id given a post's slug and post type.
     * @since 2.0.0
     * @uses $wpdb
     * @param string $slug slug of post
     * @param string $post_type post type for post.
     * @return string $id ID of post.
    if( ! function_exists( 'themeblvd_post_id_by_name' ) ) { 
    	function themeblvd_post_id_by_name( $slug, $post_type ) {
    		global $wpdb;
    		$null = null;
    		$slug = sanitize_title( $slug );
    		// Grab posts from DB (hopefully there's only one!)
    		$posts = $wpdb->get_results( $wpdb->prepare( "SELECT ID FROM $wpdb->posts WHERE post_name = %s AND (post_type = %s)", $slug, $post_type ));
    		// If no results, return null
    		if ( empty($posts) )
    			return $null;
    		// Run through our results and return the ID of the first. 
    		// Hopefully there was only one result, but if there was 
    		// more than one, we'll just return a single ID.
    		foreach ( $posts as $post )
    			if( $post->ID )
    				return $post->ID;
    		// If for some odd reason, there was no ID in the returned 
    		// post ID's, return nothing.
    		return $null;

    As an experiment to see if the MySQL statement there is actually the cause of the error, there is an alternate way you could setup this function to tap into WordPress’s functionality only. This is a pluggable function, and so by simply copying it to your Child theme’s functions.php, you can override it. (Read here)

    Here’s the alternate method you could maybe try:

    function themeblvd_post_id_by_name( $slug, $post_type ) {
    	$args = array(
    		'name' => $slug,
    		'post_type' => $post_type,
    		'post_status' => 'publish',
    		'numberposts' => 1
    	$posts = get_posts($args);
    	if( $posts )
    		return $posts[0]->ID;
    		return null;

    Yes – I know. It makes absolutely no logical sense it would be the theme if it is showing OK half the time. After posting this to you last night, I asked the hosts to change the wait_timout value to 1500. So far, the error has not reappeared after about 20 mins of refreshing. I will test periodically and if it reappears (as it has constantly done over the last 2 months) I will try your fix above and let you know the outcome here in case someone else comes across same. Thanks so much for getting back to me on this.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The forum ‘Akita Responsive WordPress Theme’ is closed to new topics and replies.