WordPress.org

Ready to get started?Download WordPress

Forums

BUG? Able to save custom post type without title, then loose all data (15 posts)

  1. kjmeath
    Member
    Posted 3 years ago #

    I have a custom post type with a title and a few custom fields.
    If I save without a title, I get a message saying the post was saved when really it didnt, and all the data is lost.

    Is there a way to make the title required and not allow the user to save until one has been filled out?

  2. Kimikaze
    Member
    Posted 2 years ago #

    I have the same problem and I’m looking for a solution for this now. Normal posts seem to save just fine without a title, but not my custom types. Did you ever find a solution?

  3. Adam Capriola
    Member
    Posted 2 years ago #

    Here's what I'm finding (working around the same issue at the moment):

    A post needs to have either a title OR content in the editor, otherwise it does not save.

    What you can do with a custom post type is do not register Title or the Editor, then you can save custom fields.

    So the code will be like this when you register your custom post type:

    'supports' => array( 'author', 'thumbnail', 'excerpt', 'trackbacks', 'custom-fields', 'comments', 'revisions', 'page-attributes' ),

    No 'title' or 'editor'. Then you can save custom fields, and the title of the post will end up being auto-draft the whole time though. I'm trying to figure out a way to auto generate the post title from meta in the custom fields right now, so that the title is something other than Auto Draft.

  4. get_username
    Member
    Posted 2 years ago #

    Hey Adam,

    Did you figure out how to change the Auto Draft (title) to a custom field? I'm trying to do the same thing.

    Thanks

  5. thatwastaxing
    Member
    Posted 2 years ago #

    I'm having the same issue with the Auto Draft title and slug. Watching this thread and will come back if I find any solutions.

  6. metai
    Member
    Posted 2 years ago #

    Hi. Long time reader, first time poster.

    I might be able to shed some light on this issue. Actually, the OP draws the wrong conclusions from his observations. The data is not lost, only unaccessible.

    As with regular posts and pages, a post of a custom post type without a title gets saved as an (auto-)draft with the title "Auto Draft". (After hitting the "Publish" button the yellow notification will erroneously say "post published"*.)

    The problem is that these auto-drafts do not show up in the posts table; Not in the regular one marked as drafts, not in the drafts filter. And because they are only drafts they also won't appear in arrays retrieved by get_posts() etc.

    I discovered this purely by accident on a client's site when I found images in the media library attached to "Auto Draft" posts that I wasn't able to find in the posts table. Following the link from the media library I found the elusive posts. When they get a title (and, in the process, a slug), they do appear in the posts table again.

    I haven't found this bug in the bugtracker yet. But the bugtracker won't access my (freshly made) login (yet). I'll be watching this topic and hopefully be able to file a bug report soon. I think this is a rather serious bug than can severly puzzle WordPress users.

    Greetings from Germany
    Freddy

    *) That the notification does not reflect the custom post type labels is another issue.

  7. metai
    Member
    Posted 2 years ago #

  8. owenwalz
    Member
    Posted 2 years ago #

    I'm running into the same issue. There are some custom post types in which a 'title' field doesn't make sense, but the system still requires it. Having the title pulled from another meta field would be ideal.

  9. owenwalz
    Member
    Posted 2 years ago #

    Could this be accomplished by adding a filter that copies meta into the title during the publish hook? I'm a bit of a noob coding-wise so forgive me.

  10. metai
    Member
    Posted 2 years ago #

    Possibly, but that's a quite ugly way to go about it. What if you don't have meta info?

    There is a flaw in WordPress here, and it manifests in several ways. You are right, there is no real reason for posts to require a title. All they really need is an ID, and that's obviously auto-generated. Posts, pages, and custom posts can happily live in the system without a slug. When saved and/or published, it would be okay to notify the user that the post doesn't have a title yet, but it shouldn't be a showstopper.

    As for the concrete bug, unfortunately, my bug report (see above) has been shrugged off by someone who misunderstood the issue. I guess I'll have to dig into the innards myself and patch the routine that generates the posts table to show posts without title and content.

  11. Kimikaze
    Member
    Posted 2 years ago #

    I don't think this problem has anything to do with the auto draft system. The auto drafts are generated even if you don't click on the save button, and just leave the site.

  12. metai
    Member
    Posted 2 years ago #

    It is not directly related to the auto draft system, no. It is a flaw in the generation of the posts table: Apparantly it chooses not to display auto-drafts without content (i.e. posts without content and title)--but ignores the fact that even at this stage, such posts can contain other data and can even have other posts (attachments) tied to them.

  13. Kimikaze
    Member
    Posted 2 years ago #

    I saw this post came to life again and wanted to give it another try. Here is my status on this problem. Found two solutions, not heavy tested, and not pretty, but seems to be working.

    In wp-includes/post.php line 2450 change:

    if ( ('' == $post_content) && ('' == $post_title) && ('' == $post_excerpt) && ('attachment' != $post_type) ) {

    to somting like

    if ( ('' == $post_content) && ('' == $post_title) && ('' == $post_excerpt)  && ('post' == $post_type or 'page' == $post_type) ) {

    seems to solve the problem for custom post types. The wrong message is still being produced for normal posts or pages without title/content/excerpt, so its not a complete fix.

    This code can fix it for your custom post type without editing wordpress itself. The idea is that if wordpress don't want to do things without a post title, then lets do it ourself, or give wordpress a temporary title to work with. The temporary title will make the 'if test' over validate to false, and continue the script. We can then remove the title again later. Please suggest improvements if you see any.

    add_filter('title_save_pre', 'check_title'); //if no post title set it to notitle
    function check_title($post_title) {
    	if ($_POST['post_type'] == 'my_post_type' and !$post_title){
    	  $post_title = 'notitle'; //set this to what you want the post name/url to be ?
    	}
    	return $post_title;
    }
    
    add_action( 'save_post', 'no_custom_post_type_title' ); //if post title = 'notitle' set it to ''
    function no_custom_post_type_title ( $post_id ) {
    	$post_type = get_post_type( $post_id );
        if ( $post_type == 'my_post_type') {
    		$post_title = get_the_title($post_id);
    		if ( $post_title == 'notitle') {
    			global $wpdb;
    			global $post;
    
    			$post_name = $post->post_name;
    			if (strlen(stristr($post_name,$post_title))>0) { //generate a post_name
    				$post_name = sanitize_title($post_type.'-'.$post_id);
    			}
    
    			$post_title = '';
    			$where = array( 'ID' => $post_id );
    			$wpdb->update( $wpdb->posts, array( 'post_title' => $post_title, 'post_name' => $post_name), $where ); //can set post name/url here based on other meta data?
    		 }
        }
    }
    
    add_action ( 'trash_post', 'do_trash_post' ); // Set status to trash when post is trashed
    	function do_trash_post($post_id) {
    		if ( get_post_type( $post_id ) == 'my_post_type' and !get_the_title($post_id)) {
    		global $wpdb;
    		$post_status = 'trash';
    		$where = array( 'ID' => $post_id );
    		$wpdb->update( $wpdb->posts, array( 'post_status' => $post_status), $where );
    	}
    }
    
    add_action ( 'untrash_post', 'do_untrash_post' ); // Set status to whatever it was before it was in the trash
    	function do_untrash_post($post_id) {
    		if ( get_post_type( $post_id ) == 'my_post_type' and !get_the_title($post_id)) {
    		global $wpdb;
    		$post_status = get_post_meta($post_id, '_wp_trash_meta_status', true);
    		$where = array( 'ID' => $post_id );
    		$wpdb->update( $wpdb->posts, array( 'post_status' => $post_status), $where );
    	}
    }

    This code can be improved for sure but works for me so far.

    I think its a good idea to to have a post_title even if you don't need a title field. This can be done with an inut with the name set to post_title:
    <input type="text" name="post_title" value="<?php echo get_the_title(); ?>"/>
    You can label it however you want, and wordpress takes care of saving it even with no support for title on that post type. Can even use a hidden post_title input and generated a post_title based on other form values with jquery, or generate it in a hook ofc.

  14. owenwalz
    Member
    Posted 2 years ago #

    Thanks for all your work on this issue. I'll see if I can test some of it out.

  15. Pierre Pernix
    Member
    Posted 2 years ago #

    Hi there,
    @Kimikaze Thanks for your code. I have been looking for something similar for a long time. In my custom post type, I use to copy the values of several custom fields to the post title field (hidden with display:none) with the help of jQuery.
    Problem: there is no way to check if this auto-generated title still exists in the database before publish, and nothing can avoid two posts with the same title to be created by different users.
    Actually, I tried your code as it and it didn't work: the custom post title with no title support is still saved as "draft".
    Well, I'm sure this code can also be improved to check if a post title still exists or not, but I'm a kind of PHP idiot.
    For now, I will use the hidden <input> method you described, and no more need to hide the title field in JS. To be continued...

Topic Closed

This topic has been closed to new replies.

About this Topic