Jump to content
bfarber
 Share


4.0 - Sharelinks

We refer to the icons you can use to post to third party services such as Facebook, Twitter and Digg as "Sharelinks" in our software suite, and we consider these an important tool both for community promotion and for search engine optimization. Not only can you get links to your community out there on other large, popular sites on the internet where you might be able to drive back more traffic to your own site, but search engines will also see these links to your site on the other large popular sites, follow them, and rank the pages they reach accordingly.

Share links were supported in 3.x, however while planning 4.0 we felt that the implementation could be improved, and so we've done just that. We have tidied up the interface to make managing the services easier for the average admin, provided more flexibility for third parties who wish to developer additional share link services, and we've made it much easier to use from a development stand point.

Managing Sharelinks

Within the admin control panel, you must be able to manage the sharelink services that are available. You may only want to offer buttons to share to Facebook and Twitter, removing clutter that you don't feel your community is familiar with. Or you may want to enable every share service link possible, because your community is full of technical-oriented users who will make use of them. Wherever you fall within this spectrum, the process should be simple and straightforward.



We have removed the ability to add and delete sharelinks, because the reality is most services require far more integration than simply specifying a URL. Thus, we have made the system plugin-based, which allows developers who are familiar with the process far more control, while greatly simplifying the interface for the average administrator. If you are comfortable with adding a link and an icon, building a plugin (see below) is a very simple process. Otherwise, if you don't know what an "HTML" is, you will now be able to work with this page in a far easier manner.

There is a generic settings button at the top, which allows you to globally enable and disable share links, as well as specify whether you want users to have the opportunity to automatically share links to new content with supported services. When you choose to "Edit" a given service, you can specify which groups can access that share link, and specify any service-specific settings related to that service (for instance, to change the default Twitter hash tag used when sharing via Twitter, you would click to edit the Twitter service).


Integrating a New Service

While we ship with some of the most popular services already supported (including support for LinkedIn sharing, new in 4.0!), it is a very simple process to add support for new services. When you build a new sharelink service and drop it into the appropriate folder, it will automatically be installed as soon as you visit the sharelinks management page in the ACP, where you can then choose to enable/disable the service and configure any available options. If you delete a plugin file, the service will automatically be deleted again when you visit this page in the ACP. No further interaction is required to install or uninstall a service, other than visiting the management page in the ACP.

The basic template for a plugin file is as follows

<?php

namespace IPSContentShareServices;


class _Servicename
{
    /**
     * @brief    URL to the content item
     */
    protected $url        = NULL;
    
    /**
     * @brief    Title of the content item
     */
    protected $title    = NULL;

    /**
     * Constructor
     *
     * @param    IPSHttpUrl    $url    URL to the content [optional - if omitted, some services will figure out on their own]
     * @param    string            $title    Default text for the content, usually the title [optional - if omitted, some services will figure out on their own]
     * @return    void
     */
    public function __construct( IPSHttpUrl $url=NULL, $title=NULL )
    {
        $this->url        = $url;
        $this->title    = $title;
    }

    /**
     * Add any additional form elements to the configuration form. These must be setting keys that the service configuration form can save as a setting.
     *
     * @param    IPSHelpersForm    $form    Configuration form for this service
     * @return    void
     */
    public function modifyForm( IPSHelpersForm &$form )
    {
    }

    /**
     * Return the HTML code to show the share link
     *
     * @return    string
     */
    public function __toString()
    {
        return "<b>Some HTML</b>";
    }
}


The class name "_Servicename" should be the same as the filename, minus the _ (the underscore is part of hooks and plugins system in 4.0, which you can read about in a later blog entry). So this filename would be "Servicename.php" and would be located in /system/Content/ShareServices/. The modifyForm() accepts a reference to the form object that is displayed when configuring the service. Here, you can add new configuration options that will be saved automatically (the configuration options should be settings). If you need to specify any HTML or CSS that needs to be manually loaded for the service, you can add assets to both the <head> of the document, or insert content right before the closing </body> tag, depending upon the service's needs in the constructor. The __toString() magic method should return the HTML necessary to generate the share service link.

