Yesterday i've installed "Heartbeat 6.x-4.x-dev"

Today I've a couple of problems:

1) Updates are not showing immediately. I dont know is it related with cron but, sometimes i have to wait 2 hours to see an update published on the stream.

2) Public Stream not showing all updates . I am using "comment published" and "node added" rules. Since I've activated HB, users added more than 10 comments, but now I can only see 3 of them.

3) When I try to use HB with Views, i get this error:

"Fatal error: Call to undefined method heartbeatParser::set_info() in xxx/modules/heartbeat/views/heartbeat_views.module on line 121"

Now lookin for your help :)

Comments

Stalski’s picture

hey ben,

I will try it out on a new site again. One thing that has been changed is the fact that not so many heartbeat rules are active on install.
I know also that there is a bug after install ... users have to surf to the page where activity streams are saved!! so save your streams and also surf to the page where heartbeat template messages are synchronized. This page will import new messages and delete old ones.
The cron has nothing to do with it i think, but i will check it.
The reason why not all your comments activity are shown could be a message configuration (single or summary?) or could be an error in the api where messages are grouped where they should not be grouped. I am completely in the dark for this one, and i hope i can reproduce it.

Also i recommend not to use views since views is not very appropriate to build streams. The streams come with blocks and pages that can do much much more that the views displays. (most of the times views is powerfull but not in the terms of heartbeat activity)
Of course it would be helpfull if you said which important modules you have installed.

Stalski’s picture

That the api works i am sure of, because the test site runs always on the latest version. That's the reason why i will test on a new site for you of course. I did it last week on a production site and it worked for me. I did see what i said before: I had to save the publicheartbeat before i used it.

benway’s picture

Hey, thank you for the quick response.

>>I set Maximum gap (in seconds): "7200" to "0" and problems (1 and 2) are solved.

About Wiews... I get that error on wiews' default public heartbeat page, not when i try to create a new wiew. i didnt tried to create a new one thought. I don't know what happens if I did :)

Blocks are just fine and enough. But I just wanted to let you know about that error.

Thanks again...

thekayra’s picture

Same problmes as benway. 1, 2 and 3.

>>I set Maximum gap (in seconds): "7200" to "0" and problems (1 and 2) are solved. is IMHO quick but a little dirty solution. The messages will no longer be grouped togehter. It would be nice to have the option to group the messanges AND make it work.

I tried upgrading from "6.x-4.x-dev (2009-Oct-10)" to "6.x-4.2 (2009-Oct-24)" and had too many problems on my test site. I can not risk this upgrade in live at the moment.

I am using a lot of views and problem number 3 is gets i the way all the time.

Stalski’s picture

I am testing the installation today.
I know for sure that the install hooks are not called properly. What i am figuring out, is if it happens when copying the new version over the old and reinstalling it.
Appears a lot of things remain in the database and i will figure this out.

About views: i will fix this too. I have changed the heartbeatmessagebuilder and parser, but did not enforce this too the views submodule since it is not active on my testsite. I will make a page with a view as well on heartbeat.menhir.be

Thx for all reports
Stalski

jide’s picture

Stalski,

Thanks for taking care about this.

But honestly, releasing so much broken versions seems a little irresponsible to me, IMHO. I encountered many problems recently with Heartbeat and lost hours redoing things.

Lastly, I just disabled a (totally unrelated) module, and encountered bug #604878: Heartbeat throws "Cannot redeclare class rules_data_type_heartbeat_message" error after installing another module.
So I had no other choice but to update the module to 4.2 version.
Then I had bug #354306: Fatal error: Call to undefined function dsm()....
So I had to comment dsm() functions (okay, that one was not too bad).
But I lost my views #617066: 3 Problems, so I had to redo the views using hook_heartbeat_register_access_types()...
And it seems that I lost some random entries now and I don't know why...

I know you're putting a lot of effort into this module - which is really great, but maybe you should slow down releases a bit and put them in dev version for some time before actually make a release. I myself did the same error so I don't blame you, it is just an advice ;)

