Title: crazyred's Replies | WordPress.org

---

# crazyred

  [  ](https://wordpress.org/support/users/crazyred/)

 *   [Profile](https://wordpress.org/support/users/crazyred/)
 *   [Topics Started](https://wordpress.org/support/users/crazyred/topics/)
 *   [Replies Created](https://wordpress.org/support/users/crazyred/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/crazyred/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/crazyred/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/crazyred/engagements/)
 *   [Favorites](https://wordpress.org/support/users/crazyred/favorites/)

 Search replies:

## Forum Replies Created

Viewing 7 replies - 1 through 7 (of 7 total)

 *   Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
   
   In reply to: [All post_type set to "post" after update to 4.4.2](https://wordpress.org/support/topic/all-post_type-set-to-post-after-update-to-442/)
 *  Thread Starter [crazyred](https://wordpress.org/support/users/crazyred/)
 * (@crazyred)
 * [10 years, 1 month ago](https://wordpress.org/support/topic/all-post_type-set-to-post-after-update-to-442/#post-7257247)
 * Ok I was wrong, my version was not 4.4.1 but 4.1.1 then I found the solution,
   and there is a thread on this known issue.
 * [https://wordpress.org/support/topic/42-update-turned-all-pages-into-posts-big-mess?replies=35](https://wordpress.org/support/topic/42-update-turned-all-pages-into-posts-big-mess?replies=35)
 * The problem came with 4.1.1 that has no db_version number defined which results
   in calling all upgrading functions.
 * Resolved
 *   Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
   
   In reply to: [All post_type set to "post" after update to 4.4.2](https://wordpress.org/support/topic/all-post_type-set-to-post-after-update-to-442/)
 *  Thread Starter [crazyred](https://wordpress.org/support/users/crazyred/)
 * (@crazyred)
 * [10 years, 1 month ago](https://wordpress.org/support/topic/all-post_type-set-to-post-after-update-to-442/#post-7257241)
 * After some more digging,
 * I found that upgrading process run trough functions that are checking for `$wp_db_current_version`
   which is stored in ‘wp_options’ table and it ‘option_name ‘ value is ‘db_version’.
 * I checked my version value which is set to ‘30135’, defined lastly by the 4.4.1
   wp-includes/version.php line:14 `$wp_db_version = 30135;`
 * Then, in the wp-admin/includes/upgrade.php, there is the following function :
 *     ```
       function upgrade_210() {
       	global $wpdb, $wp_current_db_version;
   
       	if ( $wp_current_db_version < 3506 ) {
       		// Update status and type.
       		$posts = $wpdb->get_results("SELECT ID, post_status FROM $wpdb->posts");
   
       		if ( ! empty($posts) ) foreach ($posts as $post) {
       			$status = $post->post_status;
       			$type = 'post';
   
       			if ( 'static' == $status ) {
       				$status = 'publish';
       				$type = 'page';
       			} else if ( 'attachment' == $status ) {
       				$status = 'inherit';
       				$type = 'attachment';
       			}
   
       			$wpdb->query( $wpdb->prepare("UPDATE $wpdb->posts SET post_status = %s, post_type = %s WHERE ID = %d", $status, $type, $post->ID) );
       		}
       	}
   
       	if ( $wp_current_db_version < 3845 ) {
       		populate_roles_210();
       	}
   
       	if ( $wp_current_db_version < 3531 ) {
       		// Give future posts a post_status of future.
       		$now = gmdate('Y-m-d H:i:59');
       		$wpdb->query ("UPDATE $wpdb->posts SET post_status = 'future' WHERE post_status = 'publish' AND post_date_gmt > '$now'");
   
       		$posts = $wpdb->get_results("SELECT ID, post_date FROM $wpdb->posts WHERE post_status ='future'");
       		if ( !empty($posts) )
       			foreach ( $posts as $post )
       				wp_schedule_single_event(mysql2date('U', $post->post_date, false), 'publish_future_post', array($post->ID));
       	}
       }
       ```
   
 * and this specific part :
 *     ```
       if ( $wp_current_db_version < 3506 ) {
       		// Update status and type.
       		$posts = $wpdb->get_results("SELECT ID, post_status FROM $wpdb->posts");
   
       		if ( ! empty($posts) ) foreach ($posts as $post) {
       			$status = $post->post_status;
       			$type = 'post';
   
       			if ( 'static' == $status ) {
       				$status = 'publish';
       				$type = 'page';
       			} else if ( 'attachment' == $status ) {
       				$status = 'inherit';
       				$type = 'attachment';
       			}
   
       			$wpdb->query( $wpdb->prepare("UPDATE $wpdb->posts SET post_status = %s, post_type = %s WHERE ID = %d", $status, $type, $post->ID) );
       		}
       	}
       ```
   
 * …seems to be the culprit of setting post_type to ‘post’ !!
 * So the question is now: why is this upgrade function is called since my db_version
   should be greater than 3506. Plus, it means that all the upgrading functions 
   might have been called during the upgrade process…
 * For the moment I suspect that the db_version value were not stored into the variable,
   which causes all the upgrade functions to mess up the database.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Polylang] Remove CPT slug while using polylang](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/)
 *  Thread Starter [crazyred](https://wordpress.org/support/users/crazyred/)
 * (@crazyred)
 * [10 years, 1 month ago](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/#post-7246830)
 * Yes, my first try was the exact same approach and it works well, then because
   I was not sure about the queries counting check I just made an extra condition
   for this specific case.
 * The extra `empty( $query->query['name'] )` does make sens thought.
 * Since it works I’m gonna go with this one till I get to know if counting post
   does make sens as well.
 * Thanks! 🙂
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Polylang] Remove CPT slug while using polylang](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/)
 *  Thread Starter [crazyred](https://wordpress.org/support/users/crazyred/)
 * (@crazyred)
 * [10 years, 1 month ago](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/#post-7246800)
 * I got it working by changing the following condition :
 *     ```
       if (2 != count($query->query) || !isset($query->query['page'])) {
               return;
           }
       ```
   
 * to
 *     ```
       if (isset($query->query['lang'])) {
               if (3 != count($query->query) || !isset($query->query['page'])) {
                   return;
               }
           } else {
               if (2 != count($query->query) || !isset($query->query['page'])) {
                   return;
               }
           }
       ```
   
 * This way the query string can be filled by 2 arguments when URL contains language
   information :
    name & lang
 * While this is working, I wish wp’s gurus could give me an opinion about if its
   a right way to do.
 * That has been possible with use of [Query Monitor](https://wordpress.org/plugins/query-monitor/)
   recommended by Ulrich, so again thanks a lot!
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Polylang] Remove CPT slug while using polylang](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/)
 *  Thread Starter [crazyred](https://wordpress.org/support/users/crazyred/)
 * (@crazyred)
 * [10 years, 1 month ago](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/#post-7246794)
 * Another thing,
 * While polylang is set to “Hide URL language information on default language”,
   
   then default language url will looks like: domain.com/the-artist-name , and the
   parse trick just works fine
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Polylang] Remove CPT slug while using polylang](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/)
 *  Thread Starter [crazyred](https://wordpress.org/support/users/crazyred/)
 * (@crazyred)
 * [10 years, 1 month ago](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/#post-7246784)
 * While looking around, I figured out that the parse request does not match and
   pass the argument post_type=”artiste”, instead it leave it as a “post”.
 *     ```
       function gp_parse_request_trick($query)
       {
   
           // Only noop the main query
           if (!$query->is_main_query())
               return;
   
           // Only noop our very specific rewrite rule match
           if (2 != count($query->query) || !isset($query->query['page'])) {
               return;
           }
   
           // 'name' will be set if post permalinks are just post_name, otherwise the page rule will match
           if (!empty($query->query['name'])) {
               $query->set('post_type', array('post', 'page', 'artiste'));
           }
       }
   
       add_action('pre_get_posts', 'gp_parse_request_trick');
       ```
   
 * So with following requests I get this results :
 * domain.com/fr/artiste/the-artist-name -> OK
    domain.com/fr/the-artist-name?post_type
   =”artiste” -> OK domain.com/fr/the-artist-name -> 404
 * Querying by “name” still works fine with pages and posts even with identical 
   slug, and i reach the right url, but with custom post type it doesn’t do the 
   trick.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Polylang] Remove CPT slug while using polylang](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/)
 *  Thread Starter [crazyred](https://wordpress.org/support/users/crazyred/)
 * (@crazyred)
 * [10 years, 1 month ago](https://wordpress.org/support/topic/remove-cpt-slug-while-using-polylang/#post-7246778)
 * Hey Ulrich,
 * Thanks a lot for your attention, for your great works and for the the tips.
 * I’m gonna try it right now.
 * I’ll keep the thread updated. Thanks again.

Viewing 7 replies - 1 through 7 (of 7 total)