• Resolved shup

    (@shup)


    Four years ago, I built a custom platform to add cycling records into a WordPress database. I used CPT UI to generate the code for the custom post type “record”. It all worked perfectly. I was away for a while, but now I’ve returned to find three big problems.

    1) The “All Records” and “Add New” have disappeared from the Admin menu and been replaced by “Categories” and “Tags” (which didn’t use to be there). I can get “All Records” and “Add New” to appear if I disable the Child theme we are using. Plugins have no effect on the issue.
    2) Once I can see “All Records” or “Add New”, when I edit an existing Record I cannot see any of the custom fields which were created with add_meta_box. The data is still in the WordPress database in the post meta table and I can query it with SQL. Ditto adding a new Record, doesn’t display any of the custom fields either.
    3) The archive page of posts of type record is no longer loading, and some links to single posts of type record are also causing a 404.

    I don’t know what I should be checking to get the custom form to appear as it used to. Any pointers would be very helpful.

    Code that was generated by CPT UI and had worked for years. In theme functions.php file:

    function record_add_meta_boxes( $post ){
    add_meta_box( ‘record_meta_box’, ‘Record Details’, ‘record_build_meta_box’, ‘record’, ‘normal’, ‘high’ );
    }
    add_action( ‘add_meta_boxes_record’, ‘record_add_meta_boxes’ );

    function record_build_meta_box( $post ){

    wp_nonce_field( basename( __FILE__ ), ‘record_meta_box_nonce’ );

    // Retrieve the custom field values to be managed through the meta box fields from the database

    // Custom Fields:
    // retrieve current values of Record post meta data
    $current_rider_name = get_post_meta( $post->ID, ‘_rider_name’, true );
    $current_legacy_rider_name = get_post_meta( $post->ID, ‘_legacy_rider_name’, true );
    $current_age = get_post_meta( $post->ID, ‘_age’, true );
    $current_age_group = get_post_meta( $post->ID, ‘_age_group’, true );
    $current_rider_hometown = get_post_meta( $post->ID, ‘_rider_hometown’, true );
    // Lots more….
    ?>
    <div>
    <!– all the HTML for displaying the form with custom fields –>
    </div>
    <?php
    }

    function record_save_meta_box_data( $post_id ){

    // verify taxonomies meta box nonce
    if ( !isset( $_POST[‘record_meta_box_nonce’] ) || !wp_verify_nonce( $_POST[‘record_meta_box_nonce’], basename( __FILE__ ) ) ){
    return;
    }
    // return if autosave
    if ( defined( ‘DOING_AUTOSAVE’ ) && DOING_AUTOSAVE ){
    return;
    }
    // Check the user’s permissions.
    if ( ! current_user_can( ‘edit_post’, $post_id ) ){
    return;
    }
    // store custom fields values – Rider Name
    if ( isset( $_REQUEST[‘rider_name’] ) ) {
    update_post_meta( $post_id, ‘_rider_name’, sanitize_text_field( $_POST[‘rider_name’] ) );
    }
    // Lots more fields saved

    }
    add_action( ‘save_post_record’, ‘record_save_meta_box_data’ );

    Using CPT UI 1.7.3
    Wordpress 5.3.2
    PHP 7.1.33

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    It sounds like there’s some possible issues going on with the child theme overall. However, I have no way of knowing what is in that.

    Not sure what provided that code above, but it’s not something that came from CPTUI itself, we’ve never had any code that was related to metaboxes. Perhaps it came from some support requests at the time, or a resource pointed to. Not discounting that the metabox code itself is part of everything.

    That said, at least at the moment, I’m not seeing what parts are specifically from CPTUI itself, outside of perhaps the post types in question are registered via it.

    What recent changes have been made by you? Any plugin updates, parent theme update? edited settings?

    Thread Starter shup

    (@shup)

    Hi Michael – thanks for getting back to me.

    Apologies, I didn’t post the code that was actually generated by CPT UI to register the post type. You are correct, I found the meta box code somewhere else. My mistake.

    /* This is a function to register the Records Post Type */
    /* Code generated from CPT UI */
    /* Note – if you change any config in CPT UI then it will need to be update here too, as this overrides it */

    /* Enqueue child stylesheet */
    add_action( ‘wp_enqueue_scripts’, ‘my_theme_enqueue_styles’ );
    function my_theme_enqueue_styles() {
    wp_enqueue_style( ‘parent-style’, get_template_directory_uri() . ‘/style.css’ );

    }

    add_action( ‘init’, ‘cptui_register_my_cpts_record’ );
    function cptui_register_my_cpts_record() {
    $labels = array(
    “name” => __( ‘Records’, ” ),
    “singular_name” => __( ‘Record’, ” ),
    “menu_name” => __( ‘Records’, ” ),
    “all_items” => __( ‘All Records’, ” ),
    “add_new” => __( ‘Add New’, ” ),
    “add_new_item” => __( ‘Add New Record’, ” ),
    “edit_item” => __( ‘Edit Record’, ” ),
    “new_item” => __( ‘New Record’, ” ),
    “view_item” => __( ‘View Record’, ” ),
    “search_items” => __( ‘Search Record’, ” ),
    “not_found” => __( ‘No Records Found’, ” ),
    “not_found_in_trash” => __( ‘No Records Found in Trash’, ” ),
    “parent_item_colon” => __( ‘Parent Record’, ” ),
    “featured_image” => __( ‘Featured Image for this Record’, ” ),
    “set_featured_image” => __( ‘Set Featured Image for this Record’, ” ),
    “remove_featured_image” => __( ‘Remove Featured Image from this Record’, ” ),
    “use_featured_image” => __( ‘Use as Featured Image for this Record’, ” ),
    “archives” => __( ‘Record Archive’, ” ),
    “insert_into_item” => __( ‘Insert into Record’, ” ),
    “uploaded_to_this_item” => __( ‘Uploaded to this Record’, ” ),
    “filter_items_list” => __( ‘Filter Records List’, ” ),
    “items_list_navigation” => __( ‘Records List Navigation’, ” ),
    “items_list” => __( ‘Records List’, ” ),
    “parent_item_colon” => __( ‘Parent Record’, ” ),
    );

    $args = array(
    “label” => __( ‘Records’, ” ),
    “labels” => $labels,
    “description” => “This is a custom post type for Records – created by Shu, 11 Oct 2016”,
    “public” => true,
    “publicly_queryable” => true,
    “show_ui” => true,
    “show_in_rest” => false,
    “rest_base” => “”,
    “has_archive” => true,
    “show_in_menu” => true,
    “exclude_from_search” => false,
    //”capability_type” => “post”,
    “capability_type” => “record”,
    “capabilities” => array(
    ‘publish_posts’ => ‘publish_records’,
    ‘edit_posts’ => ‘edit_records’,
    ‘edit_others_posts’ => ‘edit_others_records’,
    ‘delete_posts’ => ‘delete_records’,
    ‘delete_others_posts’ => ‘delete_others_records’,
    ‘read_private_posts’ => ‘read_private_records’,
    ‘edit_post’ => ‘edit_record’,
    ‘delete_post’ => ‘delete_record’,
    ‘read_post’ => ‘read_record’,
    ),
    “map_meta_cap” => true,
    “hierarchical” => false,
    “rewrite” => array( “slug” => “record”, “with_front” => true ),
    “query_var” => true,
    “menu_position” => 10,”menu_icon” => “”,
    “supports” => array( “title”, “editor”, “thumbnail”, “comments”, “author” ),
    “taxonomies” => array( “category”, “post_tag” ),
    );
    register_post_type( “record”, $args );

    // End of cptui_register_my_cpts_record()
    }

    I also think there is some conflict with the theme. It was chosen by someone else. The previous theme worked with my custom post type. Does this make sense:

    1) Problem 1 relates to a conflict between the custom post type and the theme, since the admin options for All and Add appear with the default theme? Can I use your CPT UI functionality to rename my custom post type, and will the “Migrate posts to newly named post type” move all record posts to the new type? I suspect, something in the theme is using “record”. Is there a way of examining a theme to see what might be conflicting?

    2) The meta boxes not appearing is another problem, but if I change the custom post type above, I can try regenerating the meta boxes and form again using details from the custom post type?

    3) I’m hoping the links can be regenerated with the new post type. Might be a manual process but not the end of the world.

    I’m trying to find out when this started to go wrong, but I’ve not changed any settings or updated anything personally. We moved to a different host and a higher version of WordPress, but I can’t say if the problem was introduced after that.

    Thanks for your help!
    Shu

    Thread Starter shup

    (@shup)

    I had a quick look to see what code CPT UI would generate now and it is different to what I had several years ago. It seems to pass the theme as a parameter:

    e.g.

    function cptui_register_my_cpts_record() {

    /**
    * Post Type: Records.
    */

    $labels = [
    “name” => __( “Records”, “Avada” ),
    “singular_name” => __( “Record”, “Avada” ),
    “menu_name” => __( “Records”, “Avada” ),
    “all_items” => __( “All Records”, “Avada” ),
    “add_new” => __( “Add New”, “Avada” ),
    etc

    I’ve put this new code in my functions.php instead and I can now see the items in the Admin bar. So looks like I don’t need to change the post type.

    Will see if I can get the meta boxes working now.

    Thanks,
    Shu

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    In terms of the CPTUI code above, this part stands out a bit:

    //"capability_type" => "post",
    "capability_type" => "record",
    

    At least with what parts I’ve seen, you’re not setting up the rest of the capabilities needed for customizing this spot. Maybe you did with the previous theme, but not are in the current one? More often than not, it’s best to leave capability type to “post”.

    Re 1): Honestly I’d leave the post type slug/content values where they’re at until other parts are investigated. No need to move content around that all likely have permalinks in place and possible traffic to them. Best way to inspect a theme is to just download from the server and start looking through the files. Most important files would be functions.php and things in folders like includes or similar. Any files being loaded by functions.php would also be good candidates.

    Re 2): Just in case it’s the situation, have you checked your screen options tab in the upper right corner to see if it’s maybe just hidden somehow?

    Re 3): I assume you mean permalinks? Those would be automatically created by WordPress, but in terms of setting up possible redirects, that would probably be more manual. I still think you should hold on that part until other things are checked on first between the old theme and current.

    I think the keys are hidden somewhere in the old theme files myself.

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Took too long to reply and you added a new reply since.

    Ack Avada. šŸ˜›

    Yeah, that part looks like it was an internationalization issue and not having a textdomain to pull from in the end, with those being filled in now.

    Thread Starter shup

    (@shup)

    Yup my thoughts about Avada too. Not my choice!

    I think it has sorted the problem though. All my meta boxes rebuilt fine after that. The capability types were handled later – so I think that is fine too, but good spot for seeing something unusual.

    I’ve also worked out problem 3. Slugs had special characters in them.

    Thank you for your help. Nice to have a quick response, and a second pair of eyes.

    Cheers,
    Shu

    Plugin Contributor Michael Beckwith

    (@tw2113)

    The BenchPresser

    Welcome. Let us know if anything else comes up.

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

The topic ‘Conflict with Categories / Tags and Lost Meta Boxes’ is closed to new replies.