nikolayrys / likely Goto Github PK

Здравствуйте.
Как можно использовать иконочный шрифт вместо вшитых SVG?
Может ли мне кто-нибудь в этом помочь?

–––

Hello.
How can I use icon font instead of hardcoded SVG icons?
Could somebody help me with it?

From an email:

Под 9 ios на 5м айфоне Сафари дает нажать на каждую из кнопок только один раз. Потом она остается нажатой. Нужно перегружать сайт - тогда опять можно нажать по одному разу. Проверяли на нескольких телефонах (Ось 9.0.3, версия Сафари зависит именно от нее)

Environment: iOS 9, Safari.

Following #25.

At the moment, we don’t declare what browsers we support. This could be a turn-off point to potential Likely customers.

I’ve looked a bit into the code, and it seems Likely should properly work in all major browses including IE 10–11. However, a deeper check is required to find out the minimally supported IE version.

Why do we need zip the code within gulpfile?

Seems we github release page provides the same functionality, so users can just download the needed version from that page, doesn't it?

How I can reinit it after AJAX call?

The bug was reported in a letter in Jul 2015. The person says that when the Likely <script> tag is placed before <title>, Twitter and VK don’t receive the page title. We need to:

• check if this is still actual (most likely no because now Likely is initialized on a load event),
• and find the way to fix this is this is still actual.

Original source from the letter:

Вчера, правда, обнаружил неприятность с которой пришлось долго разбираться. Если ссылки на подключаемые скрипты <script></script> идут раньше тега <title></title>, то в Твиттер и ВК не передаётся [в ссылке] заголовок страницы. Если ВК это не парит (можно заголовок совсем убрать из ссылки), то с Твиттером это проблема. Обнаружил долгим перебором всего, что может повлиять. Вот, смотришь на html-код — всё нормально, но не работает и всё тут. Возможно, этот можно как-то побороть в javascript’е, чтобы другие не мучались.

Following #58 (diff).

Currently, ESLint checks and fixes only files located in the source directory. It’d be great if the tools configuration files (for example, gulpfile.js) were also validated. As a probable solution, we should configure ESLint to check all .js files except those located in release directory.

PRs are welcome. Current gulpfile.js won’t be validated by ESLint, so it should also be fixed to correspond to the linting rules.

Смотри, у нас есть страница подборки со статьями: http://journal.tinkoff.ru/selected/fraud/
Первая статья грузится вместе со страницей с сервера. Разметка остальных записывается в <script type="text/plain">, чтобы не грузилось сразу много картинок, при прокрутке страницы контент вставляется через innerHTML и парсится. После выполнения innerHTML вызывается likely.initiate() для этой статьи. Для каждого блока .likely в подборке прописан корректный url и title.
Так вот: при лайкли добавляется, статьи можно шарить, но счетчики шаров появляются через раз: в одной статье есть, в другой — нет. Более того, после добавления новой статьи шары могут исчезнуть для старой.

Если что, инициализация вот так происходит: likely.initiate(article.querySelector('.likely'));
article — нода, куда вставляется контент, но сама она подгружается еще со страницей.

This problem is fairly major because Tinkoff Journal is our major user, and the issue is important for them.

Steps to reproduce:

1. Add data-url="http://ilyabirman.ru" to the Likely block on test-history-api.html.
2. Check that the counters are present and represent the share count for ilyabirman.ru.
3. Change the URL by clicking on the buttons.

Actual result:
The counters change.

Expected result:
The counters don’t change.

I'd like to implement Pocket button. Can you please give me any suggestions on how to get countUrl and popupUrl? Where to begin?

Official page: https://getpocket.com/publisher/button.

Иногда виджет инициализируется только после перезагрузки страницы
Например http://www.eyeseestyle.com/en/diary/big-geometric-earrings внизу поста.

Seems it's time to add eslint to avoid comments about code style. Let's try to add some rules based on the current code.

I think it could be good for sites with dynamic rendering

Now we explicitly use config.protocol constant to make right urls for apis. Seems the problem could be solved a little bit simpler: browsers can get the current protocol of the page if some url starts with //.

Expected behavior:
Likely buttons should catch the new URL when the page URL is changed with history.pushState().

Actual behavior:
Buttons don’t update.

(Reported by @mrnix in an email.)

When installing as a bower package, wiredep dependency manager automatically reads bower.json, then look into main param of installing package and include js and css in right places in parent projects.

But, when I've install likely via Bower, i've seen that lekely's main section looks like:

