Students' final evaluations is over, and only mentors' evaluations is left. During these months, I have been working on projects to harmonize social networking functionality in Drupal and documenting them. Notwithstanding, the Social API project started as an idea for a framework —in fact, the main components provide extensible functionality. Therefore, I documented the process of creating new implementers.
We are getting closer to Google Summer of Code final evaluation. Students must start submitting their project in 5 days. During these months, I have been working on a project to harmonize social networking functionality in Drupal. So, it was time to start creating documentation about it. This week, I focus on documentation for site builders.
Week 10 is over, and we are only two weeks away from Google Summer of Code final evaluation. During these ten weeks, we have been rebuilding social networking ecosystem in Drupal. Thus, we created the Social API project and divided it into three components: Social Auth, Social Post and Social Widgets.
Week 8 is over and we are just one month away from Google Summer of Code final evaluation. I mentioned in my last weekly summary that I would work on documentation about implementing a Social Auth integration.
Week 6 is over, and we are already in the second week of the second half of Google Summer of Code 2016. We are working hard to have the Social API project ready to be used widely before GSoC ends. Furthermore, we are trying to already have some implementors, so developers can see sample modules developed on top of the Social API, Social Auth, Social Post, and Social Widgets.
During this last week, Google Summer of Code students must have submitted their midterm evaluation and waited for their mentors' evaluation. During these first weeks, I have been working on the main components of the Social API project. These components are:
- Social API: contains the basic and generic methods, routing settings, and permissions every Social API sub-module will need
- Social Auth: implements methods and templates that will be used by login-related modules
- Social Post: provides methods to allow autoposting to social network’s accounts
- Social Widgets: allows sub-modules to add functionality to add widgets (like buttons, embedded content) to node, blocks, etc.
The Social API project is divided into four different modules. One of them is Social Widgets (social_widgets), which covers widgets (sometimes called plugins but for the Social API plugins refers to something else) such as buttons (like, tweet, share, etc.), embedded content (post, videos, tweets, etc.), among other things.
So since my last entry about the progress done with the Social API project, I have been working on adapting the functionality of Facebook Like Button (fblikebutton) to work with the Social API and Social Widgets.
The initial point was to declare a module called Facebook Buttons (facebook_buttons) as a integration of Social Widgets, so the module will be listed in the configuration environment of the Social API. To declare a module as a integration of Social Widgets, a Network Plugin must be declared similar to the following.
In the last weekly meeting with my mentors, we agreed to remove the hook that alter the user login. Instead, we decided to use blocks from the Social API parent modules since this is the most basic, flexible and extensible way to render things in the page. This is especially true if you want to provide integration points, and then render based on those on behalf of an unknown number of implementer modules.
Thus, this week on Google Summer of Code I was working to allow site builders implement user login through social network accounts and make this functionality available as a block. For example, the site builder could enable a Social Auth integration, like this version of simple_fb_connect, and customize a block in any region he wants.