It is really that simple - there are no hidden "gotchas" to watch out for.

As an aside, the built in ability to email a link has been greatly simplified for third party developers as well. If you implement third party applications by extending the appropriate classes (which we will blog more about later), the ability to email a link to your page with permission checking built in will all be handled automatically for you. You don't need any plugin files specifically to facilitate emailing links to your content items in 4.0.


Implementing Sharelinks in Applications

To implement the sharelinks in your third party applications is equally simple. As mentioned above, assuming you extend the appropriate classes to generate content items (which will be blogged about in detail at a later date), you need only do two things to implement share service integration in your application.

First, your class that extends IPSContentItem must implement the interface IPSContentShareable. This automatically enables the share links in your application and adds support for any functionality the share services utilize.

Second, your template should include the appropriate sharelinks template where-ever you wish to display the share links

{template="sharelinks" group="global" location="front" params="$contentItem"}


If you wish to render the share links in some manner beyond our default generic rendering, you can simply use whatever HTML you need to, however we feel that most content items can utilize our generic template just fine.


A Few Notes in Closing

We feel that these changes will make implementing share links as easy as possible while still providing you all the flexibility you may need to customize the interaction and display of the links at every level.

We have also decided to remove the "print" and "download" share links at this time. In researching their usage and their functionality, we feel that it is no longer worth maintaining these unnecessary links which simply add clutter to the page. All browsers allow you to save a page (i.e. download it) already, and all browsers allow you to print a page already. We will include a print stylesheet with 4.0, just as we did with 3.x, so when you choose to print a page the output will be better tailored for printed media. We feel, however, that retaining the links adds no real value for the vast majority of users, and is more inline with what most users encounter on other similar websites.

We hope that the improvements and decluttered interface, both on the front end and the ACP, make configuring and using these services (and adding support for others) much simpler than in previous versions.

 Share

Comments

Recommended Comments

Would it be possible to "group" share links? 

 

So I could want Facebook and Twitter to really "stand out" and be on it's own, but I will hide the rest of the share options inside an "other"-group. Then you could click on the other button and it would give you a dropdown list of the available services inside the group. 

 

That way you satisfy "less clutter and buttons" for new comers while still making the other services accessible enough for the "advanced" users. 

 

Just a thought :) 

Link to comment
Share on other sites

If you delete a plugin file, the service will automatically be deleted again when you visit this page in the ACP.  No further interaction is required to install or uninstall a service, other than visiting the management page in the ACP.

 

What happens if you delete the plugin file but forget to visit the ACP page? Will it remove itself the next time someone tries to use that sharelink option? Or will it error out until an admin visits the ACP page?

 

I also see that there's no information box or anything else in the screenshot you posted. How will admins know they must delete the plugin file and re-visit the page to remove it from the list?

 

P.S.: A screenshot of the sharelink settings form would be nice too see if possible.

Link to comment
Share on other sites

I look forward to seeing how the pre-built plugins are implemented.  Ideally we'd like to be able to specify different share plugin configuration/output for a given service depending on what app you are in.  For instance what you want to send to facebook or G+ would likely be different if you are sharing an image from IP.G vs an article from IP.C or a Topic from IP.B etc... 

 

Any chance of being able to use something like block templates to handle the output?

 

Agree with TSP on it being useful to kinda focus on a small handful and have the others available but hidden/de-emphasized via jQuery etc.

Link to comment
Share on other sites

Logical improvements, thank you.

Wondering if we'll ever have the ability to download entire threads as pdfs or something similar...probably not possible for those larger threads...

I've suggested that before and it wasn't met with much support, I think others have too; as I recall it was to do with impact on server performance, although the option could be restricted for real members and not guests or bots to preserve resources.
Link to comment
Share on other sites

Would it be possible to "group" share links? 

 

So I could want Facebook and Twitter to really "stand out" and be on it's own, but I will hide the rest of the share options inside an "other"-group. Then you could click on the other button and it would give you a dropdown list of the available services inside the group. 

 

