I couldn't help noticing yesterday that on the Graph API, a normal request for a page you're owner of, (like let's say http://graph.facebook.com/AnyPageYouAreAdmin with you being authenticated (you can try the call here)) would return a new field. This field is called 'new_like_count' and I kind of imagine what is it for. I can guess it will measure the growth of your fans.
What I would like to know is some extra information about it, like for how many days Facebook counts a 'like' as 'new' and these sort of specs that will make the field useful for developers.
Thanks in advance!
Julio,
The new_like_count is the number of new likes since the page has been viewed - this is only viewable by the page admin.
Related
First of all, I must confess that I'm very, very new in TYPO3, therefore, my questions might be a bit confusing or not properly understandable. So, please be patient with me.
As already stated in the title, I want to create a login page for multiple users and every user should see a customized content, for example some pdf files or slides.
I was able to create a login page and it's working but I have no clue what's happening afterwards. I'm searching for a solution since days but the TYPO3 documentation is super shitty, especially for beginners like me.
My idea was to work with a MySQL database (I don't even know if this is possible). After the login all data about the customer are read from the database and defined files (some pdf and slides) should be shown.
Is this possible like that? Or how is the usual way to do that?
I'm happy for every hint!
Thanks a lot in advance :-)
cheers,
expikx
I tried to find a solution online but without success
you need a custom extension which will render the files based on the logged in user. By using the extension "extension builder" you can create a first version of your extension very quickly which can be used as base.
If you are german speaking, take a look at the videos of Stefan, e.g. https://www.youtube.com/watch?v=dhRBvTZoPQM& which document how to create an extension as well
If you use the Login of TYPO3 you can also use the access-management from TYPO3 for FrontEnd content:
for each erecord (page, content, news, ...) you can decide which group(!) of users can see it.
Each record in TYPO3 normaly contains a field (in the access tab) to select which groups can see this record.
It's up to you to define the groups each user belongs to.
And each group can access some content. TYPO3 merges it and even can give access to one record to multiple groups.
Regarding files like PDFs: if you do not need absolute access restrictions it would be possible to only list links to the files for the apropriate groups. (other users, even not logged in users could access the files if they know the URL)
e.g.:
You have users in three groups like owner of product A, product B, product C.
Of course there are owners of multiple Products.
For each group you can provide content like manuals, updates or lists of service points.
First you can give access to the pages about each product only to member of the matching group. All the content of that pages are visible only after login and if the user belongs to that group.
But you also can have mixed pages:
Maybe news where all updates are shown. Although each news record has (at least) one group to be shown to.
There could be one page with the news plugin to show all news. After login only those records are shown which belong to the groups of the user, other records are hidden. (not logged in users can see only records not restricted to any group)
If you want a individuality of content by person you need a group for each user.
If you want the user to select by himself what his interests are you need a FE plugin where he can select his memberships of individual groups.
While it would seem to be a bug, it's always been true that LinkedIn's r_basicprofile API permission only returns the user's current positions, while r_fullprofile returns current and past positions. But with today's announcement that r_fullprofile will require enrollment in LinkedIn's partnership integration program, this difference has a real consequence: Many LinkedIn-integrated sites will no longer be able to get past positions.
My question is to LinkedIn API folks: Is it deliberate that past positions are not returned for r_basicprofile requests? Hopefully not, and hopefully this could be fixed. Alternatively, three_past_positions could be enabled for r_basicprofile... That'd give us something to work with.
If everything is working as intended, and no changes will be forthcoming, how difficult will it be to join the partnership program? Do you foresee many companies and start-ups being able to join?
Thanks!
I think that #JoseR answer was extremely close... the part that was missed was that of within the 'field' description it states:
positions -> An object representing the member's current position
https://developer.linkedin.com/docs/fields/basic-profile
so, if the member has ten 'current' positions, it will return ten, but if they only have one, then just one is returned... so, to get the r_fullprofile is your next best option (with application of course)
As we can see in https://developer.linkedin.com/docs/fields/basic-profile is supposed that now in the basic profile we are going to get all the positions, at least it does not say anything about any restriction to the current ones.
But please I'm +1 in this question. It would be good to have some confirmation from the linkedIn staff that, when accessing the new API, we are going to get all the positions.
Thank you.
I'm running a contest on the web where the image with the most likes wins. It's tiresom having to go through 900 images manually so what I want to do is, sort all images with the tag lets say #computer after the amount of likes, with the most liked pics on top. I have searched the net like crazy for some program or site that does this (ExtraGram, gramhoot, statigram, webstagram) but none offer to sort by amount of likes and it drives me INSANE! It's a really relevant request.
I've tried istafeed.js but it doesn't include all images, actually it leaves out the ones with the moest likes which defies the purpose.
There's nothing I know of in the Instagram API that sends back media sorted by likes in advance. I don't think there's a tool to do this either, but writing one is relatively simple IMO and I've done it before for a contest specifically.
The simplest thing to do is to do the following:
Use the Instagram API (via a library or pure REST) to query by tag. For instance, if you only care about the most recently tagged media or you want to process by date, you can use the [/tag/tag-name/media/recent][1] enpoint.
Page through each result page by processing the next_max_id/next_max_tag_id.
Collect the results locally into a database. You will receive the "like" count for each media item. You will have to update the data if you want to track the likes over time.
Sort the results using your database or if it's a small result set, you could skip #3 and just sort in memory.
If you need to refresh the results, you need to subscribe to the Tag via the API. You can give Instagram a URL to then push updates, and then you'll have to retrieve 1 or media items and update them in your database accordingly.
You will of course need to register your application with Instagram to get an API key if you want to do this. Then you can either send them your client_id or use OAuth.
The best way to achieve this is to pull the photos in and then sort them programmatically based on the likes numeric value. I've designed a plugin that does this automatically for you for anyone interested.
Instagram Journal
Sorry the title isn't very descriptive, but here is what I'm trying to do:
I am making a website that handles student group funding requests. A particular request for funding could involve any number of items. I have two tables: requests and items. A group begins a request by filling out a "request" form, which contains a brief summary of the request, a category (speaker, advertising, etc.), and some other fields necessary for the bureaucratic process. That works fine and was handled pretty much entirely by scaffolding. The problem I'm having is with the "items". I would like the user to click the "submit" button on the new request form and be taken to another page at which he can add any number of items to the items table, all containing in a field the id of the request he just submitted.
The front end appearance doesn't really matter - it could all be on one page - what's important is that the user submits information to one table and then submits information to a second table, with the info sent to the second table containing something that connects it to the information just submitted to the first table.
As you can probably guess, I'm pretty new at rails (I went through the book Head First Rails and I'm working on my first project), so I'm looking for a general explanation about how this can be accomplished.
I recommend you to read / watch this tutorial. It is quite good.
UPDATE:
http://railscasts.com/episodes/196-nested-model-form-part-1
Hope it helps.
Let's say user A follows user B, and B follows A. I want to know the exact date A started following B and viceversa.
Is this information stored on twitter? Can I retrieve it using the API?
To clear out: The point of this question is finding a way to know who followed who first.
(I'm assuming both A and B deleted the notification e-mails)
No Ignacio, you can't. You just can know who follows who but not the date the follow started.
Looking at the API, there's is no way, there are two calls to get the followers:
User Methods/statuses/followers
and
Social Graph Methods/followers/ids
Neither of them returns dates or even a serial that would let you see who started following first. Really, there's no indication that twitter is internally storing this information, neither in the API nor Twitter's web interface.
This is a very old question, but perhaps some might be interested to know that while you cannot get the date at which someone started following, you can at least infer an "earliest possible following date" from the fact that the list of followers is ordered according to date, and the fact that follower objects come with a created_at timestamp.
Here's a Python function for calculating an "earliest possible following date": https://github.com/BernhardClemm/twitter-follow-dates
Of course Twitter stores it, because Twitter sorts followers and following lists by the date ;)
It is possible to do this, but impractical. When you call the followers API you can page the results. Each returned object contains next_cursor and prev_cursor items. These refer to the first and last records in the next and previous pages. These values are time based and can be used to calculate the time that the respective users followed you.
It follows that, if you set the page size to 1, you can walk through the list of follower IDs one at a time and the next_cursor value will allow you to derive the follow time for the next record.
This is reasonably simple to implement, however, in practice, you'll very quickly hit Twitter's API rate limit.