so your config shows all plugins disabled except htmlawed.
is that how you were testing?
I'm kind of stumped.
you could try with vanilla statistics enabled.
the addview in discussions model is called from class.hooks via
Gdn_Statistics_Tick_Handler
I don't know what calls Gdn_Statistics_Tick_Handler
another addview is called in class statistics.php
/**
* This is the asynchronous callback
*
* This method is triggerd on every page request via a callback AJAX request
* so that it may execute asychronously and reduce lag for users. It tracks
* views, handles registration for new installations, and sends stats every
* day as needed.
*
* @return void;
*/
public function Tick() {
// Fire an event for plugins to track their own stats.
// TODO: Make this analyze the path and throw a specific event (this event will change in future versions).
$this->EventArguments['Path'] = Gdn::Request()->Post('Path');
$this->FireEvent('Tick');
// Store the view, using denormalization if enabled
$ViewType = 'normal';
if (preg_match('`discussion/embed`', Gdn::Request()->Post('ResolvedPath', '')))
$ViewType = 'embed';
$this->AddView($ViewType);
which adds to cache and throws stuff in analytics table.
if you say you added things in discussion model as above then
if it hits discussion model addview - something should print.
LogMessage(FILE,LINE,'Object','Method',"myincrement is: $IncrementBy");
if you change classhooks.... around line 527
from this
if ($DiscussionID)
$DiscussionModel->AddView($DiscussionID);
}
/**
* Adds items to dashboard menu.
to this
LogMessage(__FILE__,__LINE__,'Object','Method',"pre - discussion id is $DiscussionID");
if ($DiscussionID) {
$DiscussionModel->AddView($DiscussionID);
LogMessage(__FILE__,__LINE__,'Object','Method',"pre - discussion id is $DiscussionID");
}
}
/**
* Adds items to dashboard menu.
it should tell you if addview is bein called.
as far as other error messages maybe @x00 or @linc can chime in.
maybe tomorrow or a later time with more people adding info, we can resolve mystery.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@peregrine said:
so your config shows all plugins disabled except htmlawed.
is that how you were testing?
Yes, I have first tried with the same settings/plugins which are implemented in my production forum, then I have disabled all plugins and switched to the default theme.
you could try with vanilla statistics enabled.
Just tried, made no difference. Nothing showing up in DebugLog.
if you say you added things in discussion model as above then
if it hits discussion model addview - something should print.
LogMessage(FILE,LINE,'Object','Method',"myincrement is: $IncrementBy");
Yes, I implemented all steps exactly as shown by you.
if you change classhooks.... around line 527
to this
LogMessage(__FILE__,__LINE__,'Object','Method',"pre - discussion id is $DiscussionID");
if ($DiscussionID) {
$DiscussionModel->AddView($DiscussionID);
LogMessage(__FILE__,__LINE__,'Object','Method',"pre - discussion id is $DiscussionID");
}
}
/**
* Adds items to dashboard menu.
it should tell you if addview is bein called.
Did that and got that in DebugLog:
19 May 2014 - 10:52:49: [Garden] /usr/www/users/TESTACCOUNT/TESTINSTALLATION/applications/vanilla/settings/class.hooks.php, 526, Object.Method(), pre - discussion id is
So the first LogMessage entry (above the if ($DiscussionID) {) causes these DebugLog entries on every page hit. I refreshed the mainpage (/discussions), clicked on a specific discussion, then back to Discussions, the result is three simiar entries as shown above in DebugLog.
as far as other error messages maybe x00 or linc can chime in.
It's quite strange, those allow_url_fopen entries in DebugLog seem to show up randomly. First I thought it only happens when I enable or disable a module, but toggling the Vanilla Statistics didn't add anything else to DebugLog.
maybe tomorrow or a later time with more people adding info, we can resolve mystery.
I have now added your IncrementView plugin to my production forum and it's working properly again.
But your plugin is kind of a workaround for functionality supposed to work in the core, and I'm still interested in getting this problem solved. So I'm leaving my test installation with all your suggested test additions as is and wait for further instructions / information in this discussion.
@R_J said:
Just from looking at the error message that you've get: have you tried to enable allow_url_fopen in your php.ini?
Yes, I've tried that, but then I've read up on allow_url_fopen and disabled it again, because that's what's generally recommended due to security concerns.
The question is now if Vanilla really needs allow_url_fopen enabled and if there is any downside or impact in leaving it disabled.
As said, I've just moved my production forum (and the test installation) to a new server, which has allow_url_fopen disabled by default, I may have had it enabled on the old server, I don't remember.
@MasterOne said:
The question is now if Vanilla really needs allow_url_fopen
At least it is used several times in the core as well as in some plugins. You could replace it with a curl workaround like it is shown here http://snipplr.com/view/4084
But then you have to have curl enabled. I do not know if one of these options is better or if there even is another option.
At least it is used several times in the core as well as in some plugins.
Without knowing any better I have now switched allow_url_fopen back on again. I've just taken a look at the old servers's php config and it was also on there, which may have been a requirement when installing v2.1b1 more than a year ago, but according to the PHP documentation allow_url_fopen is supposed to be on by default anyway. Still not sure if this is now a security risk, and reading about it I'd rather turn it off again if it shouldn't really be required by Vanilla.
forgetting about allow_url_fopen - which you should open up a new discussion. if turning it on and off has no impact on the view count, and in that case would be un related to this dicussion and sidetracking the issue at hand.
why do some people's views increment and yours and chans don't and why don't you hit the addview routines.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
the one difference in my testing - I am on localhost and don't have an installationID or installation secret in my config and don't have vanilla statistics enabled.
don't know if installation id or secret in the config.php with vanilla statistics turned off has any thing to do with problems.
maybe you should remove the line you added temporarily
$Configuration['Cache']['Enabled'] = FALSE;
and enable the vanilla statistics,
and see if you get js errors or any more info in DebugLog
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
I've always used firebug or chrome and both have web developer tools and each is better than another for finding and doing things. I would recommend both, even if FF comes with console out of the box.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Well, just tried with Chromium. I switched from Discussions to a certain discussion and back, no error in the consule but the following warning:
event.returnValue is deprecated. Please use the standard event.preventDefault() instead. jquery.min.js:3
I honestly don't know if there is anything else to check with the console. If you want to take a look for yourself, my testinstallation can be found here and the DebugLog here. I've used the discussion with topic "test" for testing as it shows "1 view" and does not increment.
Because not everybody is effected by that problem, maybe it has something to do with either the MySQL server configuration, PHP config or Apache setup? Right now I can't really tell, because I moved the old v2.1b1 installation from my old server to the new one and immediately performed the update to v2.1_final. I could try another test installation with the old v2.1b1 setup without upgrading to v2.1_final to see if the problem is introduced just by the server move.
LogMessage(__FILE__,__LINE__,'Object','Method',"pre - discussion id is $DiscussionID");
if ($DiscussionID) {
$DiscussionModel->AddView($DiscussionID);
LogMessage(__FILE__,__LINE__,'Object','Method',"pre - discussion id is $DiscussionID");
}
}
/**
* Adds items to dashboard menu.
at the first message. but it has no discussion id. which one would assume it would when you click on an individual discussion. so it never hits the addview in classhooks.
I don't know if this is a red herring. but the question is - why is there no discussionid # when you click on an individual discussion (when it hits class hooks (and that would explain why you have no addview).
20 May 2014 - 06:08:37: [Garden] ..../applications/vanilla/settings/class.hooks.php, 526, Object.Method(), pre - discussion id is
20 May 2014 - 06:09:28: [Garden] ..../applications/vanilla/settings/class.hooks.php, 526, Object.Method(), pre - discussion id is
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
this
20 May 2014 - 07:21:38: [Garden] /usr/www/users/stilld/testo.stilldragon.org/applications/vanilla/settings/class.hooks.php, 495, Object.Method(), Resolved Args non jsondecode is {\"DiscussionID\":\"548\",\"DiscussionStub\":\"test\",\"Page\":\"\"}
so there is discussion id there.
no lets see if the json_decode works.
can you change in that routine to this now:
public function Gdn_Statistics_Tick_Handler($Sender, $Args) {
$Path = Gdn::Request()->Post('Path');
$Args = Gdn::Request()->Post('Args');
parse_str($Args, $Args);
$ResolvedPath = trim(Gdn::Request()->Post('ResolvedPath'), '/');
$ResolvedArgs = json_decode(Gdn::Request()->Post('ResolvedArgs'));
$DiscussionID = NULL;
$DiscussionModel = new DiscussionModel();
$Resolved = Gdn::Request()->Post('ResolvedArgs');
LogMessage(__FILE__,__LINE__,'Object','Method',"Resolved path is $ResolvedPath");
LogMessage(__FILE__,__LINE__,'Object','Method',"Resolved Args non jsondecode is $Resolved");
// Gdn::Controller()->SetData('Path', $Path);
// Gdn::Controller()->SetData('Args', $Args);
// Gdn::Controller()->SetData('ResolvedPath', $ResolvedPath);
// Gdn::Controller()->SetData('ResolvedArgs', $ResolvedArgs);
// Comment permalink
if ($ResolvedPath == 'vanilla/discussion/comment') {
$CommentID = GetValue('CommentID', $ResolvedArgs);
LogMessage(__FILE__,__LINE__,'Object','Method',"Comment id is $CommentID");
$CommentModel = new CommentModel();
$Comment = $CommentModel->GetID($CommentID);
$DiscussionID = GetValue('DiscussionID', $Comment);
}
// Discussion link
elseif ($ResolvedPath == 'vanilla/discussion/index') {
$DiscussionID = GetValue('DiscussionID', $ResolvedArgs, NULL);
LogMessage(__FILE__,__LINE__,'Object','Method',"DISCUSSION id is $DiscussionID");
}
// Embedded discussion
elseif ($ResolvedPath == 'vanilla/discussion/embed') {
$ForeignID = GetValue('vanilla_identifier', $Args);
if ($ForeignID) {
// This will be hit a lot so let's try caching it...
$Key = "DiscussionID.ForeignID.page.$ForeignID";
$DiscussionID = Gdn::Cache()->Get($Key);
if (!$DiscussionID) {
$Discussion = $DiscussionModel->GetForeignID($ForeignID, 'page');
$DiscussionID = GetValue('DiscussionID', $Discussion);
Gdn::Cache()->Store($Key, $DiscussionID, array(Gdn_Cache::FEATURE_EXPIRY, 1800));
}
}
}
LogMessage(__FILE__,__LINE__,'Object','Method',"pre - discussion id is $DiscussionID");
if ($DiscussionID) {
$DiscussionModel->AddView($DiscussionID);
LogMessage(__FILE__,__LINE__,'Object','Method',"post - discussion id is $DiscussionID");
}
}
EDITED
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Comments
so your config shows all plugins disabled except htmlawed.
is that how you were testing?
I'm kind of stumped.
you could try with vanilla statistics enabled.
the addview in discussions model is called from class.hooks via
Gdn_Statistics_Tick_Handler
I don't know what calls Gdn_Statistics_Tick_Handler
another addview is called in class statistics.php
which adds to cache and throws stuff in analytics table.
if you say you added things in discussion model as above then
if it hits discussion model addview - something should print.
LogMessage(FILE,LINE,'Object','Method',"myincrement is: $IncrementBy");
if you change classhooks.... around line 527
from this
to this
it should tell you if addview is bein called.
as far as other error messages maybe @x00 or @linc can chime in.
maybe tomorrow or a later time with more people adding info, we can resolve mystery.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Yes, I have first tried with the same settings/plugins which are implemented in my production forum, then I have disabled all plugins and switched to the default theme.
Just tried, made no difference. Nothing showing up in DebugLog.
Yes, I implemented all steps exactly as shown by you.
Did that and got that in DebugLog:
So the first LogMessage entry (above the
if ($DiscussionID) {
) causes these DebugLog entries on every page hit. I refreshed the mainpage (/discussions), clicked on a specific discussion, then back to Discussions, the result is three simiar entries as shown above in DebugLog.It's quite strange, those
allow_url_fopen
entries in DebugLog seem to show up randomly. First I thought it only happens when I enable or disable a module, but toggling the Vanilla Statistics didn't add anything else to DebugLog.I have now added your IncrementView plugin to my production forum and it's working properly again.
But your plugin is kind of a workaround for functionality supposed to work in the core, and I'm still interested in getting this problem solved. So I'm leaving my test installation with all your suggested test additions as is and wait for further instructions / information in this discussion.
Just from looking at the error message that you've get: have you tried to enable allow_url_fopen in your php.ini?
Yes, I've tried that, but then I've read up on
allow_url_fopen
and disabled it again, because that's what's generally recommended due to security concerns.The question is now if Vanilla really needs
allow_url_fopen
enabled and if there is any downside or impact in leaving it disabled.As said, I've just moved my production forum (and the test installation) to a new server, which has
allow_url_fopen
disabled by default, I may have had it enabled on the old server, I don't remember.Did it work?
At least it is used several times in the core as well as in some plugins. You could replace it with a curl workaround like it is shown here http://snipplr.com/view/4084
But then you have to have curl enabled. I do not know if one of these options is better or if there even is another option.
It didn't change anything.
Without knowing any better I have now switched
allow_url_fopen
back on again. I've just taken a look at the old servers's php config and it was also on there, which may have been a requirement when installing v2.1b1 more than a year ago, but according to the PHP documentationallow_url_fopen
is supposed to be on by default anyway. Still not sure if this is now a security risk, and reading about it I'd rather turn it off again if it shouldn't really be required by Vanilla.@MasterOne
do you have any js errors in your console.
forgetting about allow_url_fopen - which you should open up a new discussion. if turning it on and off has no impact on the view count, and in that case would be un related to this dicussion and sidetracking the issue at hand.
why do some people's views increment and yours and chans don't and why don't you hit the addview routines.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
the one difference in my testing - I am on localhost and don't have an installationID or installation secret in my config and don't have vanilla statistics enabled.
maybe you should remove the line you added temporarily
$Configuration['Cache']['Enabled'] = FALSE;
and enable the vanilla statistics,
and see if you get js errors or any more info in DebugLog
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@peregrine, how can I check on js errors? Never had anything to do with such so far. I'm using the latest Firefox (no Firebug installed right now).
I think the latest build of FF has a JS console ? RightClick-> Inspect Element should bring it out. I dont have it right now , but you can try it.
I've always used firebug or chrome and both have web developer tools and each is better than another for finding and doing things. I would recommend both, even if FF comes with console out of the box.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Well, just tried with Chromium. I switched from Discussions to a certain discussion and back, no error in the consule but the following warning:
event.returnValue is deprecated. Please use the standard event.preventDefault() instead. jquery.min.js:3
I honestly don't know if there is anything else to check with the console. If you want to take a look for yourself, my testinstallation can be found here and the DebugLog here. I've used the discussion with topic "test" for testing as it shows "1 view" and does not increment.
Because not everybody is effected by that problem, maybe it has something to do with either the MySQL server configuration, PHP config or Apache setup? Right now I can't really tell, because I moved the old v2.1b1 installation from my old server to the new one and immediately performed the update to v2.1_final. I could try another test installation with the old v2.1b1 setup without upgrading to v2.1_final to see if the problem is introduced just by the server move.
notice how there is no discussion id. when you click on an individual discussion in the debuglog.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
so it hits classhooks
at the first message. but it has no discussion id. which one would assume it would when you click on an individual discussion. so it never hits the addview in classhooks.
I don't know if this is a red herring. but the question is - why is there no discussionid # when you click on an individual discussion (when it hits class hooks (and that would explain why you have no addview).
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
whereas I get a proper discussion ID when i click on a discussion.
20 May 2014 - 06:28:34: [Garden] /var/www/vanilla/applications/vanilla/settings/class.hooks.php, 526, Object.Method(), pre - discussion id is 31
20 May 2014 - 06:28:34: [Garden] /var/www/vanilla/applications/vanilla/models/class.discussionmodel.php, 1911, Object.Method(), myincrement is: 1
20 May 2014 - 06:28:34: [Garden] /var/www/vanilla/applications/vanilla/settings/class.hooks.php, 529, Object.Method(), post - discussion id is 31
pre - is the first logmessage in classhooks
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@MasterOne - we may be near the homestretch.
can you replace this entire Gdn_Statistics_Tick_Handler in /applications/vanilla/settings/classhooks.php
EDITED
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Done.
thx.
I made a few more changes - if you want to replace it with the above code which I just edited.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Done.
ok the nondecodej joson has
this
20 May 2014 - 07:21:38: [Garden] /usr/www/users/stilld/testo.stilldragon.org/applications/vanilla/settings/class.hooks.php, 495, Object.Method(), Resolved Args non jsondecode is {\"DiscussionID\":\"548\",\"DiscussionStub\":\"test\",\"Page\":\"\"}
so there is discussion id there.
no lets see if the json_decode works.
can you change in that routine to this now:
EDITED
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.