The original Drupal path is used for the article identifier because you can comment entities and list pages too so you can comment any url on your site (if you want). That’s why we couldn’t use entity id or similar identifiers.
An administrative and an access permission is created. The administer permission limits the access to the settings page and the access permission limits the users to use the Livefyre comments widget. The bypass visibility settings permission allows the user to set the comment field regardless of the field settings.
A new field is created to use Livefyre comments on any entity in the site. This field use a checkbox widget, so the editor will be able to enable or disable the comment widget per copies. The cardinality setting is removed from the widget form because it’s unusable in this case (do not need more than one livefyre comment field).
The field has two formatter:
- comment count
The full formatter renders the full comment widget and the comment count formatter renders only the the number of comments. The latter one is useful for teasers.
All field instance has different ID, so multiple widget implementations can be used in a page.
There is a hide Livefyre field checkbox. If you check this checkbox, content editors will not be able to modify the default settings on the content form. The bypass visibility settings permission will override this setting.
A block is also implemented. You can add this block anywhere to your site, so you will be able to comment page manager/views pages as well, not only entities. The block has a different id so it will not conflict with the field widgets.
Admin interface changes
The node type checkboxes are removed because this functionality is implemented by Drupal fields.
The widget always gets the cached HTML version if exists. This is useful because the rendered HTML will available in the site not only in an iframe, so the search engines will index the comments easily.
A new not fieldable entity is created called “Livefyre Comment”. This entity won’t have own display or url, it is stored only in the database. It uses the “livefyre_comments” table and all information is stored as entity property. The following informations will be synchronized:
- comment id
- parent id
- drupal user id
- displayed name
- email addredd
- creation date
- path (article identifier)
- body text
- publish (published or not)
- status (the comment’s current status, for example pending, unapproved, mark as spam etc)
While the cron running the sync process will store the new comments. The number of activity messages are limited to 25/request (for performance). Every time we store the latest activity id in a Drupal variable and the next time we will sync the activity messages from this point. If a comment marked as deleted we will delete it from the Drupal system too and only status, published and body fields will updated, because the activity message author and email address will different than the original. So these messages are not only comments, these are activities so if someone marked a comment as spam a new activity message will be created.
The stored data is usable in views, we implemented a new handler class to set the correct handlers for created, homepage and published fields.
- The module creates the following variables:
These variables will be deleted automatically during the uninstallation process.
There is an API function to check the current user has enterprise licence or not, it called livefyre_is_enterprise().
The system will trying login the current drupal user to Livefyre using his username as display name. Before rendering the widget the module will generate a token from the currently logged in user data and and send it to Livefyre. We are using the fyre.conv.login function to send the user token and start the login process. After the process successfully performed the username should be displayed on the Livefyre widget.
All the three delegate redirect sets the destination, so after the Drupal’s form submit the user will redirect to the original page.