I would like to generate statistics for a site, specifically which frontend user is logged in at specific times of the day, how many users are/were logged in, etc.
I have searched but couldn't find any extension that already does this. Does anyone know of either a TYPO3 extension or an external tool that already does this? Will Piwik track the information I am looking for?
We have a compatible extension for tracking FE-User.
Features:
Configure who should be tracked (configurable in Extensionmanager):
only non logged in visitors
only logged in Frontend-User
logged in and non logged in Frontend-User
Configure if the user data of logged in user should be tracked (configurable in Extensionmanager). If you don't track that user data, the tracking records behave like non logged in user.
Optionally track IP-Address (configurable in Extensionmanager)
Backend-Modul with:
Overview about all trackings
Listing by page
Listing by user
Listing by object (downloads, news, shop products, portfolios and more)
CSV export for tracking records
User restriction: Admin user see the whole tracking data. Editor user only the data from current selected page.
Tracking for pages and objects like:
Displaying News (EXT:news)
Downloading Files (EXT:downloadmanager with type restricted)
Products (EXT:shop)
Configure your own object by TypoScript
If it's interesting for you, get in contact with us.
Related
Is there a feature in moodle that allows users (users that have an access, not guest) to enter the course with a link shared by admin?
What I want is that when a user clicks on that link, a login page appears, after logging in, the user is automatically enrolled in that course.
Moodle version: 3.6.2
Without the need of coding, you could enable the self-enrol enrolment method at course level with enrolment key (defaulting to student role), then provide the link to the course to the existing user you wish he/she self-enrolls as student.
The user, once logged in and trying to access the course, will be presented with a form requesting the enrolment key, once the correct key is provided he/she will be self-enrolled as student.
If you want something more direct, like a token based kind of direct authentication+enrol you will need to use an existing plugin (like this one https://moodle.org/plugins/auth_enrolkey) or write your own.
I am in the process of making a social application that involves users and a news feed. In order to display a user's news feed in chronological order, which of the following would make more sense?
Get all posts from each user the person is following and sort them into chronological order
Each time a user goes to post, save that id and the date into each
of their followers profile data (seems redundant)
A better solution that you may know
Generally social sites are built using Graph Database. I have worked on one of the social sites. Below was the technology stack and logic to display the news feeds.
Java, Spring MVC
OrientDb- A GraphDB containing Vertex connected with Edges
JQuery & Bootstrap for UI
Apache Solr- for text searches on User,Articles
Below was the logic for newsFeeds:
When any user does any activity, we used to create Activity vertex containing
the meta-data of activity like dateTime, type of activity and actor etc.
We had a batch program(running after every 3 mins) which will go thr all unprocessed the activities. The onus of the batch is to generate the newsFeeds from Activity and assign these newFeeds_To_Be_Displayed to relevant users(i.e connections of actor) newsFeeds to be displayed on screen.
When the user logs in, we used to query newFeeds_To_Be_Displayed of the given user and display them on screen.
We chose to calculate the newFeeds_To_Be_Displayed asynchronously, as thats a time consuming process and we dint want to end up in bad user experience.
It appears there was a big update to the facebook api a year ago and a lot of the info online is inaccurate because of it. I'm trying to create a website that provides additional function for members of a specific facebook group; if a user is not part of a specific group I don't want them in it. Some groups may have more than 5k users but if I have to settle for less, so be it. I'm using the php sdk and have successfully made an initial api call with general user information.
Administrators of the group WILL be able to log in, but apparently Facebook isn't approving the "user_groups" permission (?) https://stackoverflow.com/questions/31171082/check-if-user-is-a-member-of-a-specific-group-using-facebooks-javascript-sdk
I found this but I'm not sure how to make it work. Facebook Graph - Possible To Check If A User Is A Member Of A Group w/o user_groups?
I'm using the graph api explorer and I can get a partial list of the groups I'm in but it's nowhere near complete (it displays 4 out of like 20). My thought was that if I can get a full list of members in a group that I could just do an [if user is in userlist then]
What would you do here?
As far as I understand there is no way to do this without some caveat where it won't work (when you have more then 5k members). It also causes you to create a copy of the members list, instead of when a user wants to access the group.
I would like to know if I can store more data than a Facebook user id. In the old API it says no.
From ttp://developers.facebook.com/docs/ref … ndardinfo/:
The only storable values returned from this call are the user IDs.
But, could I store data if I do not relate it to the user? For instance: If the user is a woman, and rates something in my page, could I count a +1 women vote in my page without relating to the user?
That information is really old. Long ago Facebook changed the rules so you could "cache" any information 24 hours. Last year they then changed it so you could store it indefinitely. However, there are still rules on what that information can be used for. Look at the question "How long can I store data?" http://www.facebook.com/help/new/?page=1100
Now it's pretty much all based around permissions. Basic authorization gets you basic information about the user, based on their privacy settings. The user may not allow you to tell their gender. If you want more information, you need to prompt the user to grant you access to that additional information. Facebook has even setup a real time API for subscribing to user information changes. For example, you can get "alerted" if a user changes their gender (bad example).
I hope this is allowed but I have a number of questions regarding Facebook Connect, I'm quite unsure on how I should approach implementing it.
I am working on a live music type service and currently have user registration, etc. If I were to implement Facebook Connect alongside this, would I still be able to email the Facebook Connect users as if they were on my database?
Also, would it instead be possible to let users who have Facebook "link" their accounts once registered so I am able to give them the benefits of sharing via Facebook and inviting friends while still having an actual registered user on my system.
I have tried to read up answers to the above questions but what I've found is quite ambiguous.
Thanks, look forward to your views.
Facebook's documentation process is very poor, so don't feel bad about having a hard time getting started. Their wiki-style approach to documentation without any real official documents tends to leave the "process flow" tough to grasp, and requires piecing together parts of a bunch of randomly scattered docs.
Facebook has an obligation to protect privacy, so they never make a user's actual email address available to application developers, through Connect or normal applications. They do have a proxied email system in place that you can use, however, you must get explicit permission from a user in order to email them. There's a decent document on proxied email here. You can get permission by prompting for it; there's several methods for doing so linked in that document.
In regards to linking Facebook and local accounts, this would definitely be the way to go. Once a Connect user logs in, you want to store that fact for that user so you can provide the Facebook-specific functionality. I would simply create a normal user account in the database for every new Connect user that came by, with it's own local id, so that you don't have to do special handling of two different types of user accounts all over the site. That being said, the account would obviously have to be marked as a Facebook user's account (I use an externalId column in my users table), and any part of the site that relied on information you might otherwise have locally would have to handle the Facebook aspect properly (such as using proxied email instead of normal email).
For existing users, you could arrange an "account link" by having a process whereby they log into FB Connect after they've logged into the site already, and you could detect that and simply add their FB id to your users table. After that, they could log in through Connect in the future, or through your normal process. I've never done this, but it should be possible.
If you write the account handling code generically enough, your site will be able to function well no matter what kind of user you throw at it.