Welcome to Geeklog, Anonymous Sunday, September 01 2024 @ 01:45 am EDT
Geeklog Forums
Calendar Plugin Upgrade?
Page navigation
Tex
![angelic angelic](https://www.geeklog.net/forum/image_set/moods/angelic.gif)
http://www.sweetphp.com/projects/TotalCalendar_2/index.php?selectedDate=1175410800
suprsidr
![Smile Smile](https://www.geeklog.net/forum/image_set/pixel.gif)
-s
FlashYourWeb and Your Gallery with the E2 XML Media Player for Gallery2 - http://www.flashyourweb.com
LWC
Tex
![determined determined](https://www.geeklog.net/forum/image_set/moods/determined.gif)
TotalCalendar for Geeklog doesn't look well-integrated. It doesn't seem you can put calendar blocks (upcoming events, etc., etc.) wherever you want them, etc., etc., The Geeklog calendar is really good. It just needs some TLC.
I wanted to pay for this, and maybe get others to help pay something, so that it could be given free to the community. If I could figure out about how much it would cost, I could come up with a plan to make this happen.
LWC
samstone
"Actually I helped Matt make TotalCalendar work with Geeklog "
TotalCalendar for Geeklog doesn't look well-integrated. It doesn't seem you can put calendar blocks (upcoming events, etc., etc.) wherever you want them, etc., etc., The Geeklog calendar is really good. It just needs some TLC.
I wanted to pay for this, and maybe get others to help pay something, so that it could be given free to the community. If I could figure out about how much it would cost, I could come up with a plan to make this happen.
This features has been requested hundreds of times in the past four and a half years. Someone (I think it was Vince) tried it and gave up. It is obviously a very complex and time consuming task that no one feels worthwhile to invest the time and effort on.
TotalCalendar does allow you to put the calendar block on GL. The author will send you the codes for the lib-custom.php.
My problem with the TotalCalendar is the poor support. My last support request is two months old and I couldn't get any reply. I own 4 licenses! The author would disappear for weeks at a time and come back to make quick answers. But my current problem doesn't have a quick answer, so he just doesn't respond, after telling me that he would get back at me quickly.
The support I requested is that the calendar and events block is in conflict with Geeklog's portal blocks because both use PEAR and you get something like "cannot redeclare PEAR modules..." error. If you have both the TotalCalendar's event block and some RSS feed blocks on your Geeklog site, you will run into that error when RSS refreshes. He asked me to comment out almost everything in Geeklog's PEAR.php. It works for a while and then other problems arise because of that hack.
Now I have waited two months for a better solution that he said he would give me sooner. Other than that TotalCalendar is very powerful especially if you use if for many groups. The only thing that lacks with the integration is searchability.
He uses the name sweetphp, and no where you can find his real name, or where he lives. Not that I care to know who he is, but he just doesn't have a name of face for his customers to feel comfortable with. His website is poorly maintained.
The program heavily uses xml to the extend that I found no way to modify it if I need to modify it for certain need.
I was about to promote TotalCalendar to the Geeklog community, but so far I am not yet happy with it.
Good luck with your attempt to get GL Calendar improved. Count me in for contribution.
Sam
jmucchiello
* Recurring events.
* Email reminders for events.
* Subscribe to events.
The first one is just annoying to write. I've looked at it and it probably needs a different method of storing the event day/time so you can easily find "future" events without littering the event table with duplicated entries.
The other two suffer from GL's lack of easy to make ad hoc groups. If that was easy to do, they become easy to write. I've also looked at doing that but it isn't easy without making the group admin screen a pain to use.
I would do recurring events by splitting the main event table into two tables. The first would be as it is now, the second would be strictly a list of timestamps and event instances (probably called "occurrences" ) . Most events would have one instance per event but recurring events would fill the instance table (for up to a year or two from initial creation) with future events. This table would make it fast to lookup reminders. (Reminders go on both tables so you can change the reminder for a specific instance if needed, such as over a 3 day holiday.)
As for the groups, I would add two fields: subscribe id and subscribe type. ID would be the eid and type would be 'calendar'. Whenever these fields are filled in the group would not display in the normal group displays. Subscribers are added to the group as they subscribe. Email notifications go out to all subscribers as needed.
Why clutter the group table? So that other forms of subscription (subscribe to story, subscribe to poll, etc) would be located in a central place. And, such a group could be promoted to a real group rather easily if it goes through the existing group code. (Not to mention not having to duplicate the group code.)
Laugh
Wouldn't using just one table be the best way to handle recurring events. You could add one or two columns to add in the recurring type (ie monthly, weekly, daily, every Friday, etc..). I realzie this may not be the best way in terms of using the existing calender code but from the stand point of db design it would be.
One of the Geeklog Core Developers.
jmucchiello
For example, suppose you have 3 events: one is a one-shot event Monday, April 16; one recurs weekly on Mondays and one is the third Monday of each month. If you want to populate the day planner for April 16, you find 3 records in the table and you list those three events. Without that table, you have to read every recurring event record and determine if any of its events fall on that day.
Now imagine there are hundreds of events. Do you want to process every event every time someone decides to look at December 2007 to see if anything is scheduled? No, you populate the second table with all the recurrences so you can look them up quickly. About the only reason to shoehorn it into the same table is if think recurrences will not share most of the same information about the event (location, addresses, state?, organizer, type, etc). If that was needed, you could have a flag that says, "recurring events are independent of original event" and then the code would just insert a bunch of unique events. (The fields for recurrences should have an end-date for when occurrences cease for that purpose.)
Likewise, the reminder code would use the reminder datetime field to determine what subscriptions needs to be mailed. For example, event 1 might have a "Remind 24 hours before event" reminder. Event 2 might have a "remind 1 week and 3 days before event" reminder. and Event 3 might have no reminder. On April 9, the reminder_date for event 2 would become less than now() and you would send out the reminder. You would recalculated reminder_datetime to be 3 days before the event and then exit. On April 13, the 3 days reminder would kick in and the reminder is sent again, the recalculated reminder_datetime is now NULL so no more reminders are sent for event 2. Event 1's reminder goes out on April 15. Etc.
Tex
Here is what I'd like for us to consider:
We need someone to set up the "proposal." Don't know what this entails, but if we have someone here who has experience, we sure could use that person. We can all chip in ideas about how long a certain feature might take to code, and how much $$$ we are each willing to chip in for it. If it is involved, then that person could do the proposal in lieu of donating bucks.
If we can get a fix on the $$$$, then I can take over the fund raising part. Basically, what I will do is divide the total estimated $$$ into enough people so that each person has to contribute only about $5 or $10 max. Then I will try to drum up the support, based on the many requests over the years for this enhanced calendar. After I get enough people pledging, I will put pressure on those folks until they pay up. Depending on the needed $$$, I may even pay the remainder if I could get the group even half-way there. I like the Geeklog calendar. But I am pretty sick of it not being a real calendar.
Laugh
You make a good point about having an alternate location for an event. You could even include a status field or description in this. As example, I'm thinking of of a night class schedule (recurring event) and the possibility of a single class being canceled. You still want to display the event but also say it is canceled and the new event is at this time. I wonder here if you would want a grouping of events as well. Taking the above example you could create a group called "English Night Classes 2007". In this group you could include your recurring event plus any other events like rescheduled classes, field trips, etc.. that don't fit the recurring event pattern. This would help the administrator keep the schedule organized plus it would also help students looking for just a particular class.
One of the Geeklog Core Developers.
Tex
Basically, I am looking for the following features to be added:
* Recurring events. (The Total Calendar way is fine by me, unless someone has a better idea)
* Email reminders for events.
* Subscribe to events.
* Group Assignments of Events
If we could form a group, the group could submit a bounty for each request.We need is a simple, trusted way to make it happen. Any suggestions?
Also, what's involved with a proposal? Is it just a matter of telling the feature and how much money you're willing to pay? If so, then let's take the first feature and ask who's in and for how much?
jmucchiello
I think I see the problem here. Basically, the Bounty system is setup so that a single person has to contribute the $$$ for a project.
Until someone puts up, it won't get onto the bounty page.
Tex
What would keep a person from NOT using Bounties to get a geeklog feature?
1. He has no idea how much a feature might cost. Most of us aren't developers. So, we don't have any idea how much it is worth from a developer's point-of-view. We know what it is worth to us. So, if we "donate" $50 for what all developers think is worth at least $200, we still must wait until someone else comes along to donate more. Even if we group ouselves and donate, we are in the same situation. It is too hit-or-miss, I think, to give people hope of getting the work done.
One solution for this might be to do what you have done. When you said the bounty for the calendar stuff should be at least $200, you set a range that let the rest of us know what is reasonable. Maybe someone could do this for requests - set minimum suggested bounties. Or, maybe bounty hunters might just put their personal minimums so that we get an idea of what the job is generally worth to the hunters.
2. You still feel pretty isolated with the bounty system. If I have only $50 I am perfectly willing to give provided I can get others to give with me, the current system doesn't allow me to sense I am part of a group that is about to really get a job done. That is probably why casper and sandstone are sitting in the wings, with money in hand, ready to give, but not actually doing it. They likely don't feel enough certainty that their money is going to be put to the use they intend it to be.
A solution for this might be to have some way for official bounty groups to form in view of specific features. Each user will pledge a certain amount to the group for the feature(s). The pledges are published, then a bounty hunter says that if the pledges materialize into a bounty, he would take the bounty. Then the members of the group donate the bounty by a certain date, understanding that its donation will not be refunded.
If we could get the two things above somehow implemented, I wonder if bounties would be used more frequently.
Just trying to help
Tex
jmucchiello
Ah. Think I see it now. If my understanding is correct, a bounty is a way to donate to Geeklog's development for a specific feature. It will not be refunded even if no one takes the bounty.
The catch-22 is that the more requirements you put into the task the more expensive it becomes. OTOH, the more tasks there are the easier it is to get someone to commit to "learning" the subsystem to the degree needed to accomplish all the tasks in a decent manner.
First, you have to bounty the ad hoc user groups task.
![Smile Smile](https://www.geeklog.net/forum/image_set/pixel.gif)
Tex
Add your name and the amount you will contribute to the project below mine. If we can get to $600 in good time, then I'll procede to the next step.
I will contribute:
Tex - $100 (subTotal = $100)
Page navigation
- Normal Topic
- Sticky Topic
- Locked Topic
- New Post
- Sticky Topic W/ New Post
- Locked Topic W/ New Post
- View Anonymous Posts
- Able to post
- Filtered HTML Allowed
- Censored Content