Log article ID in txp_log also please

ande · 2007-01-21 22:46:28

Hello there,

I understand that the page part of the URL will stored in “page” of the logfile to see what url was called. This is OK and the “page” field should just remain there.

What I’d suggest is to store additionally the ID of every article (if hit) in the log too .. otherwise statistics are rather impossible! The style of the URLs used within textpattern can vary from /section/id/title to /year/month/day – we will never able to find out in a generalized way which article it was.. to print a list with titles of the articles, not only the urls. If article titles may change – the worse!

This is the problem of the plugin jas_popular_articles too – the only statistics plugin i found. It stopped development at version 0.1 – for that reason i think.

I could write a wel working statistics if the feature would be available.

Thanks in advance!

ruud · 2007-01-21 23:22:36

ande wrote:

The style of the URLs used within textpattern can vary from /section/id/title to /year/month/day

While you can change the style, normally the URL style will not vary once you have a website up and running. Same applies to titles of pages. You don’t want to change them because visitors bookmark links and search engines point people to old links as well.

ande · 2007-01-21 23:31:10

Thats true, but:

If the /section/id/title scheme is on, a user might only type /section/id – it works but that generates two different urls in the logfile. What if he or she takes a wrong title / id combination?

My problem is that I need statistics, therefore it is hardly possible to “guess” the correct ID when creating the statistics table from “random” and not unique urls given in the logfile, thats my point! And i need to know the ID of the very article as my link to the article should have the correct title inside the link..

if any existing section without any id is in the logfiles – how can i guess which was the article? its not always true it must be the sticky one..!

ruud · 2007-01-22 09:00:29

When both ID and title are set in the URL, only the ID is used. The title is just there to make a more descriptive URL in that situation, so wrong ID/title combinations would still work and give the page for the mentioned ID. I think most people click links instead of entering them manually, so the number of incorrectly entered article URLs is probably negligible.

Statistics are always inaccurate due to browser caching and use of proxies. Most popular statistics tools work based on the URLs entered by the visitor.

ande · 2007-01-22 09:27:51

It is not a problem that the statistics is a little inaccurate as long as we see which page is called more often. We’re not doing rocket science ;) and the blur happens for all pages.

It is a problem however that if we dont have the unique ID any page will have several entries in the statistics, wich IS a problem.

It is true that the visitors click links, but it is also true that the client who operates textpattern does not click but write the link.

Not only the ID is looked up by textpattern, if we supply the wrong section the link will not work.

When you have a navigation containing sections as main level, you put only the section as url – without id. Then it is almost futile to “guess” the right article for a statistics.

Sorry to say that, but I cant follow your arguments against my suggestion as (with all humbleness) you seem not really want to understand my problem. I am not a dumbass and I’m a professional programmmer myself. I know that it is important to keep the code small and not redundant.

The size argument of the database will not be one, as the ID will be only 4 bytes extra – we store IP AND url of the IP already, plus the referrer. Why do we store a log if we cant use it right?

If we had to keep up performance we would not have a logfile inside the SQL, but use apache’s. Im not criticizing, I like textpattern very much for it being small and effective.

In the time we’re writing this I could have done and tested it. The only thing is to write an updater from 4.0.4 upward to add the field in the database when updating. I need no gui changes.

I would contribute code and work also, but if I’d have to explain in several rounds where my problem is before someone says “I understand”, textpattern will get less attractive for me. Are you fighting against anyone so hard before you accept even an idea?

As a matter of fact, I realized already around 10 installations of txp for customers, but if i get too many problems here i will quickly switch.

As I said, sorry to say this.

wet · 2007-01-22 09:44:28

This can be done by a plugin without lacking any functionality, so I can see no use in debating whether this is a useful feature, or not.

Just hook into the textpattern event and log the parsed id into a table or a new column at txp_log.

Last edited by wet (2007-01-22 09:45:15)

ande · 2007-01-22 09:52:24

Ah thats fine, thank you!

Perfect solution if we dont find a majority..

ruud · 2007-01-22 10:43:09

My apologies if I have somehow offended, that was unintentional.

ande · 2007-01-22 10:44:42

No problem ;)

Textpattern CMS

Textpattern CMS support forum

#1 2007-01-21 22:46:28

Log article ID in txp_log also please

#2 2007-01-21 23:22:36

Re: Log article ID in txp_log also please

#3 2007-01-21 23:31:10

Re: Log article ID in txp_log also please

#4 2007-01-22 09:00:29

Re: Log article ID in txp_log also please

#5 2007-01-22 09:27:51

Re: Log article ID in txp_log also please

#6 2007-01-22 09:44:28

Re: Log article ID in txp_log also please

#7 2007-01-22 09:52:24

Re: Log article ID in txp_log also please

#8 2007-01-22 10:43:09

Re: Log article ID in txp_log also please

#9 2007-01-22 10:44:42

Re: Log article ID in txp_log also please

Board footer