Problem/Motivation
We currently are completely dependent on addthis.
The general abstraction of Sharemessage is vendor independent.
This is a lock-in and addthis has multiple disadvantages such as their markup does not validate as HTML5 (causing validation W3C validation / certification issues).
Also, customizing the appearance is very limited.
Proposed resolution
We could integrate with a different sharing gateway service or directly integrate a local sharing script.
One option is this script:
http://sharrre.com/
Remaining tasks
* More research about addthis alternatives (services) and create list / tickets
* More research about alternative scripts
User interface changes
@todo
API changes
@todo
Comments
Comment #1
miro_dietikerNow that ShareMessage is short before getting pluggable, i'm excited to see this happen soon! :-)
Comment #2
sasanikolic commentedComment #3
miro_dietikerComment #4
sasanikolic commentedHere is the first step.
Things to do next:
Comment #6
miro_dietikerWe should enable some default services.
Didn't properly rebase?
Is there no minified version?
Anothr revert?
Comment #7
sasanikolic commentedRename settings, added the min js, fixed tests (rebasing) etc.
More things to do:
- clear cache after saving plugin settings ( ->invalidateTags(['rendered']))
- define the default styling and custom styling
- fix the default styling
Comment #9
sasanikolic commentedHmm, strange, tests are passing for me locally. I will retry uploading the new patch again.
Comment #11
miro_dietikerI think the config values are supposed to be lowercase underscore separated? (and so are the form keys.)
Codestyle (spaces) and lines below.
Prefix it with sharemessage_?
Oops... This is telling mit that things don't work when A sharrre and an addthis thing is present at the same time!
Can you please extend the sharemessage_demo with placing a second message for Sharrre?
I also realise that the demo does not cover images configuration...
Sharrre and not AddThis. And there are other similar locations.
This does not return the "default" settings. It still contains the overrides. Only use the term "default" in an API if it is the global default.
This text is totally meaningless. If anything, then link to the provider and or describe what it is! Same applies for the existing AddThis description... ;-)
And what if unchecked?
Still no idea why the test fails!
Comment #12
sasanikolic commentedDid lots of renaming, CSS changes and other changes for the comments below.
Also, I opened a few issues related to this / followups.
Comment #14
miro_dietikerIs it possible that the AddThis plugin tries to connect to addthis to load the services definition and that fails with a timeout because the testbot does not allow external connections. As a result no services are available and none are output.
The module has a switch to use the local file for the definition. Then things should pass - or at least chances exist.
Comment #15
miro_dietikerAnd we are missing sharrre specific tests. :-)
Comment #16
sasanikolic commentedOn @miro_dietiker's suggestion, I'm posting a combined patch with open graph headers only patch and a OG no-test patch.
Comment #19
miro_dietikerCodestyle :-)
Fix location - either determine the URL of the bot correctly by API or use assertPattern()
Comment #20
sasanikolic commentedFixed the link in the test, the inheritdoc for getSetting and codestyle in OGHeaders.
Comment #22
sasanikolic commentedTesting the testbot with the option "Use local service definitions file" enabled.
Comment #24
berdirThis can not be related, this setting is just what's shown in the settings form.
I know it's annoying but we can't add this, we need to rely on libraries module and make users download it.
there is no such thing here.
lies!
All of those methods should have default implementations in the base class, so remove the empty methods. add them if necessary.
remove this.
doesn't need to be public.
Use $this->t() everyhwere in here.
Comment #25
berdirCan reproduce those test fails.
The reason is simple enough. The new og headers plugin or probably before sharrre is the default plugin now. So we no longer use addthis but ogheaders.. obviously nothing works anymore then ;)
We should make sure that the default is addthis for now. Possibly just as a fallback default value in the form, instead of the first, pick addthis. Or we could introduce a weight on the plugins and sort them by that.
Also, the list builder should show the plugin in the list now in a new column.
Comment #26
sasanikolic commentedSome of the these changes broke the og tags plugin and the tabs of sharrre plugin is now not displayed.
Have to check tomorrow to see what exactly is happening, but a review would be welcome.
Comment #27
miro_dietikerYeah, time to get this in... :-)
Now you also provided here the OG plugin.. I thought we stay with the sharrre plugin and add the OG plugin in a separate issue #2600094: New plugin: open graph headers only
Why are we mixing now?
We should be describe a bit clearer about what is happening here.
Comment #29
sasanikolic commentedRemoved OG headers plugin patch and its changes, removed the min js, extended a comment, fixed local test warnings - min js version.
Comment #31
sasanikolic commentedExtended the test, made the library also external and some other changes.
Comment #33
miro_dietikerHmm... skipped?!
Comment #34
sasanikolic commentedUncommented the test, removed the library dependency, made a new validation function for Sharrre settings form, ...
Hopefully now the tests will be green.
Comment #35
sasanikolic commentedChanged some comments and switched some things around.
Comment #36
miro_dietikerYeah we are almost there! ;-)
Example initialisation? ;-)
That's not allowed here.
Plugins need to check stuff on their own.
Thought we moved this into the builder?
Then let's name it checkConfiguration()
You want to have a test that checks the error message when configuration is missing.
Comment #37
sasanikolic commentedFixes for #36, rebased correctly, extended the plugin base and moved the validation into the plugin.
Comment #38
miro_dietikerYay! Looks fine now.
And fine to cover more in followups...