As I've been getting involved in the Sharebar issue queues, I've noticed that a lot of the issues seem to relate to managing when and how the Sharebar is displayed, via the module's settings page. Personally, I find the "Add Sharebar" section of the settings somewhat counter-intuitive, and also inconsistent with the way people are accustomed to managing visibility in Drupal (in the core Blocks module or the contrib Context module).

In thinking about how best to address this problem, I thought it would be smart to drop back and have a discussion about an overall approach to a 7.x-2.x version of Sharebar. So, to kick things off, here's an overview of the open issues:

Managing Sharebar visibility and settings

Major feature requests:

Minor feature requests:

General: Theming Challenges / Module conflicts / Bugs / Support / Etc

Administrative

Proposed approach for next major release

Managing when Sharebar is visible seems to be the biggest pain point for users, so I'd like to propose that those settings be refactored to more closely resemble the visibility settings used by the Block module, which users are accustomed to. In addition, I think we should add several Context Reactions to allow users to manage Sharebar's visibility through the Context module if they choose.

Since refactoring the visibility settings risks causing problems for existing users, I think this work should be done in a 7.x-2.x branch, and that the 7.x-1.x branch continue to be supported until most users have transitioned to 7.x-2.x. Other bug fixes and feature requests would be introduced first in the 7.x-2.x branch, and then selectively rolled back to 7.x-1.x. The lone exception would be #2106887: Add token support, which is nearly ready to commit and could be introduced in 7.x-1.x before the 2.x branch is created.

Discussion

Co-maintainers and all other users, please chime in with any feedback about this proposed approach.

Comments

david_garcia’s picture

david_garcia CreditAttribution: david_garcia commented

I've been dealing with this module recently so i'll spit in some ideas:

- If going to open a v2 branch, and going to refactor whole module, consider using module xAutoload (as a dependency of sharebar) and adhere to D8 coding standards as much as possible, that will enable a smooth transition to D8 and possibly enable easy maintenance of D7 and D8 versions in parallel for a while.

- Visiblity "per page or node type" is not a good approach, enpower users and give them the tools to show the sharebar wherever they need it: as a block, as a configurable field in views, even as a field or a context reaction.

- With token support, we open the door to have per bundle sharebar settings, that would be nice. No more per node stuff, let's move forward on the use of entities!

- Maybe you could define more than one sharebar settings group, then link each of those settings with different bundles, or chosse wich setting to use when configuring the view, field or block.

Just some ideas, there's tough work to be done with this module.

Greetings,

bradweikel’s picture

bradweikel CreditAttribution: bradweikel commented

David, could you point me towards any specifics regarding Drupal 8 coding standards? The general Drupal coding standards are version independent, and once I start digging into this module I'll be using Coder module (and maybe coder_tough_love) to enforce coding standards, but I'm wondering if your comment was referencing something else?

I might split some of your suggestions out into a v3, or at least v2.1, so v2 doesn't get delayed too long. But I agree that maximizing overlap between D8 & D7 versions will be helpful for long-term maintenance.

SocialSEO’s picture

SocialSEO CreditAttribution: SocialSEO commented

Thank you for your message.
We plan to do an update for the Sharebar module soon.
We will be happy to use all the recommendations for the update.

bradweikel’s picture

bradweikel CreditAttribution: bradweikel commented

@SocialSEO -- Could we meet via IRC or email or some other forum to discuss managing this module going forward? I've spent a lot of time reading through the issue queue and familiarizing myself with the code in September, because it seemed like a module that was largely neglected, and then I had the currently listed maintainer (nmudgal) give me commit access so I could start to move forward on both stale issues in the issue queue and also a future version.

I was quite surprised to see your message here, because you aren't even listed as a maintainer on the project page anymore, and I had no idea you were still interested in maintaining this module. I don't want to hijack someone else's module, especially if you are indeed planning to do major work on it soon, but I'm also happy to collaborate with you on it (and with nmudgal, if he still interested in contributing) and would like to see the time and effort I've put in so far pay off soon. Could we put our heads together to discuss collaboration?

SocialSEO’s picture

SocialSEO CreditAttribution: SocialSEO commented

We are developing ShareBar module updates list for next release since last module update was made in March, 6, 2014. We'll publish the ShareBar module release roadmap soon.

nmudgal’s picture

nmudgal CreditAttribution: nmudgal commented

Brad,
Quite a plan! Thanks for summing up everything here :-)
Let's do one thing. Let's first remove the issues under these two categories "Managing Sharebar visibility and settings" && "General: Theming Challenges / Module conflicts / Bugs / Support / Etc" and release a version. We can work on feature requests later, people can live without that for a while right? I can surely pickup few items and cross them off!
Yeah, you're quite right, it's been ages :P So let's cleanup the mess a bit and then we can see what 'socialseo' has, for us in bucket and along with that we can work on refactoring the code according to d8 standards as david is suggesting. Thoughts??