Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#239 closed new feature (wontfix)

Page managment - satistics for page activity

Reported by: jeanyves Owned by:
Priority: major Milestone: unassigned
Component: BW General Keywords: page managment
Cc: hannu, steinwinde, philipp, micha

Description

I would like to introduce a way to see when a page is used and by who. This will allow to detect problem, dead code, dead page and also will allow to solve in a clean way some issue like the |#236

The idea is to introduce the following tables :

Page table which will have :

page.id (id of the page)

page.created (date the record was created)

page.updated (when the record was updated)

page.SelfName? (the name of the page according to PHP_SELF)

page.IdAuthor? (username of the guy who created the page (default beeing bwadmin, no need to be very strict on this, we will see page by page)

page.Description (role of the page, this is a member view, this can also be a text giving some information, project for this page) This could be display one day at the bottom of the page

page.WikiHelp? (link to a future wikihelp page, and yes we could allow the members to create this help ! and yes in various languages for exemple mymessages_fr / my_messages_en etc ... !) This could be display one day at the bottom of the page

page.IdContact? (a member Id to contact in case of problem with the page)

Then I will also introduce a PageUsage? table for tracing the usage of page by members which will have :

pageusage.id (the unique id of the record)

pageusage.idmember this is a the id of the member who use the page (0 will mean a not logged user)

pageusage.IdPage? this will link to the corresponding page

pageusage.created when the record was created

pageusage.updated when the record was updated

My intent is to put the code as a dedicated class "page" which will automatically create the records at each new page encountered (using $_SERVERPHP_SELF?) and whicl will be updated according to page visits.
Note that this will not be critical at all for database, because it will be updated with and index and with a innodb model, the lock will be at recordlevel. Anyway, I will make a way to disallow the feature - we never now -

About the connection with the #236 ticket : the corresponding record pageusage for the member IdMember? and the value pageusage.updated will be the reference to know for exemple, when the member visitated his messages page to see if he has received new messages since this visit.

Comment welcome

Change History (10)

comment:1 Changed 10 years ago by micha

Before reading this ticket, I was out in the web, searching for a
cache-solution for us. And now that I read it I must say: Isn't this
highly related to a cache-system we could set up? I'm not sure if this
PHP-SELF-tracker is a good base for a caching solution itself but we
should at least think of creating something that is useful in other
areas aswell.

I'm doubting that a page-table will help us with tickets like #236.
The question is not if the user has been on the mainpage or not (this
should not be the indicator for marking messages read/unread) but if
he has actually seen messages (or comments, etc.) in detail (if he
looked at them or marked them as read).

In general I don't like to see too many tables in our DB that are
loosely related to each other. And IF we add tables, I think we should
try to sort them more and more (with starting letters like "mod_pages"
or "admin_pages" or something like this).

comment:2 Changed 10 years ago by micha

I would really much vote for leaving things like these out of the 0.1.1 outreach release. We have to many tickets right now and have to focus on bugfixing with this release...

comment:3 Changed 10 years ago by jeanyves

It seems that $_SERVER[PHP_SELF] cannot work at all in PT plateform (Felix has rememebr me that all page are run thru index.php)

About the feature, I think it must be kept as a major thing (since it will alter the whole website) it is also very important to understand that this will allow global debugging (because it will be a way to measure traffic on pages/features and then to detect anomalies : a pages is never used, or suddenly a pages is used 100x more than the normal, and this with correlation to members profiles (typically : languages, which are important for some bug cases)).

The idea I have, more than providing a way to produce a help on each feature, is to gather data which are to help in the website managment (and to show what is and what is not use in BW).

Anyway, I agree we have a lot of ticket to solve

comment:4 Changed 10 years ago by steinwinde

I'd also vote for removing the milestone marker "0.1.1-outreach-bugfixing". An additional argument: If we really want to do this, lets do it properly and not introduce a quick hack, which has bad results for everything! This feature isn't urgent on a website, which normally has to deal with 3 concurrent sessions. Jean-Yves, could you change the milestone please?

comment:5 Changed 9 years ago by micha

  • Milestone changed from 0.1.1-outreach-bugfixing to BigPicture

comment:6 Changed 9 years ago by micha

moving this to BigPicture?. Hope this is ok.

comment:7 Changed 9 years ago by philipp

  • Milestone changed from BigPicture to unassigned

Milestone BigPicture? deleted

comment:8 Changed 5 years ago by jsfan

  • Cc changed from hannu, steinwinde,philipp,micha to hannu, steinwinde, philipp, micha
  • Milestone Future deleted

Milestone Future deleted

comment:9 Changed 5 years ago by midsch

  • Milestone set to unassigned
  • Resolution set to wontfix
  • Status changed from new to closed

For snooping on users the pikwick-script is in use for ages now. If there are any other issues to be solved with this ticket, I doubt this will happen in the suggested way.

Last edited 5 years ago by midsch (previous) (diff)

comment:10 Changed 5 years ago by shevek

Closing.

Note: See TracTickets for help on using tickets.