"main": "source/index.js",

Currently in main param missed css file, and index.js file isn't work properly.
So, main param should looks like:

"main": [
    "release/likely.css",
    "release/likely.js",
  ],

You can read more about main section in bower.json and how it should be defined here

Cheers!

Following #31.

• Move test.html to the test directory.
• Move the stylesheet into sources

See network error on http://ilyabirman.ru/projects/likely/

It’d be good to add the CDN links to the README so a user could just drop a script link and go without downloading anything. As an example, we can use npmcdn.com.

There's a section about using likely as a CommonJS-module, and there's just an example of using some method (likely.initiate in this case).

Apparently, it's not enough. Seems we need some API section. Now we have a couple of ways to interact with likely:

• likely.initiate()
• likely(node)

Each of this methods should be clarified.

Firefox 45, Linux:

It looks better if I remove the .likely {font-size:0!important;} rule:

I wasn't able to replicate it on Firefox 45 on Windows, so say if there's anything I can do to help you debug it. Also, it looks the same when I run Firefox in safe mode (so I don't think it's caused by an extension).

Update: replicated on Windows as well.

I researched source, but I can't guess the reason for creating global variables in dom.js. Are they necessary?

It would be great if we can specify some parameter like data-count-empty="true" on the .likely root.

This parameter should force likely to display 0 in counters if they're empty.

Steps to reproduce

• load the test page
• perform likely.initiate() in console

Actual

Counters disappeared

Expected

Counters stay the same as after init

The Telegram button implemented in #23 can currently only share a specific URL. Telegram also allows to specify the message that will appear next to the URL, and @ilyabirman suggested that we implement it. Let’s do this.

I suggest to add the data-text attribute to the Telegram button which can be used to specify the message. The button code will look like following:

<div class="telegram" data-text="Ilya Birman">Send</div>

The attribute should translate to the text parameter of the sharing URL. The URL will then look like following: https://telegram.me/share/url?url=http://ilyabirman.net&text=Ilya%20Birman.

PRs are welcome. PR should also describe the sharing options in the according section of Readme.

The project doesn’t correspond to the open-source quality defaults. Let’s make it better.

