php - Custom Post Types in WordPress Dashboard List Rows But Data is Blank

admin管理员组

文章数量:1122826

I have a WordPress site that has several custom post types. Recently I moved it to Amazon Lightsail hosting which I've used for years. After the move, all my post types appear in the dashboard but they cannot be edited, and while the rows appear all data is blank.

I have checked the database to ensure that the data is indeed there (and it is). This is happening for every post type. As a test, I created a new post type and then added a new post to that post type, but the backend still shows the empty row. I can create posts, pages and new products (WooCommerce site) which all show as expected.

I have double-checked my capabilities to ensure that for some reason they weren't corrupted or turned off and Admins should have all the correct capabilities. In addition, I turned off all plugins and used a base theme to see if anything changed but the issue persists.

Here is an example of one of my custom post types. You can see the rows are empty, some of the data is output (like the ids) but the cells are empty

Sample Custom Post Type from functions.php

    function my_custom_post_tickets()
{
  $labels = array(
    'name'               => _x('Tickets', 'post type general name'),
    'singular_name'      => _x('Ticket', 'post type singular name'),
    'add_new'            => _x('Add New', 'ticket'),
    'add_new_item'       => __('Add New Ticket'),
    'edit_item'          => __('Edit Ticket'),
    'new_item'           => __('New Ticket'),
    'all_items'          => __('All Tickets'),
    'view_item'          => __('View Tickets'),
    'search_items'       => __('Search Tickets'),
    'not_found'          => __('No tickets found'),
    'not_found_in_trash' => __('No tickets found in the Trash'),
    'parent_item_colon'  => '',
    'menu_name'          => 'Tickets'
  );
  $args = array(
    'labels'        => $labels,
    'description'   => 'Need Tickets',
    'public'        => true,
    'menu_position' => 5,
    'supports'      => array('title', 'editor', 'author'),
    'has_archive'   => true,
    'capability_type' => 'tickets',
    'capabilities' => array(
      'publish_posts' => 'publish_tickets',
      'delete_posts' => 'delete_tickets',
      'edit_posts' => 'edit_tickets',
      'read_private_posts' => 'read_private_tickets',
      'edit_post' => 'edit_tickets',
      'delete_posts' => 'delete_ticket',
      'read_post' => 'read_tickets',
    ),
  );
  register_post_type('tickets', $args);
}
add_action('init', 'my_custom_post_tickets');

I am using the latest WordPress 6.5.2 with PHP 8.2.16

I have a WordPress site that has several custom post types. Recently I moved it to Amazon Lightsail hosting which I've used for years. After the move, all my post types appear in the dashboard but they cannot be edited, and while the rows appear all data is blank.

I have checked the database to ensure that the data is indeed there (and it is). This is happening for every post type. As a test, I created a new post type and then added a new post to that post type, but the backend still shows the empty row. I can create posts, pages and new products (WooCommerce site) which all show as expected.

I have double-checked my capabilities to ensure that for some reason they weren't corrupted or turned off and Admins should have all the correct capabilities. In addition, I turned off all plugins and used a base theme to see if anything changed but the issue persists.

Here is an example of one of my custom post types. You can see the rows are empty, some of the data is output (like the ids) but the cells are empty

Sample Custom Post Type from functions.php

    function my_custom_post_tickets()
{
  $labels = array(
    'name'               => _x('Tickets', 'post type general name'),
    'singular_name'      => _x('Ticket', 'post type singular name'),
    'add_new'            => _x('Add New', 'ticket'),
    'add_new_item'       => __('Add New Ticket'),
    'edit_item'          => __('Edit Ticket'),
    'new_item'           => __('New Ticket'),
    'all_items'          => __('All Tickets'),
    'view_item'          => __('View Tickets'),
    'search_items'       => __('Search Tickets'),
    'not_found'          => __('No tickets found'),
    'not_found_in_trash' => __('No tickets found in the Trash'),
    'parent_item_colon'  => '',
    'menu_name'          => 'Tickets'
  );
  $args = array(
    'labels'        => $labels,
    'description'   => 'Need Tickets',
    'public'        => true,
    'menu_position' => 5,
    'supports'      => array('title', 'editor', 'author'),
    'has_archive'   => true,
    'capability_type' => 'tickets',
    'capabilities' => array(
      'publish_posts' => 'publish_tickets',
      'delete_posts' => 'delete_tickets',
      'edit_posts' => 'edit_tickets',
      'read_private_posts' => 'read_private_tickets',
      'edit_post' => 'edit_tickets',
      'delete_posts' => 'delete_ticket',
      'read_post' => 'read_tickets',
    ),
  );
  register_post_type('tickets', $args);
}
add_action('init', 'my_custom_post_tickets');

