[#5252] - [#31516] Create JLayout's for common social buttons
- Closed
- 17 Jun 2015
- Medium
- Build: staging
- # 5252
- Diff
- wilsonge:jlayoutsocial
- Foreign ID 31516
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
This starts the process of making some features not already in the CMS available as JLayouts. This starts with:
- Facebook Like
- Twitter Share
- Twitter Follow
- Twitter Hashtag
- Twitter Mention
- Google +1
Note this is the same as my old PR as #1550 except targeted at staging instead of master
Screenshot
Note including them in articles is NOT included in this PR - this is just demonstrating their use
Layout Params
Google+1
- data-size small, medium, standard, tall Size of the icon - default standard.
- data-annotation inline, bubble, none The style of annotation to appear - default inline.
- data-width integer The width of the icon - default 300
- data-href URL The URL for the like to link to. By default the current URL (JUri::current())
- show-count true/false Show/Hide the number of people who have +1'd the page
- language Language string recognized by google Defaults to the locale according to the language (https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/language/language.php#L1244).
Facebook Like
- appid integer The appid if one exists for the like to link with
- data-href URL The URL for the like to link to. By default the current URL (JUri::current())
- data-width integer The width of the icon - default 450
- show-faces true/false Shows the faces of others who have liked the page. Default true.
- data-layout standard, button_count, box_count Layout of button. Default standard.
- data-action 'empty attribute'/like, recommend Verb for the button. Default empty (which is "like").
- data-colorscheme light, dark Color scheme. Default like
- language Language string recognized by fb Defaults to the locale according to the language (https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/language/language.php#L1244).
Follow
- show-count true/false Show the number of users followed. Default false
- user Valid Twitter user The user for twitter. If not entered will give a JLog priority warning.
Share
To be written up (see code for now)
Hashtag
To be written up (see code for now)
Mention
To be written up (see code for now)
Issues
- Is my new language file in a good location and with a good name?
- Twitter hashtag langs don't seem to work at the moment (the other twitter views do)
- Is the location of the social layouts package in a good place?
Testers
- Check multiple instances of each icon work
- Check each icon work
- Check parameters work as expected
- Check multilingual aspect
Suggested code:
$layout = new JLayoutFile('social.google');
echo $layout->render(array());
$layout2 = new JLayoutFile('social.twitter.share');
echo $layout2->render(array());
$layout3 = new JLayoutFile('social.facebook');
echo $layout3->render(array());
$layout4 = new JLayoutFile('social.twitter.follow;);
echo $layout4->render(array('user'=>'GW1992')); // or similar for a twitter username (please don't spam mine :P)
jissues-bot
- | Title |
|
||||||
| Labels |
Added:
?
|
||||||
| Title |
|
||||||
Using a language file with prefix as layout does not look ok to me. A language file should be linked to an extension or library.
In this case, I would rather add the strings in en-GB.ini. That is, if this sort of patch is accepted, instead of a specific plugin.
Have no objection to extending that to layouts. Would consider layout an extension type, without the need for a separate installer. Do suggest to use the naming convention currently in use 99% in core. Meaning to use: en_GB.lay_layout_social.ini
But also agree with @infograf768, what message does this send. Not looking forward to ini files per layout. Not saying this is an ini per layout, but afraid of having that effect. An alternate in use is pkg_, but that is not a 100% fit either.
@test: Adding the above test code gives a fatal error on the current staging branch:
Parse error: syntax error, unexpected '[' in D:\wamp\www\joomla-cms\layouts\social\google.php on line 53
As for the concerns raised above, can't we turn this into a plugin, the plugin would have it's own files and own language files. The plugin itself doesn't respond to any triggers but does add the functionality of added social icons to your page. I am using plugin here since we don't have any specific extension package type. At this moment we only have plugins/modules/components/templates/languages, there is no specific layout option. A plugin that is unpublished would fit best I think, as it can remove the files on uninstall.
I agree this should be a plugin. It's exactly what a plugin should do.
You can then add the JLayouts and language files to the plugin and everythign works as it is supposed to do.
You should even be able to use existing plugin events (before/after content).
But then such plugins already exist on JED. See http://extensions.joomla.org/extensions/social-web/social-share, I can't even count how many there are...
Any convincing reason why this should be in core?
Especially when you have a look at the JED category, you see people want options. Not just Pinterest and local social media networks that we do not know about, but also different styles, button sizes, colours etc etc.
Because there are already a lot of solutions in the JED, and this PR will not be a "full" replacement for them, I would suggest not adding this in core. It's also (if you ask me) more bloat, when Joomla! is actually moving to a small core (removing com_weblinks for example).
It's not personal, I'm just not convinced we need this in core.
At best it should be a "core supported extension" like the decoupled weblinks will be - my 2c
Beautiful extension, but it should live his life out of the core...
89 votes on ideas.joomla.org disagree with this living outside of Joomla core!
@sovainfo That's a pretty bad argument :-)
89 votes is not even 89 people, as you can add up to 3 votes per person. Those people could/need to be educated that there are solutions on the JED, I agree with that. So a large minority of Joomla! users (less than 90!) communicated they want this, and now it needs to be in core? I don't think so.
Limited volunteer time is better invested in the top 5 ideas on ideas.joomla.org (with thousands of votes!), instead of a minor issue which just creates more maintanence in the future eating up limited volunteer time (needs to be maintainced, refactored, new coding standards, new social networks added etc etc).
Looks like some people need to be educated on Layouts!
Thanks for wasting Georges time!
I did not ask him to develop this :-) Ask first, code later.
Wasn't referring to the development time, was referring to get something contributed to core!
Surpised he hasn't given up, as so many have done!
Looks like some people need to be educated on Layouts!
That's for sure, me being first in line! But why this can't be done inside a community-supported extension?
Would it be difficult for George to make the final step and transform this into a plug-in? (I've not looked at the code...)
A core supported extension would be some way to go but I am not sure because it will need the dedication as the extensions get on the JED. Users always want more options.
was referring to get something contributed to core!
That is indeed not an easy process but just because someone builds something it is not a free pass to include it in the core though.
My first question is why we should create and maintain an extension which already exists in over hundred variants on JED.
So I did this yonks ago because it was in this list here https://docs.joomla.org/CMS_Development_Wishlist#Social_media_module_or_JLayout_for_.E2.80.9Clikes.E2.80.9D
To be honest though the advantage I see of this being core managed is that it exists in hundred of variants. When google and facebook change their API's it means there's one single point of truth to fix these things rather than 10 different extensions with their own implementation (like what we did fairly successfully imo with the captcha system)
Perfect case for a "community supported" extension, IMHO...
You can't install JLayouts as an extension. And the JLayouts part to me is important because you can override the default colour schemes etc. for all extensions in one go. Install as a plugin and what do you achieve? Components aren't going to throw a special event to get the social media icons!?
You can't install JLayouts as an extension.
Oops... I missed that! I guess I have to study layouts better and think it over in the meanwhile....
Thanks for point out!
Still think it's wrong to use JLayouts for that kind of stuff.
JLayouts should contain only minor logic and mainly HTML output. Your JLayouts contain a lot of logic and only a few lines of HTML.
That is exactly what plugins should do 
Now if I want to use those JLayouts in my extension, I would have to add many JHtml calls and pass parameters to the JLayout. The user would have to add those same params into each extension which supports it.
On the other hand, in a plugin or module you add it once, and it will work on each page.
Also if Facebook or Google changes the API, you most likely need to change params as well. It will not be only a change in the JLayout.
So I still don't see why we want to add this to core when there are over hundred variants of it on JED.
What are we going to solve by maintaining this ourself?
Thing is HTML layouts in Plugins are gonna be JLayout based soon anyhow with mine and Roberto's work (especially as this is exactly the kind of thing you will want to template override anyhow for colour schemes of the buttons etc.). JLayouts are used to share html code across components - which is EXACTLY what this PR is doing.
The only logic is checking for valid param values which I'll put money on is something most people won't do checks for in a plugin anyhow.
Finally you'd need to add an event in across all the components to render this stuff - something that is unlikely to happen in the forseeable future - what's much easier is to add 2 lines to call the JLayout either by default or as a template override - note there are default values for all the fields - so no params are necessary anyhow (in retrospect not sure the JHtml class has any use).
Setting to Needs Review so that the CMS Maintainers can make a decision on this - otherwise its going to sit here forever
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5252.
| Status | Pending | ⇒ | Needs Review |
IMO unless we intend on baking social features into core, let this one go.
| Status | Needs Review | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-06-17 21:32:58 |
| Closed_By | ⇒ | wilsonge |
joomla-cms-bot
- | Labels |
Added:
?
|
||
Throw it in a repo somewhere, build an extension out of it. Definitely not /dev/null worthy effort.
If there is a way to defer (async, ajax ) the scripts so they load after page fully loaded will be nice for performance...