Support » Plugin: WP to Twitter » Fields not appearing

  • Does anyone see any issues with the following template fields… ?

    #author# @{{clearbit_person_twitter_handle}} of @{{clearbit_company_twitter_handle}} quoted in [[press_mention_information_publication-name]] [[press_mention_information_story-link]]

    Intermittently, it doesn’t correctly show author, clearbit_person_twitter_handle or press_mention_information_story-link (not missing all at the same time, just alternately missing). I can’t see a pattern at work, but fields that are present in WordPress seem to be randomly not showing in the tweets.

    Thanks.

Viewing 15 replies - 1 through 15 (of 21 total)
  • Plugin Author Joe Dolson

    (@joedolson)

    Is it possible that the Tweet with all fields in place could be too long to post?

    That may not be it.
    “May” because I have contracted the formulation down a lot, but, several hours later, the plugin is still using the original formulation.
    Can’t understand why that would be the case.

    The following …

    New by #author# at [[press_mention_information_story-link]]

    … when instigated on an edited post, does not display author name.

    Plugin Author Joe Dolson

    (@joedolson)

    Author name can come up blank if the user doesn’t have either a Twitter handle entered or a Display Name; that should be a rare circumstance, but it is possible.

    All of the WP to Twitter custom field tags, surrounded by curly braces, are parsed before the Tweet is shortened to meet length requirements, so they should be added, if they’re available.

    I’m not sure what the square brackets are; WP to Twitter doesn’t use this – are you adding these via custom code?

    Also, I’m not sure I understand your comments “I have contracted the formulation down a lot, but, several hours later, the plugin is still using the original formulation” – can you describe that in more detail?

    “Author name can come up blank if the user doesn’t have either a Twitter handle entered or a Display Name; that should be a rare circumstance, but it is possible.”

    Twitter handle: Where/what is a WordPress’ Twitter handle supposed to be/stored? It’s not a default field, is it? My users’ Twitter handles are stored in a field I call “clearbit_person_twitter_handle”, as above, minus the “@” sign. What is the plugin expecting?

    Display name: How does WordPress “Author Name” differ from “Display Name”? Isn’t something for “Display name publicly as” mandatory, since there is no “None” option in the WordPress backend dropdown on an Edit User page. My users have both, I believe. I can certainly see a tweet that just got sent that does not include the name of a user who definitely does have something set against “Display name publicly as”.

    “I’m not sure what the square brackets are; WP to Twitter doesn’t use this – are you adding these via custom code?”

    It is a custom field (and from a custom post type). This is from your own documentation, on the “Tweet Template Tags” panel, as below. Just like the above fields, I have had success showing this sometimes, but not all the time.

    Create custom shortcodes and access WordPress custom fields by using square brackets and the name of your custom field.
    Example: custom_field

    Create custom shortcodes and access the post author’s custom user meta fields by using curly brackets and the name of the custom field.
    Example: {{user_meta}}

    “Also, I’m not sure I understand your comments “I have contracted the formulation down a lot, but, several hours later, the plugin is still using the original formulation” – can you describe that in more detail?”

    That’s my long-winded way of saying, I took a few fields out in the process of elimination. It currently stands at only…

    New by #author# at [[press_mention_information_story-link]]

    Tested right now, I had some success showing both those fields in a tweet prompted by a manual edit of an existing post.

    Plugin Author Joe Dolson

    (@joedolson)

    WP to Twitter has its own field for storing a Twitter handle; if you’ve enabled user settings, it’ll be available to edit. It’s the only Twitter handle field that will be recognized.

    The display name can be empty for automatically created users, but no, not for users that were created from the admin.

    The documentation you cited shows curly braces; but your sample text includes a mix of curly braces and square braces. The square braces aren’t a WP to Twitter pattern; is this *actually* what you have in your system, or are they actually curly braces?

    Plugin Author Joe Dolson

    (@joedolson)

    OK; I’m apparently crazy. WP to Twitter does claim to support both square and curly braces; I’m investigating, because in searching the *code* I’m not seeing the square braces.

    Plugin Author Joe Dolson

    (@joedolson)

    OK. It’s a bug in my code editor. For some unknown reason, it finds the curly brace combination and can’t find the square brace combination; even though both are present. I apologize! That was my mistake.

    WP to Twitter has its own field for storing a Twitter handle; if you’ve enabled user settings, it’ll be available to edit. It’s the only Twitter handle field that will be recognized.

    Oh, that’s really weird – and not great news for me, since I have extensively customised user meta and my Twitter handles need to stay stored there, currently named “clearbit_person_twitter_handle”. This actually seems to work for the last few tweets today, for authors who do have a handle stored in that field. So, fingers crossed.
    But you think it *shouldn’t* work, is that right? How does it know? Like, is the plugin supposed to not write out fields, other than your own, that are prefixed with “@”, or fields whose names contain “twitter”? What’s the big deal about me tweeting out a flat piece of text that I say is a Twitter handle?

    The display name can be empty for automatically created users, but no, not for users that were created from the admin.

    But, new users created from admin do have a default Display Name. At least, I’d say they can *after* user creation. Whilst this is not an option on the first Add New User screen, when you go to edit a profile after creation, the dropdown is there with a preselected value (first and last names).
    Are we saying that some of my users may not have Display Names assigned if I haven’t subsequently edited and saved the profile bearing the dropdown?
    And what’s the difference between #author# and #displayname# anyway?

    The documentation you cited shows curly braces; but your sample text includes a mix of curly braces and square braces. The square braces aren’t a WP to Twitter pattern; is this *actually* what you have in your system, or are they actually curly braces?

    I don’t understand how they aren’t a WP To Twitter pattern when your documentation includes:

    Create custom shortcodes and access WordPress custom fields by using square brackets and the name of your custom field.
    Example: custom_field

    The examples I gave above are verbatim what I’d using – a mixture of both curly and square brackets because I want to tweets to contain both custom user fields and custom post fields.

    [Edit: Seen your latest reply, above.]

    • This reply was modified 9 months, 1 week ago by  parakeet.
    Plugin Author Joe Dolson

    (@joedolson)

    I mean that you can’t get the Twitter handle using #author# unless you’re using the WP to Twitter field; you can get anything you want from custom fields.

    #author# is designed to fetch the Twitter handle, and fetches a name only as a fallback; display name always fetches the display name, if it exists, with no fallback.

    How does your publishing process work? Is any of this automatically generated, or is it always the case that you’re creating a post & adding meta data, then publishing?

    Feels like perhaps the bug only applies in certain functions/hooks/scenarios (?). As I said above, I have managed to *successfully* include a square-bracket, custom-field text in the latest and some other instances. So it is displaying on occasion. That last instance was a manual post edit, which leads us to…

    How does your publishing process work? Is any of this automatically generated, or is it always the case that you’re creating a post & adding meta data, then publishing?

    The most typical post creation scenario on my site, however, will be automated posting – ie. the site ingesting content by cron to a custom post type. I’m not sure if this affects things regarding the square-brackets bug… ? As of now, posting happens automatically and there is no stage in which I edit post meta data, before or after publication (although I have been doing this in testing).

    #author# is designed to fetch the Twitter handle…

    That confused me.

    … and fetches a name only as a fallback; display name always fetches the display name, if it exists, with no fallback.

    So, in my case, wherein my users’ Twitter handles are stored in my custom field rather than yours, I should use #displayname# instead of #author#, right?

    Here are some tests, incrementally adding fields…

    * New by #displayname# at [[press_mention_information_story-link]] << all works upon manual custom post add

    * New by #displayname# (@{{clearbit_person_twitter_handle}}) at [[press_mention_information_story-link]] << all works upon manual custom post add (same as above but with standard brackets around a curly field)

    * New by #displayname# (@{{clearbit_person_twitter_handle}}) of @{{clearbit_company_twitter_handle}} at [[press_mention_information_story-link]] <<< all works upon manual custom post add

    * #displayname# (@{{clearbit_person_twitter_handle}}) of @{{clearbit_company_twitter_handle}} at [[press_mention_information_story-link]] <<< all works upon manual custom post add

    * #displayname# (@{{clearbit_person_twitter_handle}}) of @{{clearbit_company_twitter_handle}} quoted by [[press_mention_information_publication-name]] [[press_mention_information_story-link]] <<< all works upon manual custom post add

    That final one successfully approximates my original intention, albeit 1) all tests are with same user, 2) all same scenario of manual post addition.

    I will await tests with auto-ingested content.

    • This reply was modified 9 months, 1 week ago by  parakeet.

    Update:

    Overnight, several automated posts were made using the following template (which succeeded in the manual examples above)…

    #displayname# (@{{clearbit_person_twitter_handle}}) of @{{clearbit_company_twitter_handle}} quoted by [[press_mention_information_publication-name]] [[press_mention_information_story-link]]

    … However, all the square-bracket fields above have been omitted from the tweets.

    This is what I expected. We discussed the square-brackets bug above. Again, feels like it’s only happening in certain scenarios. Felt like you were probing in the right place when you asked me if content was automated or manually-created.

    Thanks.

    Plugin Author Joe Dolson

    (@joedolson)

    OK. It probably relates to the way that your tool creates the automatic posts. At a guess, it’s creating the posts as published, and only adding the meta data after the post has already been published. If that’s the case, this would be the expected behavior: the Tweet is generated at publication, and can only use the information that has been saved at that time.

    What are you using to do your automatic publishing?

    Interesting.
    The post creation is being done by a custom-written plugin, designed to take content from RSS.

    I’m not the direct developer, but, to the extent I understand, I think these are some relevant portions of the code…

    						// Set the basic post information, such as author, published date,
    						// title, and description/story.
    						$postdata = array(
    							"post_author" => $userId, 
    							"post_type" => "pressmention",
    							"post_date" => $feed['date'],
    							"post_date_gmt" => $feed['date'],
    							"post_title" => $feed['title'],
    							"post_status" => "publish",
    							"post_content" => $feed['story'],
    						);
    						
    						// Insert the new post.
    						<strong>$id = wp_insert_post($postdata, true);</strong>
    
    						// Add to index
    						$indexed = add_to_index($feed, $id, $userId, $client);
    						
    						// Save the link
    						<strong>add_post_meta</strong>($id, "press_mention_information_story-link", $feed['link']);
    						
    						// Save the image
    						if($feed['image'] != "") {
    							add_post_meta($id, "press_mention_information_image", $feed['image']);
    						}
    		
    						// Save the publication name
    						if($feed['publication_name'] != "") {
    							add_post_meta($id, "press_mention_information_publication-name", $feed['publication_name']);
    						}
    		
    						// Save the publication url
    						if($feed['publication_url'] != "") {
    							add_post_meta($id, "press_mention_information_publication-url", $feed['publication_url']);
    						}
    						

    In line with what you say, it looks to me like, for each post, the post is created using wp_insert_post and _then_ the relevant meta data is added to the corresponding post. Right?

    I’m not sure how to overcome this!

    If I could get this up and running and used well in a live environment, I would be interested in purchasing the pro version next year. Looks challenging at the moment 🙁

    Plugin Author Joe Dolson

    (@joedolson)

    All you’d need to change is instead of

    'post_status' => 'publish'

    use

    'post_status' => 'draft'

    Then, after all the meta data is added,

    use

    wp_publish_post( $id );

    Should take care of it.

Viewing 15 replies - 1 through 15 (of 21 total)
  • The topic ‘Fields not appearing’ is closed to new replies.