I am using the latest WordPress 6.5.2 with PHP 8.2.16

• php
• custom-post-types

Share Improve this question asked Apr 20, 2024 at 17:19 elkefreedelkefreed 38511 gold badge55 silver badges1616 bronze badges 4

• Are there indeed (in the database) 27 of this custom post type as shown? if so that confirms the code which populates this table is at least accessing the database and reading the right data. Could you hook into the parse_query filter which gets passed the query for this page - and then log that query to see if there is something wrong with it? Or - how did you migrate? Did you copy the database or use the export/import? Some posts seem to suggest the problem may lie with permalinks. – Kropotkin Commented Apr 20, 2024 at 19:30
• Yes the returned count matches the db query (27). I used Updraft Plus to migrate the posts vs a straight db dump. Using the parse_query filter is a great idea, I'll start there. – elkefreed Commented Apr 20, 2024 at 22:25
• The post columns look like post-meta or taxonomy terms. Where is that registered? Can you use the screen-options form (top-right) to add the title column? – admcfajn Commented Apr 23, 2024 at 1:06
• @elke_wtf Possible to share the code for the Coupons List class? And is there anything at all in the error logs? – Kumar Commented Apr 25, 2024 at 6:52

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 0

As you have checked the problem is not with the post-type not existing or the database being empty. The key to your solution is in the line you have highlighted: class="locked-indicator". You can find the code in WP_posts_List_Table if you want.

Somehow during the migration the posts have received the status 'locked', which means somebody is editing them. Usually that status is retracted as that user stops editing. Now it isn't. And even as an admin you cannot edit posts that are locked, so you cannot change the status.

Now we're getting into unknown terrain. The locked status is sparsely documented. Changing it with WordPress functions may be impossible. That means you will have to change the post_status directly in the database. My suggestion would be to try a couple of bulk editing plugins to change all 'locked' posts to 'publish'. Else you probably have no choice but to backup your database and run a MySQL query to get this done.

Update

Another line of thought: ignore the 'locked' status (only temporarily, else you'll mess up the locking process forever). If you look at wp_check_post_lock you see these lines:

$lock = get_post_meta( $post->ID, '_edit_lock', true );

if ( ! $lock ) {
    return false;
}

So, if you can manipulate what is returned from get_post_meta you can shortcut the locking process. Down the line this opportunity arises in this line in get_meta_data_raw:

$check = apply_filters( "get_{$meta_type}_metadata", null, $object_id, $meta_key, $single, $meta_type );

Here you can force _edit_lock to be false (I hope).

Follow this steps to find the error and to resolve this

Check Error Logs: Look into your server error logs for any PHP or database errors that might shed light on what's going wrong. Sometimes, errors are logged that can be helpful

Reinstall WordPress: As a last resort, you might consider re-installing WordPress core files. take backup your site before doing this.

Database Prefix: check your all database table prefixes are consistent. If you're moving between environments, sometimes this can cause issues if the table prefixes are different.

Re-save Permalinks: Sometimes, simply re-saving your permalinks structure can resolve unusual behavior in WordPress. Go to Settings > Permalinks and click the

"Save Changes" button without making any changes. WP_DEBUG: Enable WP_DEBUG mode in your wp-config.php file to see if there are any PHP notices or warnings that could point to the source of the problem.

Test on a Local Environment: If possible, set up a local development environment mirroring your live site and see if the issue persists there. This can help isolate whether the problem is specific to the hosting environment.

Reinstall WordPress: As a last resort, you might consider re-installing WordPress core files. take backup your site before doing this.

Note: Let's collaborate to resolve this issue. I'm confident we can find a solution. We'll start by checking the database for any inconsistencies. After ensuring the database integrity, we'll investigate any potential changes in table prefixes that might have occurred during the migration. Then, we'll re-save the permalinks structure in WordPress settings to see if that resolves the problem. Next, we'll meticulously examine for any conflicts with plugins or themes, even though we've already disabled them for testing. Enabling WP_DEBUG mode in the wp-config.php file will help us identify any PHP notices or warnings that could provide valuable insights. We'll also verify that the database charset and collation settings match between the old and new hosting environments. If necessary, we can set up a local development environment to isolate the issue. As a last resort, we'll consider reinstalling the WordPress core files, ensuring to back up the site beforehand. With this systematic approach, I'm confident we'll identify and rectify the issue.

本文标签： phpCustom Post Types in WordPress Dashboard List Rows But Data is Blank