That way you satisfy "less clutter and buttons" for new comers while still making the other services accessible enough for the "advanced" users. 

 

Just a thought :smile:

 

Our designer will be going over the interface (which you guys of course haven't even seen since I didn't post a screenshot of it) still, so it's premature to talk about *exactly* how they will be displayed on the front end.  I could show you what they look like now but...admittedly they're a little ugly still. :)

 

 

What happens if you delete the plugin file but forget to visit the ACP page? Will it remove itself the next time someone tries to use that sharelink option? Or will it error out until an admin visits the ACP page?

 

I also see that there's no information box or anything else in the screenshot you posted. How will admins know they must delete the plugin file and re-visit the page to remove it from the list?

 

P.S.: A screenshot of the sharelink settings form would be nice too see if possible.

 

If the plugin file is not there (but the database row is), it simply won't execute.  Visiting the ACP page simply deletes it from the database - there's no harm if it is still in the database though during front end execution.

 

Admins really shouldn't need to delete plugins.  If you don't want to use a sharelink just disable it.  i.e. if we ship with Reddit support (as a random example) and you don't want to use it, if you just delete it then it is going to show back up the next time you upgrade.  If you disable it, however, then it will remain disabled even through upgrades.  I don't think it is really necessary to give deletion instructions, at least through the interface.  It is primarily meant for third party share link plugins if you suspect the code quality is poor or there might be a security issue.

 

I look forward to seeing how the pre-built plugins are implemented.  Ideally we'd like to be able to specify different share plugin configuration/output for a given service depending on what app you are in.  For instance what you want to send to facebook or G+ would likely be different if you are sharing an image from IP.G vs an article from IP.C or a Topic from IP.B etc... 

 

Any chance of being able to use something like block templates to handle the output?

 

Agree with TSP on it being useful to kinda focus on a small handful and have the others available but hidden/de-emphasized via jQuery etc.

 

I'm not really sure what you are getting at.  For Facebook and Google+ (as examples) you don't specify these things - rather, they pull the data they need from OpenGraph and Microdata formats in the raw HTML of the page.  There is literally no real way to specify this data with the share link plugin itself.  Of course we will use the correct microdata/OG tags in the output itself.

 

Wondering if we'll ever have the ability to download entire threads as pdfs or something similar...probably not possible for those larger threads...

 

What I have done long long ago is installed a PDF printer driver (many people do this - I think Mac may even come with one standard).  Then you can print any page on the internet as a PDF if you want. :)

Link to comment
Share on other sites

  • Management

I don't want a webpage though. I'm talking about the ability to download an entire 10 or 15 page thread with one click. Kind of like the archive PM feature.

Unfortunately there are technical limitations in the way web servers work that make it difficult for us to distribute a feature like that as it would not work on all web hosts.

Link to comment
Share on other sites

I look forward to seeing how the pre-built plugins are implemented.  Ideally we'd like to be able to specify different share plugin configuration/output for a given service depending on what app you are in.  For instance what you want to send to facebook or G+ would likely be different if you are sharing an image from IP.G vs an article from IP.C or a Topic from IP.B etc... 

 

Any chance of being able to use something like block templates to handle the output?

 

Agree with TSP on it being useful to kinda focus on a small handful and have the others available but hidden/de-emphasized via jQuery etc.

 

 

Here my personal interpretation

 

When sharing in Twitter we are limited,   Where on G+ we have a some options not being the same as Facebook and vice versa. One good example is the message box in Hootsuite

Link to comment
Share on other sites


When sharing in Twitter we are limited,   Where on G+ we have a some options not being the same as Facebook and vice versa. One good example is the message box in Hootsuite

 

Can you elaborate?  What options do you have when sharing to Google+ that aren't available for Facebook, but are supported?

 

At the end of the day we are implementing the javascript social sharing widgets that the providers give - we aren't manually building forms to share to these providers, so whatever code an individual provider makes available is what we are using, and similarly whatever features they are making available in that implementation would be what is available (and beyond our control).

