Facebook posts may have an embedded link, together with a description and a caption. This is quite prominent ("shares"). The API allows to import these fields as well. Many facebook posts are empty apart from the embedded data or at least not understandable without the context provided by the embedded info.

Attached patch allows social_content to import the embedded link, description and context into three new fields.

A small change to social_content.class.inc is also included:
1) Allow to import link fields with title and url (so far only the url was supported)
2) Refresh the field list provided by sub-modules when loading the config page (to pick up changes).

CommentFileSizeAuthor
#3 2692221-social_content-settings_for_fields-3.patch1.24 KBholist
social_content_facebook_embedded.patch17.5 KBFrando

Comments

Frando created an issue. See original summary.

pere orga’s picture

pere orga
Primary language Catalan
commented
Status: Needs review » Needs work

Thank you for the patch.

+function social_content_facebook_update_7001() {
+  $type = 'facebook';
+  // Fields were added, add missing.
+  module_load_include('inc', 'social_content_facebook', 'social_content_facebook.fields');
+  $fields = social_content_facebook_field_default_field_bases();
+  foreach ($fields as $field_name => $field) {
+    if (field_info_field($field_name) == NULL) {
+      field_create_field($field);
+    }
+  }
+
+  $instances = social_content_facebook_field_default_field_instances();
+  foreach ($instances as $instance) {
+    if (field_info_instance($instance['entity_type'], $instance['field_name'], $type) == NULL) {
+      $instance['entity_type'] = 'node';
+      $instance['bundle'] = $type;
+      field_create_instance($instance);
+    }
+  }
+}

I think that part can be problematic. Some sites already using the module may don't want to have these fields added to the existing nodes. It's also possible that site builders have deleted the original content types that came with the module.

I don't have the right solution to this problem but I think it's better to remove this part. It's the problem of having the content types bundled: It may be handy for some but problematic for others. We have the boolean variable social_content_create_bundles to make them optional on install (and maybe could be checked here) but that's not great either.

If the update_n part is removed only sites with new installs will have these new fields but I think that's acceptable.

Any thoughts?

holist’s picture

holist commented
StatusFileSize
new 2692221-social_content-settings_for_fields-3.patch1.24 KB

I stumbled upon the same general issue, as I wanted to get Facebook attachments (shared videos etc) from the API.

What I suggest is to make it possible to configure the fetched fields per instance.

I wrote a quick patch to enable configuring this, but I haven't addressed the issues that arise from taking this into use on existing Social Content installs -- i would be necessary to run updates to add the default setting to all existing instances (run will fail as is if the new configuration field is not set).