Keep up the good work.

Edit : This thread is about dev version but I encountered problem #3 in 4.2 release.

Stalski’s picture

you are completely right. Everytime i have a stable version, i forget something that messes the whole process up.
The other thing is true as well. I put too much and too much functionality in it that i cannot keep up with versioning on drupal.org. We need heartbeat a lot at work and my main efforts go that way.

I will do my best to freeze code now and put some backward compatibility in it. Every release is so different from the previous ones that i don't take enough effort for the people using it. It is rather difficult because the changes are improvements imho.

I will do my best to avoid this in the future and release a new version shortly to fix things.

About using views: i can not see any advantage in using views and i would like too remove that. The problem is dat most people prefer that, because they are familiar with it i guess. So this stays a big dilemma for me. I cannot see another option that to update it to work again and i promise i will just do that.
On the other hand, i would like to get your opinions on this matter? Are their many people that have trouble with the default heartbeat blocks and pages, please tell me and/or ask me so i can act to it.

jide’s picture

Stalski,

I totally understand since I made the same mistake for some modules too. Some forgotten debug functions here and there... It's hard not to rush sometime ;)

If a release is too much different from a previous one and may break things, you may warn users about that in a release note. BTW, a README.txt would be very welcome.

About views integration, for example, I wanted to have a block that displays heartbeat activity for a given user, and there is no block for this by default. So I created a view, used the currently viewed user as an argument and displayed its activity.

I think Views flexibility is great for cases like this, we can add filters, arguments, templating and all these neat things Views allows us to do ;)
Moreover, using hook_heartbeat_register_access_types() may not be easy for people who do not want to get their hands dirty with code.

But to me the most valuable thing about Views integration would be its flexibility, it is a good query builder so why reinvent the wheel ? I may be missing something here, but to display results of a query it seems very effective to me.

Stalski’s picture

There is a option on the block pages to use the block on the user profile pages (when enabled visibility) .With this block configuration ON, and the ajax way of toggling older messages , you see the activity off the displayed user on the user/uid page.
I am currently working (thinking) on how to offer this as full page as well. The difficult part here is that i dont know what is best to use as url.
/user/uid/heartbeatStreamType would work i guess ...

The query is the most easy part of heartbeat displays, so using views does not do that much. The magic is afterwards, in the views alter hooks ... and i dont want duplicate code so the objects have to work with views and custom.
So really it does not offer anything more since i am totally rewriting queries and the performance is much worse with views as well. I am going a bit too technical but from dev too dev, i like to throw it in ;)

Stalski’s picture

But that does not mean i wont do what i promise ofcourse. I would very much bring activity streams with views to a higher level. We will hold a brainstorm at work about that in a month or so.

jide’s picture

For the user block, I thought I could only display private stream of a user to himself, not a public stream of the user to everyone ?

Concerning Views, no doubt perfs will be worse than a custom home made query, but I think this may be a choice of the user. Moreover, with Views cache we can lower the performance impact.

But personally, I would prefer a robust module without Views support than the opposite ;)

BTW, I think Issues are the right place to discuss technical things, don't worry.

thekayra’s picture

Hi Stalski and jide,

I really like heartbeat, there is no question about it.

Just to add my 2 cents, I am using views to show what the friends of the user are doing, as I mentioned in Activities of friends. So it would be nice to have views support =).

By the way, I will submit a patch for people who might be interested in something like that, once we have a really stable release.

Stalski’s picture

Reminder to myself:
- Make pages for a viewed user per stream type (especially related activity)
- Make views related activity example at heartbeat.menhireffect.be to show it can work (without grouping in phase one)
- Make views private / personal example at the demo site mentioned above

Stalski’s picture

Assigned: Unassigned » Stalski
Status: Active » Closed (fixed)

I will close this issue because this is one that's very difficult to follow up. The original issue is fixed and some TODO's came from it.
- Make views related activity example at heartbeat.menhireffect.be to show it can work (without grouping in phase one) = DONE

the other two are in the TODO list, so available soon.