Re: Facebook Like Module Drupal 7
Vilma Steiert
Rather than having to manually copy/paste the Like this on Facebook code for each piece of content you (or your users) create, this module will automatically add that code to the end of each chosen node type. You are able to add a Like button which likes a given URL (static, e.g. your homepage) or/and put a dynamic Like button on your page to like the page you are actually visiting.
Using Heartbeat I have been able to effectively make streams of user activities through Rules triggers. However I would like to be able to have users notified of new activities, and keep a count of the number of new activities like in facebook, or even similar to new email counts in most email systems.
I was trying to do this on Drupal 7 with the " fb_likebox" module ( _likebox). To get it to be responsive. Turns out I had to write my own Contrib module Variation and stripe out the width setting option. (the default height option didn't matter for me). Once I removed the width, I added the in the fb_likebox.tpl.php.
This module allows adding the social media like and share buttons to certain document. Having them, you can add or share this document via your social networks. Twitter, Facebook, Google+ and LinkedIn are available by default. You can add more, having edited the template.
The module indicates how many users like the page, allows reading the newest posts of the page and liking them without redirecting the user to his Facebook page. The users with admin access rights can set different Facebook attributes in the block settings.
Facebook Share - It ought to be the same as the Like button but is implemented differently and uses its own button images instead of getting images/style directly from Facebook. Instead, the style is its own, meant to look like the standard Share button but now appears out-dated. You could hack it to use current Facebook share buttons. It just won't match up with the Like button from the above module.
Service Links - This module helps you deal with tons of social media services you've never heard of or nobody is using anymore. There are also hosted widgets like AddThis which offer many social media services but they add their own branding. Only helpful if you need a uniform way to enable sharing across a lot of different social networks.
This module is quite alike to the Easy Social module but it has features which made us add it to this list. At first, the Drupal ShareBar module lets you easily add a "floating" social media submission bar on your website. It means that when you scroll a page, share buttons will move along with content. At second, this module provides more networks which you can integrate with a website. If in the Easy Social module it was only Twitter, LinkedIn, Facebook, and Google Plus, here you can add any from this list:
Choose suitable Drupal modules and improve your website and business. Let users share and like your content and social pages, increase the number of your followers or add the possibility of a real-time messaging.
As the name suggests, this social media module allows you to embed Twitter widgets into the website. You can add the Twitter timeline or a button to your Twitter profile by embedding them as a block or as a field. If embedded as a block you can show your Twitter profile, collection, list or likes from the Twitter page. Twitter Embed Module Link
If you want to add the Facebook like button to your Drupal 7 site, the process is relatively straightforward. To get started, you will need to download the Facebook Like Button module from the modules section of your Drupal site. Once you have downloaded the module, extract it to the sites/modules folder.
Once you have enabled the module, go to the admin/config/fblikebutton page to configure the module. You will be presented with two options for the Facebook like button: Dynamic and Static. Depending on your desired behavior for the like button, you will need to choose one of these options.
By using the Facebook Like Button module, you can easily add a powerful social sharing tool to your Drupal 7 site. This module eliminates the need to manually copy and paste the Facebook like code for each piece of content you create. Instead, the code will automatically be added to the end of each chosen node type, making it quick and easy to get started with social sharing on your site.
We need a realistic goal for implementing our module, and I think Facebook integration is the perfect idea. We will allow the user to "like" our articles by adding a Facebook 'Like' button to each of them. The second task of our module will be to show, in the sidebar, which articles were liked by the users.
Drupal searches for contributed modules in the sites/all/modules folder of your Drupal installation. In case an administrator decides to have multiple sites driven by one Drupal installation, the path to the contributed module will look like sites/subdomain/modules.
First, let's choose a name for our module. Since its task will be to add Facebook functionality to our site, I assume "facebook" will be a proper name for it. We can start preparing the required directory structure for developing our module.
Inside sites/all create a subfolder, named modules. We will store our contributed modules in a subfolder named custom. The Facebook module will reside in the facebook subdirectory of the custom directory. The final structure will look like so:
The code above reveals the required information to be placed in an info file. Notice that we've referenced the facebook.module in the files array. This file will contain our module's code. For the moment, go ahead and create an empty file in our folder.
NOTE: Confusingly, in the case of Facebook there is another submodule called metatag_facebook. However, it is used only to configure integration with Facebook API's like Facebook widgets and the Facebook Connect single-signon system and is not necessary for rich-media posts to Facebook.
I have some familiarity with Square and Drupal Commerce. In 2017 I was tasked with creating the Drupal Commerce and Square Connect integration for the Square Payment Form (now the Web Payments SDK.) However, my wife's site does not use that module. The standard connector provides integration with the Drupal Commerce Payment APIs and uses the native checkout experience inside of the Drupal site. I wanted my wife's web store to leverage Square's Checkout API. This allows customers to check out off-site on Square. The benefit? If their phone number is already in Square's system, it will send them a confirmation code to reuse their existing information. Off-site checkouts like this also gain customer trust when providing payment information. Just about everyone has experienced this when shopping on a Shopify store. The website is customized, but each merchant's checkout experience is the same.
Part of this is identifying what makes Drupal uniquely better than other systems and what its audience is, and that is the content development and site-building experience, the content modeling and views, the module ecosystem and flexible, combinatorial way in which modules work together as a set of flexible building blocks. It's the power of what you can do with the admin interface. Full stop, repeat that. It's the power of what you can do with the admin interface. Anyone saying to use the command line or get out of the admin interface and into an IDE is going down the wrong path (unless, perhaps, it an entirely decoupled theming layer). If that's how I wanted to develop, I'd have selected a framework like Laravel, NOT a bloated, cumbersome, archaic CMS like Drupal. Drupal isn't WordPress or SquareSpace or Wix, and can't compete with them for dead simple things, and shouldn't try (and by not trying, actually stands a chance of BECOMING good at building simple sites as it gets better at building complex ones). But nor is it Laravel or Symfony or Django, let alone Node, so trying to compete with them is a waste of time too. (Again, the best way to compete with them is to become better at what it's already good at, not trying to change its nature to more resemble them, because that's how you pick up their weaknesses along with their strengths.) Stop trying to compete with different technologies, and just try to be the best at being what you already are! And... cater to your audience! Your audience is NOT programmers! It is almost closer to web producers, site builders, people who want to point and click more than deal with an IDE. Like I said, most of them aren't afraid of HTML, or simple PHP even, but the complexities of modern PHP development? They're not going there. The number of site builders Drupal is going to lose far, far outweighs the number of Symfony developers they might gain (especially as the latter number is likely to be zero. What does a Symfony developer have to gain by moving to Drupal, instead of just continuing to use Symfony? Drupal's always been there, and they chose Symfony, why on earth did anyone think they'd suddenly want to use Drupal? Was the lack of Symfony underpinnings the reason they didn't use Drupal before? Please...)
But thus far Drupal 8 is a nightmare to manage. Until Core is updated automatically via "composer update" it takes many wasted hours to update sites, especially when plugins and the core itself have bugs that give the unhelpful "website has encountered a problem" message. There were 4 core updates in the past month. Many of these were caused because modules were put into Core (like Views), and when they had a security issue, Core had to be updated. Symfony has a similar issue. Since my update procedure consists of replacing the Core and Vendor directories and running composer update, I do not see why the replacement steps cannot be put into the composer workflow.
Drupal 8 adoption has tanked because those pushing the things we're seeing have forced everyone to do things their way without making their ways, optional. For example, this whole Composer thing: are we really going to pretend that everyone is okay with being forced to use that just to install something like Drupal Commerce!? They shoehorned everyone into it, completely disregarding how it might be beneficial (or merely convenient and easier) to allow it as an optional component. I keep reading how Composer is the future this, how GIT is the future that, etc., etc. and yet, for every leap forward these things supposedly provide, the massive user experience regression they create is synonymous to taking a dozen leaps backwards especially when you experience that from just installing or upgrading something. These things being involved in the bigger maintenance equation should be trivial point-and-click operations, or better yet, be completely transparent to the entire set of processes involving how Drupal is used or maintained, and yet, despite being in a technologically advanced society where we can make cars drive themselves, allow refrigerators to access the internet, or make little speakers order us pizza from our favorite restaurants by speaking to it, we're consigning to this idea that the only way to use something like Drupal Commerce (or other Drupal modules) is only by issuing commands at a command line!? And we're going to chalk all that up to something we're told we should embrace!? What a joke!
aa06259810