Closed amcguire62 closed 9 years ago
assigning to @alexandru-m-g
@amcguire62 Is this required before we go to production?
please add to the next sprint. On 7 Oct 2014 17:12, "cjhendrix" notifications@github.com wrote:
@amcguire62 https://github.com/amcguire62 Is this required before we go to production?
— Reply to this email directly or view it on GitHub https://github.com/OCHA-DAP/hdx-ckan/issues/1427#issuecomment-58209691.
Ok, so it's after the release to production. Removing Alex and moving to product backlog.
please use goo.gl
Serban, my advise to Marianne is use the service which is most standard and causes us lest pain to deploy.
It was agreed @mbellotti would investigate and reply back with ideas
It looks that the google api doesn't answer to our request. We will have to make a hotfix and think how to improve the solution to avoid the timeouts.
disabling this functionality for now:
@danmihaila @mbellotti I was thinking, so that we don't change alot of code and introduce unnecessary AJAX calls, what if:
@alexandru-m-g Most of these problems are solved by caching the response from Google, either via a db table or with some fancy @teodorescuserban magic.
@mbellotti If @teodorescuserban sets up some caching on the server side it won't work on our development environments. We could store the shorted URLs in the db, but I wonder if it's worth the trouble at this point in time.
We don't need to have the shortened URLs rendered on every dataset and indicator page. We only need it when someone is actually sharing the dataset/indicator (so much more rarely ). That's why I was suggesting a server redirect in my previous post (we can use the shortening helper function that you already wrote and which could in the future use some sort of caching if need) .
Why would it matter whether it works on your local devs? Google's url shorten works without an api key, so it's not as if requests made from your dev is going to effect the limit on production. You already said it took 100 refreshes to reproduce the problem.
(I don't really disagree about only generating the link if the user wants to share fyi)
But that means that each page load waits for another request to the google servers to finish ( and this is a server side request not a browser side, so can't even see the problem easily in Firebug). If my internet is down or flaky I might get problems on the page although there's nothing wrong with the page.
I just don't see why the dataset/indicator page should be dependent on a 3rd party service that has not much to do with the information on the page itself.
Yes, but if we're storing the short links only the person who creates the dataset will have to wait for google servers, everyone else will just get the link directly from CKAN.
I can certainly move it to client side, but either way caching the response from google will solve a multitude of programs.
Lets have the chat about this on our call tomorrow
So the issue is cosmetic. It needs to look shorter. Can we try bit.ly?
It is not about what we use, but how we use
@amcguire62 In your court.
@mbellotti , please explain me more about that next time we are online.
At the moment when you hit share you get this link ... " http://data.hdx.rwlabs.org/dataset/sub-national-data-of-confirmed-cumulative-ebola-by-gender" whereas when you click on a story from the NYT you get this type of link "Stopping Ebola in America http://nyti.ms/1CQgzAP" we want links ala NYT or something similar.