• I was testing out the various custom field types and noticed an issue with the Image and Media field types. For example, I added a Media field to a new custom content type. When I tested creating a new post using this content type, I got an SQL error shown on screen after uploading the media file (a PDF) and then clicking on the “Insert into Post” button. What happens is that the upload dialog closes and then directly below the “Choose Media” and “Upload” buttons I see the following error:

    WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”http://localhost:8444/wordpress/?attachment_id=105′ ) GROUP BY wp_posts.ID ORDE’ at line 1]
    SELECT wp_posts.* , parent.ID as ‘parent_ID’ , parent.post_title as ‘parent_title’ , parent.post_excerpt as ‘parent_excerpt’ , author.display_name as ‘author’ , thumbnail.ID as ‘thumbnail_id’ , thumbnail.guid as ‘thumbnail_src’ , metatable.metadata FROM wp_posts LEFT JOIN wp_posts parent ON wp_posts.post_parent=parent.ID LEFT JOIN wp_users author ON wp_posts.post_author=author.ID LEFT JOIN wp_term_relationships ON wp_posts.ID=wp_term_relationships.object_id LEFT JOIN wp_term_taxonomy ON wp_term_taxonomy.term_taxonomy_id=wp_term_relationships.term_taxonomy_id LEFT JOIN wp_terms ON wp_terms.term_id=wp_term_taxonomy.term_id LEFT JOIN wp_postmeta thumb_join ON wp_posts.ID=thumb_join.post_id AND thumb_join.meta_key=’_thumbnail_id’ LEFT JOIN wp_posts thumbnail ON thumbnail.ID=thumb_join.meta_value LEFT JOIN wp_postmeta ON wp_posts.ID=wp_postmeta.post_id LEFT JOIN ( SELECT wp_postmeta.post_id, CONCAT( GROUP_CONCAT( CONCAT(wp_postmeta.meta_key,’::::’, wp_postmeta.meta_value) SEPARATOR ‘,,,,’), ‘$$$$’) as metadata FROM wp_postmeta WHERE wp_postmeta.meta_key NOT LIKE ‘\_%’ GROUP BY wp_postmeta.post_id ) metatable ON wp_posts.ID=metatable.post_id WHERE ( 1 AND wp_posts.guid ‘http://localhost:8444/wordpress/?attachment_id=105’ ) GROUP BY wp_posts.ID ORDER BY wp_posts.ID

    It seems that the issue is the final WHERE clause, i.e.:

    WHERE ( 1 AND wp_posts.guid 'http://localhost:8444/wordpress/?attachment_id=105' )

    This obviously isn’t valid SQL since there is no comparison operator between wp_posts.guid and the url. I have never touched any php before, but I was looking through the php code for this plugin and I think I’ve found the line that generates that SQL for that WHERE clause. It is within the _get_sql function and looks like this:

    $hash['direct_filter'] .= $this->_sql_filter($wpdb->posts, $c, $this->operators[$c], $this->$c);

    I added a bit of logging below this and apparently $c has a value of ‘guid’ and I’m assuming that it doesn’t have an operator defined within operators. I noticed that the line directly above this line of code is commented out, so I tried uncommenting that line and commenting the one below it and now the SQL doesn’t break. This is obviously because the ‘=’ operator is hardcoded.

    The only problem is that the generated SQL doesn’t return anything. There are no posts in my database with a guid value of ‘http://localhost:8444/wordpress/?attachment_id=105’ and in fact this URL doesn’t reference anything on my site.

    But I do have a wp_posts row with an ID value of 105 with a guid that is of this form:

    http://localhost:8444/wordpress/wp-content/uploads/2012/01/FilenameHere.pdf

    This makes me think that my attachment guid format is not compatible with the plugin.

    I’ll admit that I’m not up to speed with everything WordPress so I might be missing something obvious here.

    These are the versions I am using:

    Plugin Version: 0.9.5.6-pl
    WordPress Version: 3.3
    PHP Version: 5.2.17
    MySQL Version: 5.5.8
    Server OS: WINNT

    http://wordpress.org/extend/plugins/custom-content-type-manager/

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Contributor fireproofsocks

    (@fireproofsocks)

    I’m working on the Summarize Posts code relating to the operator, so it looks like the operator got snubbed in the query — it’d be useful to know the exact scenario that caused this condition. If you activate the WP_DEBUG mode, you might get more info on this. I’m working to expand the simple hard-coded “=” operator to other operators for greater flexibility in querying.

    I don’t think this has anything to do with the guid format / plugin… that’s just how WP stores the file names, so if you search for the file by name, you search the guid column.

    I believe this issue is fixed on the dev branch: http://downloads.wordpress.org/plugin/custom-content-type-manager.zip

    If not, please file a bug: http://code.google.com/p/wordpress-custom-content-type-manager/issues/list

    Thanks!

    Thread Starter lcewp2012

    (@lcewp2012)

    Out of interest, what is the purpose of this particular query? I assume it is meant to return something so that it can render the selected/uploaded media within the edit form. But as noted, when I changed it to use the hardcoded ‘=’ operator, the query doesn’t match anything (due to the guid being different than what it expected). So my assumption is that this is why after uploading and then inserting the media, there is no indication on the edit form that anything has been selected.

    I forgot to mention that last bit in my initial post. Nothing is displayed within the Media field in the Custom Field section of the edit form to show that a media file has been selected. I assume it should show something (e.g. filename, title, description) and I’m wondering if the guid used in the query not matching the guid of the new attachment row in wp_posts is why nothing is showing.

    Thread Starter lcewp2012

    (@lcewp2012)

    I think this issue is something to do with my particular WordPress configuration at the present time. For some reason the images/media are saying that they have a link URL of this form:

    http://localhost:8444/wordpress/?attachment_id=118

    …but this doesn’t actually return anything (other than a WordPress “It seems we can’t find what you’re looking for” message). Instead the image is returned using a URL of this format:

    http://localhost:8444/wordpress/wp-content/uploads/wintersmall.jpg

    So I assume that the plugin is correctly obtaining the link URL from WordPress and is probably making a usually safe assumption that this link URL will match the guid. But for some reason in my WordPress setup the two do not match. I must have clicked some setting somewhere, or perhaps installed another plugin that has messed this up.

    Thread Starter lcewp2012

    (@lcewp2012)

    I have now confirmed that this guid issue is related to my configuration. What I did is drop all the tables in my database and rerun the install. After doing this, and then reactivating the Custom Content Type Manager plugin, the guid issue has gone away.

    So I think this means that something within my database was causing the issue, probably something in wp_options I’m guessing. I didn’t touch the WordPress application code at all, i.e. the php code was identical either side of the data ‘clearance’, so this seems to suggest it was data related and nothing to do with your plugin. I suspect another plugin has left something such as perhaps a shared option in an inconsistent state.

    So back to the original operator issue. As noted, I can work around this by doing the following:

    $hash['direct_filter'] .= $this->_sql_filter($wpdb->posts, $c, '=', $this->$c);
    //$hash['direct_filter'] .= $this->_sql_filter($wpdb->posts, $c, $this->operators[$c], $this->$c);

    i.e. comment out the one using the operators and uncomment the line using the hardcoded ‘=’. Does this seem like an acceptable workaround?

    My concern about moving to the development build is that it isn’t recommend for a production site. But then again, a hacked version of an official release doesn’t seem ideal either. What are your thoughts on the best way to go with this for a production site? The solution shown above or the development build?

    Plugin Contributor fireproofsocks

    (@fireproofsocks)

    Interesting…. I’d be really curious if there were some WP option that caused the guid to be stored differently. If a plugin was the cause of this, well, then that’s par for the course. I just wish devs would implement their uninstall code and cleanup after themselves a bit better.

    The dev version does correct this issue, so I think you’d be fine using it — I’m trying to get the next patch released in the next couple days, but I’ve got very limited internet. Keep in mind that even the PUBLIC release isn’t at version 1.0, so I still consider it some level of beta. The only way I guarantee my code is when they’re written for a paying contract — I’ve just happened to share the fruits of that labor. What I did temporarily on the dev build was exactly what you did, actually. I sorta got sidetracked trying to implement too many features at once…

    Thread Starter lcewp2012

    (@lcewp2012)

    Thanks for the quick response. Sounds like I could wait for the next patch release. A few days isn’t long to wait.

    I discovered another potential issue: After the media file is attached, clicking on the thumbnail pops up a modal that has a dump of the binary contents of the file. For example, if it is a PDF file then I see the binary contents of the file rather than the PDF (I’m not expecting the browser to actually render the PDF but I thought that it should do something other than displaying the binary content). Same happens for RTF and I would assume for any binary file other than images.

    Is there any way to avoid this other than hiding the thumbnail?

    Plugin Contributor fireproofsocks

    (@fireproofsocks)

    A binary dump? Where is the thumbnail you’re looking at? In the manager? Can you send me your .cctm.json definition file? This would be good to file as a bug, methinks.

    Plugin Contributor fireproofsocks

    (@fireproofsocks)

    oh, re the query: it’s the primary query behind Summarize Posts: it was built as a replacement to WP’s various half-assed post-fetching functions (get_posts, query_posts, WP_Query) — it filters on both the post and postmeta data and gets all results in one query, providing a unified interface to your extended “post objects”, whereas the WP alternatives had numerous caveats and they never incorporated the postmeta (i.e. the custom field data) in any streamlined way.

    I need to do some benchmarking with it on large data sets: it’s great to filter on all your data at once and not have to sew it together after the fact, but it gets inefficient with large data sets.

    Thread Starter lcewp2012

    (@lcewp2012)

    What is the expected behaviour? For example, if the media file is a PDF, what would you expect to see in that modal?

    The thumbnail I mean is the one on the left hand side of the currently selected file for a Media custom field. The currently selected file is shown immediately below the Choose/Upload buttons. For a PDF it shows a static thumbnail called wp-includes/images/crystal/document.png and then beside that the name of the file and below the filename I see the date time that it was uploaded. There is a X image on the right of all of this that deletes the attachment.

    What I did is click on the thumbnail image.

    Plugin Contributor fireproofsocks

    (@fireproofsocks)

    Hmm… I think the binary thing might be something with your particular environment, but I see what you’re talking about — I need to customize what ends up as the target of the link depending on whether the relation is an attachment or another post etc…

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘[Plugin: Custom Content Type Manager] SQL error after uploading then inserting using Media field’ is closed to new replies.