Link to comment
Share on other sites

I'm not really sure what you are getting at.  For Facebook and Google+ (as examples) you don't specify these things - rather, they pull the data they need from OpenGraph and Microdata formats in the raw HTML of the page.  There is literally no real way to specify this data with the share link plugin itself.  Of course we will use the correct microdata/OG tags in the output itself.


Fair enough.  
 
I haven't worked directly with the share widgets so I wasn't aware that there was no per service formatting going on, so you're saying that it's just a pointer to the original page and the social media platforms scrape from there?  That's too bad, it would be enormously helpful if we COULD define what's sent to the various social media platforms via the sharelink system.
 
I was hoping that we would have the ability to exercise some control over the content of what is shared via the share link.  One of the reasons that would be useful is that the different systems use different markup standards IIRC (Facebook uses OpenGraph/OG which largely uses meta info in the header, while my understanding is that other social network use other standards such as schema.org, RDFa etc), so trying to build the basic page to support ALL the different markup systems could get problematic, esp when you start working with things like custom IP.C DB display templates etc.
 
James
Link to comment
Share on other sites

Fair enough.  
 
I haven't worked directly with the share widgets so I wasn't aware that there was no per service formatting going on, so you're saying that it's just a pointer to the original page and the social media platforms scrape from there?  That's too bad, it would be enormously helpful if we COULD define what's sent to the various social media platforms via the sharelink system.
 
I was hoping that we would have the ability to exercise some control over the content of what is shared via the share link.  One of the reasons that would be useful is that the different systems use different markup standards IIRC (Facebook uses OpenGraph/OG which largely uses meta info in the header, while my understanding is that other social network use other standards such as schema.org, RDFa etc), so trying to build the basic page to support ALL the different markup systems could get problematic, esp when you start working with things like custom IP.C DB display templates etc.
 
James

 

Here's one example

 

https://developers.google.com/+/web/share/

 

As you can see, the url is really the only thing you define, and it describes how that is pulled.  The share plugins DO have the url and title passed in, so if you build a sharelink integration for a service that requires you specify the parameters (for instance, I believe with Reddit you pass these as parameters), then that's fine.  Many of the services though use markup on the page.  It is simply how they are designed to work.

Link to comment
Share on other sites

"We have also decided to remove the "print" and "download" share links at this time."

 

 

Has there been any thought to a "Printer Friendly" button? Just a black and white version with minimalist formatting, and no frilly wrapper stuff. 

 

I'm sure everyone knows how annoying it is to try and print a forum, and how much ink and page-wasting garbage is in the default output. 

 

Edit: One possible implementation of this may be to revert to the mobile theme, or a derivative of it, for printing purposes. 

Link to comment
Share on other sites

"We have also decided to remove the "print" and "download" share links at this time."

 

 

Has there been any thought to a "Printer Friendly" button? Just a black and white version with minimalist formatting, and no frilly wrapper stuff. 

 

I'm sure everyone knows how annoying it is to try and print a forum, and how much ink and page-wasting garbage is in the default output. 

 

Edit: One possible implementation of this may be to revert to the mobile theme, or a derivative of it, for printing purposes. 

 

You will be able to print directly from your browser, and it will use a printer friendly stylesheet.  An extra button actually doesn't do anything more than force this style sheet, which is already present and used by the browser when printing.  This is done by defining a "media" attribute for your stylesheets - most stylesheets are media="screen" and are used when rendering the page normally, but you can (optionally) define media="print" to specify different styling when printing, which is what we will be doing.

 

Note that we do this in 3.x as well - we simply have an extra button to force this stylesheet.

 

 

There is no mobile theme in 4.0 - we are using a single theme which is responsive (that is, it will adapt depending upon the screen size automatically, without the need for separate themes)

Link to comment
Share on other sites

Why are the share links so small?  And on my site they are right down the bottom AFTER all the comments. Not really encouraging and share is people have to go and find them.

 

I would like large share links at the side of /or top of preferably or at least at the bottom of the post.

Link to comment
Share on other sites



Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...