• Specify safe semver ranges for dependencies (PR #42)
• Add .editorconfig
• Add contributing.md (issue #17)
• Add linting for JavaScript (issue #28, PR #29)
• Add linting for Stylus files
• Configure the Travis CI (issue #30, PR #39)
• Update the project structure (issue #32, PR #141)
• Add automated tests (PR #73)
• Improve the code (refactoring and related stuff) (issue #120)

Likely buttons should search for url to share in the following places by order:

1. own data-url attribute
2. <link rel="canonical" href="..." /> in the head of the page
3. the address of the page

According to https://yoast.com/rel-canonical/ :

Facebook and Twitter honor rel=canonical too. This might lead to weird situations. If you share a URL on Facebook that has a canonical pointing elsewhere, Facebook will share the details from the canonical URL. In fact, if you add a like button on a page that has a canonical pointing elsewhere, it will show the like count for the canonical URL, not for the current URL. Twitter works in the same way.

If the page already has rel=canonical Likely should use it. On www and non www domains, on any other mirrors and even on localhost Likely will share correct url and show correct number of shares without additional settings.

The most obvious reason is that all live projects written on it: working on a same syntax is much more easy than switching between different. With Babel, which can convert ES6/7 to ES5, no need to worry about compatibility with older browsers.

On script load there's an error in console:
Refused to execute script from 'http://share.yandex.ru/gpp.xml?gid=0&url=http%3A%2F%2Fnanobilet.local.ticketscloud.org%2Fe%2F55d468139cb53842cb27ec03' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.

Chrome / MacOS

http://ilyabirman.ru/projects/likely/

initate
Did you mean: initiate
— Google

TypeError: Cannot read property 'counter' of undefined
http://leningrad.lv/addons/likely/likely.js:4

Have no idea is it a bug or what.

What do you think about adding GitHub star button?

Hello! Please, extend documentation with next:

Using with webpack

First, make sure that you install json-loader

Next install likely via npm

Then, in code:

\\ on document ready or in the end
require('ilyabirman-likely').initiate();

Thanks!

It would be nice to have a LinkedIn share button.

We received a letter asking how to make the buttons oriented in a column instead of a row. This can be done by placing <br />s between the buttons:

<div class="likely">
    <div class="facebook">Share</div><br />
    <div class="twitter">Tweet</div><br />
</div>

This should be documented in README.

Something about

<div class="likely">
    <div class="facebook">
        <svg class="likely__icon_facebook"><custom-facebook-icon /></svg>
        Share
    </div>
</div>

@iamakulov can we avoid to commit right inside the master? In this case followers can't see the changes, github illuminates in notifications only pull requests.

In February, a person reported that the Google+ counter doesn’t work, whereas social-likes (the project Likely is built upon) fixed the counter in 3.1.0. We need to:

• check that the bug is still actual,
• and find what changed and fix the problem on our side.

Original source from a letter:

В Лайкли счетчик Гугл+ так и не заработал, хотя у Артема Сапегина в релизе от 10 января написано "Fix Google+ counter" https://github.com/sapegin/social-likes/releases И в Яндексе он тоже работает: https://tech.yandex.ru/share/

Currently, Webpack users have to install json-loader to use Likely in their projects (see “Using with Webpack”). This is required because main in package.json points to source/index.js, and one of the source files requires a JSON file. The requirement to install json-loader is unfriendly, and we want to remove it.

To fix this, we should switch to UMD builds and make main point to release/likely.js. Currently, we use Browserify for the build process. I’ve googled a bit, and it seems there’s no easy way to create a UMD build with Browserify. So most likely we’ll need to switch to Webpack.

PRs are welcome. Feel free not to switch to Webpack if you find an appropriate way to create a UMD build with Browserify.

The PR should also update the “Using with Webpack” section in the Readme. As #40 that updates the Readme is still open, you are probably better to rebase upon the update-readme branch.

I think it would be good to clarify

• who should update version of package,
• should contributor build new release and add it to pull request or not,
• other things.

And GitHub suggests to add such information to CONTRIBUTING.md file.

We use the config protocol for urls in some services and the others are https only.

Why we need config.protocol in such case? Maybe all services should be https only? Seems that all apis work on https and http-sites can request https without any penalty.

Now url

https://graph.facebook.com/fql?q=SELECT+total_count+FROM+link_stat+WHERE+url%3D%22http%3A%2F%2Filyabirman.ru%2Fprojects%2Flikely%2F%22&callback=random_fun_1

responses with a error

(#12) fql is deprecated for versions v2.1 and higher

Facebook counter doesn't work. We have to update API call.

Following #43.

There’s no real requirement for this yet, but this will make us more flexible in the future. PRs are welcome.

It would be convenient to check codestyle (and autotests in the future) on every pull in Travis, so we don't need to check out the branch and make sure that everything's okay every time.

See #59 (comment) for example.

Most likely this is happening because npm test runs ESLint with --fix option, so ESLint fixes some rules locally on Travis and doesn’t generate any errors.

http://bower.io/ Очень нехватает.

Steps to reproduce:

1. Go to Tinkoff Journal, wait until the page is loaded.
2. Open the console, refresh the page.
3. Check a Facebook counter request (filter by ?id=) in the network tab.

Expected result:
The request returns a JSONP response with the share count.

Actual result:
The request returns a JSONP response with an error:

{
   "error": {
      "message": "(#4) Application request limit reached",
      "type": "OAuthException",
      "is_transient": true,
      "code": 4,
      "fbtrace_id": "Ap5Jr2xVCxj"
   }
}

Looks like this is caused by a lot of Likely buttons each doing a request to the API (e. g. 101 requests total on the Tinkoff Journal’s main page).

Possible solutions:

• find another, less limited API method for getting the counter,
• find a way to increase the limit for this API method (by providing a token probably?)
• detect multiple Likely instances on the page and do a single ?ids=<url1>,<url2>,... request instead of multiple ?id=<url> ones (this way is pretty hard).

Following #29.

@vitkarpov, I’m going to do this on my own as I have some time. Are you OK with this?

Likely 3 should include some major feature additions, and we want to bind several breaking changes to this release. There’s neither a concrete date nor a concrete list of features for this version.

• Bundle both JS and CSS into one file. This will let us get rid of Gulp and switch to Webpack completely.
• Remove likely.initate() which is an alias for likely.initiate() and was originally introduced by a mistake.
• Remove likely() in favor of likely.initiate() (see #82 (comment)).
• Join .likely_visible and .likely_ready into a single class: it’s unclear why they are ever separate. (This could probably be a large breaking change because people can rely on one of these classes.)
• Make Likely auto-initialize when being used as a CommonJS module.

The list will most likely be expanded in the future.