Plugin works for default post types, but not for custom

  • Raevenne

    (@raevenne)


    10 years, 11 months ago

    I’ve coded a plugin that adds a meta box to the post page. When the post is published, the plugin will generate a random ID for the post, and insert the random ID and the post guid to a custom table in the database. After publishin, or upon editing, the plugin queries the custom table to retrieve the random ID for the post based on the post guid, and prints out the random ID in the meta box.

    Everything works great until I try to change the post type in the add_meta_box function from ‘post’ to ‘quilt’. The plugin will generate the random ID and save it and the post guid to the table, but presents this error in the meta box:

    Notice: Trying to get property of non-object in /home/qultshow/public_html/wp-content/plugins/randomID/randomID.php on line 126

    instead of the random ID. If I use 

    var_dump( $query );
$wpdb->print_error();

    to try to debug, I see:

    NULL

    WordPress database error: [] SELECT * FROM wp_customtable WHERE qrci_guid = “http://testsite.com/?post_type=quilt&p=213”

    If I run the above query in phpmyadmin, a row is returned as expected.

    Is there something odd or different about querying the database from a custom post type that I need to know about to make this work?

    Thanks for any help!

    P.S. This plugin is not for usage by anyone but me on one website where I need this weird functionality. Also, this is a multi-site installation of wordpress if that makes any difference. I can’t use post metadata for this since I need to be able to query this data without querying every postmeta table on the network, so it has to be a custom table in the database.

Viewing 1 replies (of 1 total)
  • Moderator bcworkz

    (@bcworkz)

    10 years, 11 months ago

    The root of the problem needs to be traced back from what object property you are trying to use on line 126 and why that “object” is no longer an object in this situation.

    In the broader scope, guid is not the best choice of fields to key off of. It is sort of an “internal use” type of field where the nature of its content is subject to change without warning. This may have already happened for custom post types. The only useful data in that field as it currently stands is the post ID. Post ID is really the best field to key your custom data off of. You should be able to write an update query that changes the guid strings in your custom table to just the integer value contained in the string. If all else fails, a PHP loop certainly can make the update.

Viewing 1 replies (of 1 total)
  • The topic ‘Plugin works for default post types, but not for custom’ is closed to new replies.