Hi Scott,

Currently the only way to avoid that is to kill the view counter and, if you want to make new comments count as an update, you also need to make a comment register as an update to the post.

To do this crack open evocore/_item.class.php and find this bit and comment it out :-

		if( $dispmore && !$preview && $Hit->is_new_view() && $Hit->agent_type != 'robot' )
		{ // Increment view counter
			$this->set_param( 'views', 'number', $this->views+1 );
			$this->dbupdate();  // move to end of method, if we should have more params to be changed someday
		}

If you want to make comments count as modified crack open htsrv/comment_post.php and add the red bit's :-

$Comment->dbinsert();
$commented_Item->set_param( 'views', 'number', $commented_Item->views+1 );
$commented_Item->dbupdate();

¥

¥åßßå,

Thanks for the code. I just might kill "views" because it is a misleading and innacurate statistic.

Views are only updated when someone clicks the "permalink" or "read more =>" tease. Un-teased post views are skewed low, because they can be read (in their entirety) without hitting the permalink and don't register as a "view". Likewise, multi-page post views are skewed high (each page read counts as a view). So what's the point?

It's very frustrating to LOSE a statistic that WAS accurate (mod_date) for a statistic that isn't (views).

Question: Does killing the view counter restore the mod_date functionality?

TIA

[url=http://randsco.com]-stk[/url] :D

Hi Scott,

Yes, if you amend item.class.php (unfortunately your dates have already been modded in the database by the views, but you could run an sql to copy date created to date modified)

IF you want a comment to count as an update to a post then you would also need to make the second set of changes that I posted.

Personally I'm implementing both changes as it makes "recently commented" a doddle, just pull up all posts in modified date order with a view count, and I really have no use for the view count otherwise.

¥

¥åßßå,

Knowing that "view" stats are skewed lower for non-teased posts and higher for multi-paged posts, they still provide SOME indication of the "popularity" of a post. Any information about readership likes or dislikes are important to me.

So ... with that in mind, I took a different approach, keeping BOTH "views" (though inaccurate) and "mod_date" (just like it USED to be - an accurate, "last-edited" date).

To accomplish this ... I changed the way views are incremented and committed to the database. The original code in /evocore/_item.class.php was changed from:

		if( $dispmore && !$preview && $Hit->is_new_view() )
		{ // Increment view counter
			$this->set_param( 'views', 'number', $this->views+1 );
			$this->dbupdate();  // move to end of method, if we should have more params to be changed someday
		}

to the following: [Edit: Code below edited to incorporate Yabba's code change recommendations]

		if( $dispmore && !$preview && $Hit->is_new_view() )
		{ // Increment view counter
		  $DB->query( 'UPDATE T_posts SET post_views='.($this->views+1).'
         WHERE post_ID='.$this->ID, 'Up your View' );		
      }

Additionally, you MUST remember to add

		global $DB;

to the list of globals at the top of the same content() function (around line 805 "global $Plugins, $Hit, $more, $preview;").

Hope this helps! :D

[url=http://randsco.com]-stk[/url]

PS ... Not sure how I'm going to fix my corrupted mod_date values, now that many are erroneously the "date_last_viewed" instead. I wonder how difficult it is to re-poplulate from a backup? Has anyone done this?

EDIT: Well ... I had a quick boo on the I'net regarding restoration of a single field and ... gave up. In the end .. I did it manually. This corruption cost me 2+ hours of time, but I suppose that's what I get for going ALPHA? (Let's just HOPE that it's fixed for BETA and higher, because anyone using the mod_date field won't be too happy with the new code).

EDIT #2: Code changes made above to incorporate Yabba's suggestions (below)

Hi Scott,

I thought only politicians used skewed stats? :|

You can chage your sql to :-

            $DB->query( 'UPDATE T_posts SET post_views = '.($this->views+1).'
              WHERE post_ID = '.$this->ID, 'Up your view' ); 

Then you only need global $DB ;)

¥

¥åßßå,

LOL ... didn't you know? EVERYONE now uses skewed statistics! :D

Gee ... I was just happy to get it working properly after the shocking discovery that my DB was being corrupted. ;) Your suggested changes make it simpler and more elegant. (I have edited the above post to reflect your erudite, sagacious & more succinct solution. - Thanks!!)

I had the darndest time FINDING the $Item->ID (post number) variable, let alone figuring out the syntax of the $DB->query() function. What's the difference between $Item->ID -vs- $this->ID and why would one require a global definition and not the other?

Also ... One noted difference in the behavior of this method (as compared to Phoenix Alpha out-of-the-box), is that the view count isn't immediately seen on the clicked permalink|more|next-page view (unlike like the out-of-the-box way). One has to refresh the page to see the new view count. (This isn't much of a bother. View stats are for MY benefit, not the reader's). A very tiny price for correcting the mod_date value (posts_datemodified field or $Item->mod_date() function). ;)

Thanks again. :D

[url=http://randsco.com]-stk[/url]

Hi Scott,

Jeez, lucky I got a dictionary for christmas, now I only need a typist :p

The difference between $Item and $this, lol, sheesh, ok I'll give it a shot.

The new code is written in what's called an Object Oriented way, what this means is that you have an "object" that knows all about itself and nothing about the outside world...... tad like an orange .... honest, it'll make sense ........ it'll make "some" sort of sense.

This object knows all about everything that is to do with itself (listen to questions, give answers, ask questions, listen to answers ...... be an orange), but it has no idea who's asking the questions (the farmer) or what's done with it's answers (the consumer), it just knows what IT does (ie/ be an orange).

When you set a variable = to an object it "becomes" that object, and any references are exactly the same as if you talked to that object (the variable is the orange).

so $Item = new Orange() makes $Item an ...... urm, well, a new orange.

But, all an orange knows is "itself" (it could be any orange in an orchard full of them), so when it referers to itself it uses "$this" ("this" orange) so $Item->ID is the same as $this(orange)->ID.

For the orange to "see" the outside world it has to accept a "global" view, even when it's looking at a mirror image of itself ($Item), but obviously, within itself it doesn't need to ($this).

On top of all this you also have collections (urm, they appear to be called caches in php) which are like orange trees ($MainList) which are collections of objects (oranges).

Even if that doesn't clarify things for you in the slightest, I'm damn sure you'll look at oranges in a different light ;)

¥

¥åßßå,

Hmmm. So this is the big internal change in b2evo version 1 & higher? ... that's it's written as object oriented code?

LOL ... I have never heard fo a "globally aware" orange and geez, as my latest post (ironically) indicates ... [url=http://randsco.com/index.php/2006/01/05/orange_in_edmonton]I claim to know a thing or two about oranges[/url]. :p

So, I gather that $Item is more or less a (b2evo defined, but) generic variable name and could have been named anything (e.g. $Blah) and requires a global definition just like any other variable.

But it seems that $item is a special (object oriented) varible that is used to refer to the object itself (and since it always knows about the objects in the "cache") ... it's always available to be queried about itself.

(Hope this is right, otherwise I don't know about oranges as much as I think) ;)

Thanks for taking the time and attempting the explanation. I'll have to find some reference on object oriented coding, b/c it's a new grove that will take a while to grok.

Hi Scott,

Lol, not all oranges are in a penned state :|

This is of course just my own view, but I think Phoenix is far fuller of orange groves than previous versions ..... but hell, I grow Dahlias, so what do I know? :|

$Item, $Comment, $Blog .... yeah, they're just names that refer to the objects that they represent, whereas $this means "this item" (when refering to itself).

A cache is a different thing, it's a tad more like an array of objects that can be passed around, but is (or can be) in itself an object (back to orange trees again :| )

I'm sure if you search for OOP ( lol, how appropriate is that name ) you'll find a million examples that don't even hint at oranges ;)

¥