status? roadmap?

[stevekeiretsu]

hello,

looking to make myself useful, as i have a ton of photos on flickr i would like to integrate with my website, if i ever got around to making myself a website (cobbler's kids have bad shoes, etc), this seems like a good project to look at.

as far as i can see the 8.x-1.x branch is just the 7 branch renamed, so far; nothing has been done?

so I should just go away and get on with it and come back when I have a PR?

I mean that's cool, I just don't want to step on anyone's toes or waste my time if other people already have plans or activity in progress.

cheers steve

[dakkusingh]

Hi Steve, Thank you for your interest, I much welcome the enthusiasm and contribution. I was originally going to port this module to be used for Flickr Media Entity module. However, that specific module did not require an API.

This still however does not fill in the need for having a Flicker API module. After having had long and hard and discussing it with my peers, I came to the conclusion that it was perhaps better to either:

1) put effort into making a symfony library that can be used in other projects without Drupal overhead. 2) There are already a number of Flickr API projects available for Symfony, perhaps it is better to evaluate them in the first instance.

In any case, I see the scope of "Flickr API module Drupal" to simply be a glue wrapper to a symfony library.

Please feel free to share your thoughts.

[stevekeiretsu]

hi,

after posting that yesterday i went through the module's code and reflected for a while, I came to the following tentative conclusions

1. I would not attempt to port the module per se, it would have to be more of a 'rewrite'. d8 seems too different especially if one is to follow some architectural best practices (e.g. make this a service, rather than just making a function available). i think i would have to scaffold it with console and then incrementally attempt to rebuild the functionality using the d7 branch as a conceptual reference more than a direct source of code

2. i am frankly confused by the state of Oauth on d8, From https://www.drupal.org/project/oauth

This module implements an authentication provider for Oauth by leveraging the OAuth PECL extension. If you just need to sign requests with a set of OAuth Credentials, you can use the PECL extension as the module tests do, or install the module Guzzle OAuth.

AIUI this (flickrapi) module has no need to act as a provider, we do "just need to sign requests", so there is no need to depend on this (big) library. But Guzzle Oauth declares itself "obsolete", using the PECL extension directly doesnt smell like good practice, and the the fact that "Simple Oauth" has two contradictory purposes on different version branches, and also seems to be for provider/server rather than client use.... I'm left very unclear which, if any, would be the best choice as the dependency for this rewrite. Hopefully if I actually install and try them out I can make some sense of it, but it was not an encouraging start!

3. A realisation that it will be impossible to meaningfully test a flickrapi 'helper/service' module without having another module using the flickrapi module.... so I either have to write that as well...

4. ...or, I was looking at the media entity module. But I see you create entities there by pasting in the embed code? In that case you don't even need the API (like you say). If you were to use the API for a module of that nature, I would have anticipated entities being ID-based so that instead of the width/height of a given size being hardwired into that embed html, they could be dynamically generated according to...whatever (theme/hooks/config/context etc. Like a flickr media entity in a sidebar block could 'know' to load a small thumbnail, but the same entity used in a hero could load a hi-res. etc). I did build something similar as a personal toy in raw php but to fit within the rather complex drupal media ecosystem...

5 ...got me thinking maybe i am biting off more than I can chew by volunteering for this! (I have been building stuff with drupal for a few years but mostly 7 and for internal use rather than contrib standards, so it's ambitious)

So all round I was having my own doubts already. Anyway, I hadn't considered the possibility of Symfony projects already existing. That is a great idea. If one of them can be reused with a little glue, that is probably more achievable!

I will have a look at what is out there.

[dakkusingh]

Hi Steve, I also went through the oauth puzzle for my 500px integration module. And you can see both approaches here to do oauth:

Pecl: https://github.com/dakkusingh/drupal500pxintegration/tree/8.x-pecl-oauth?files=1

Guzzle oauth: https://github.com/dakkusingh/drupal500pxintegration?files=1

Regarding other points: 1) I would encourage a flickrapi lib that can be installed using composer. Keeping it Drupal agnostic has many benifits.

2) pecl, I did not like this approach as it requires system level access and DevOps experience, not everyone will have the skillset or permission from their hosting company. It's a big big dependency.

3) guzzle seems to be the new and preferred way and it supports oauth. Check the code in my links above and u will see how much less code is required compared to pecl

4) glue module might be required to provide a neat settings interface where the admins can enter API keys etc. The actual API work could be Drupal agnostic

5) media entity module is great for adding adhoc Flickr images by pasting in the image is it URL. However, if u need the functionality where you need a block listing latest X number if Images, u would need API access. Example of such complex functionality is the Drupal Flickr module.. https://www.drupal.org/project/flickr

You are more than welcome to collaborate on https://www.drupal.org/node/2902676

I hope this helps :)

[dakkusingh]

Guzzle: https://github.com/dakkusingh/drupal500pxintegration/blob/8.x-1.x/src/D500pxIntegration.php

VS

Pecl: https://github.com/dakkusingh/drupal500pxintegration/blob/8.x-pecl-oauth/src/D500pxIntegration.php