UBB.Developers Forums UBB.threads 6 V6 Modifications Archived Mods Calendar v 3.0

LoL I don't know...


When I was stationed in Germany I never noticed... (was there for 2 years) LoL



In the US Sunday is the first day of the week, not Monday.

yes, and hours count 0:00-23:59 instead of 0.00 AM - 23.59 PM, thats all the difference I think.

Greetings Carl

Thanks

I hadn't thought about allowing for the 24 hour format (military time) but I'll get it in.

Switching from European to Western calendar weeks is configurable. I wan't to place an extra setting in users prefs so they can chose what type they see but if they haven't chosen a calendar week type it falls back on what ever the default is set to.

Sounds pretty cool! I am very curious now.

In case you need help with German language files, let me know.

IIP 6.0's text has been completely moved to seperate language files and is stored in the same manor as .threads' is.

This last version was just something I threw together from the pieces parts I had laying around. LoL I just wanted to give everyone something to kill time with.

posted by caymuc:

---

yes, and hours count 0:00-23:59 instead of 0.00 AM - 23.59 PM, thats all the difference I think.

---

No - we prefer to use 0:00am to 11:59pm - oh and don't forget to allow for the fact that we drive on the left, still use our own currency and rule the world Okay the last one might not be true these days

Ohh I figured that out... The problem or thing that needs adding is... When you "Create" a forum. You should add a Radio Button on "Is this forum a Calendar?" If yes it does the Y and no it does the N... Just my 2 cents...

Also a bug... I put in an event. Then I went to delete it and it gave me some weird error (cant remember it) and the stats for the forum still show the message being there but it isn't... Any suggestions...

It does not remove the event name and date from the w3t_events table, you need to manually remove it. phpmyadmin works great for this.

Well shouldn't we make it so it does??

Yeah, that would be a good idea. Also having it show the event date and title in the post body would be good so ya know when the event is from the post info.

Yeah that would be nice also Especially for the Calendar's that are Moderated...

when I run-

CREATE TABLE w3t_Events (
E_ID int(9) DEFAULT '0' NOT NULL auto_increment,
E_CalendarID int(9) unsigned DEFAULT '0' NOT NULL,
E_Number int(9) DEFAULT '0' NOT NULL,
E_Date int(11) unsigned DEFAULT '0' NOT NULL,
E_Time int(11),
E_Duration int(11) DEFAULT '0' NOT NULL,
E_Recurring char(1) DEFAULT 'N' NOT NULL,
E_Recurtype varchar(10),
E_End int(11),
E_Frequency int(11),
E_Days varchar(7),
E_Location text,
PRIMARY KEY (E_ID),
KEY E_CalendarID (E_CalendarID)
);



I get-

Results from your SQL command

Here are the results of your command: "CREATE TABLE w3t_Events ( E_ID int(9) DEFAULT '0' NOT NULL auto_increment, E_CalendarID int(9) unsigned DEFAULT '0' NOT NULL, E_Number int(9) DEFAULT '0' NOT NULL, E_Date int(11) unsigned DEFAULT '0' NOT NULL, E_Time int(11), E_Duration int(11) DEFAULT '0' NOT NULL, E_Recurring char(1) DEFAULT 'N' NOT NULL, E_Recurtype varchar(10), E_End int(11), E_Frequency int(11), E_Days varchar(7), E_Location text, PRIMARY KEY (E_ID), KEY E_CalendarID (E_CalendarID) ); ".
SQL ERROR: Unable to do_query: CREATE TABLE w3t_Events ( E_ID int(9) DEFAULT '0' NOT NULL auto_increment, E_CalendarID int(9) unsigned DEFAULT '0' NOT NULL, E_Number int(9) DEFAULT '0' NOT NULL, E_Date int(11) unsigned DEFAULT '0' NOT NULL, E_Time int(11), E_Duration int(11) DEFAULT '0' NOT NULL, E_Recurring char(1) DEFAULT 'N' NOT NULL, E_Recurtype varchar(10), E_End int(11), E_Frequency int(11), E_Days varchar(7), E_Location text, PRIMARY KEY (E_ID), KEY E_CalendarID (E_CalendarID) );
You have an error in your SQL syntax near '; ' at line 16 row(s) affected by your query.

Hmm, I didn't change that create table command when I updated the directions to 6.1, so they should still work. It looks like you have a space after the ; from your quote of '; ' so perhaps it got added on from a copy and paste?

anyone know if this hack works with 6.1.1?

Thanks!

It works just fine with 6.1.1 Pappy. I am glad that I installed it.

One question though from me: Until we wait for Rick to do some magic with the birthdays etc., I noticed that on the events table there are some fields like E_Duration, E_Recurring, E_Recurtype, E_End and E_Frequency

Can we set those fields and if yes to what, so that if I enter someone's birthday (say 12/12/1980) it will appear every year on the 12/12th?

That will save loads of input for the admins.

Thanks in advance

Warm regards

Nikos

The events table is part of the calendar 3.0 addon, and I think those fields were never implemented by Max.

Birthdays should go in the user table along with the other user information.

does this version of calendar work with 6.1 ?

Charles,

Dimipoulous indicated (in a few posts above yours) that it seemed to work in 6.1.1 so I presume it would work in 6.1 - YMMV, since I haven't had the opportunity to try it myself.

Cheers,

Rob

Yes it works in 6.1, I posted updated instructions above somewheres...

An optional note:

When you specify a board to be a calendar, it shows at the top of the screen and below it you can see the list of all the entries you made - as events.

If you do not wish this to be shown - only the calendar to be visible you need to do the following:

Open postlist.php
Go to the end of the file and find:

code:

        if (!$debug) {
           include ("$thispath/templates/$tempstyle/postlist.tmpl");
        }

---

and change it to

code:

if($Calendar != "Y")
{
        if (!$debug) {
           include ("$thispath/templates/$tempstyle/postlist.tmpl");
        }
}

---

Warm regards

Nikos

Make Note... You forgot the making of the templates

Here are 2 suggestions for the calendar incase you guys haven't thought of it. If you have please ignore it:

1. Edit Event so that we can change the information about the event.
2. Put the Event information into the original subject line of the original post.

Another one....

Add a date that it goes under for the actual thread listings. If you put new posts at the top and someone inputs something for a date a few months ahead, there is no decent way to figure it out.

2 more suggestions.
1. Add an option for All Day Events.
2. Set it so that if you change the time offset in the display settings it also changes on the calendar as well.

Here is a proposed change for the calendar to fix timeoffset issues.

In postlist.php:
Look for
$h = strtolower(strftime ("%I", $tm));

Add Above it:
$tm = strtotime($html -> convert_time($tm, $user['U_TimeOffset']));

There should only be 2 entries.

------------------------
In AddEvent.php

Look For
$user = $userob -> authenticate("U_Username, U_Password,U_Signature,U_Picture,U_Groups,U_Display,U_Language,U_Totalposts,U_Title,U_Color,U_TempRead,U_TextCols,U_TextRows,U_EReplies,U_Preview,U_Number");

Change it to
$user = $userob -> authenticate("U_Username, U_Password,U_Signature,U_Picture,U_Groups,U_Display,U_Language,U_Totalposts,U_Title,U_Color,U_TempRead,U_TextCols,U_TextRows,U_EReplies,U_Preview,U_Number, U_TimeOffset");

Look for:
$ETime = mktime ($hour_convert, $min, 0, 0, 0, $year);

Change it to:
$ETime = mktime ($hour_convert - $user['U_TimeOffset'], $min, 0, 0, 0, $year);

And that's it. Then Timeoffset will work properly.

Is this mod compatible with 6.2?

I don't believe it will be. Since this works off of the information stored in the w3t_Posts table which has been changed for 6.2 it will probably break this mod. I haven't seen the code for 3.0 and can't remember if Max went with a table join between the events table and the posts table to grab the information. If so this will also be a problem since .threads 6.2 uses a table join between the Users table and the Posts table and adding an additional table will most likely impact speed. (without a lot of work in streamlining things)

About adding an extra table join to the Users table:

This only seems to apply to postlist.php (and I'm not even sure if the username is needed there). So wouldn't the additional overhead only occur when viewing the calendar? Is so, I wouldn't think that would be a big deal.

I've modified the version of this hack in this post to work with 6.2dev4.

I can upload it after 6.2 public beta is available, if there's interest. I'm not sure who's currently maintaining this hack, and I'm not really interested in maintaining it.

Questions:

1) What version # should this be called?

2) I know that Max Fisch and Allen Ayers have worked on the hack. Is there anyone else, so that I can list the authors?

I haven't looked at 3.0's code so I couldn't say for sure but I know you know your stuff Dave so I'm sure it's all good.

Yeah the extra overhead should only occur during calendar viewing. The last time I seen it running here I recall a good 30-40 queries being needed when there was a few events listed. Is there a way to cut them down? Just a thought.

GameJag ? I believe started things rolling. Max picked it up from him and moved it forward. Then Allen got the templates/xhtml into working order and some fixes too, I believe. I would say those are the 3 main authors prior to your update. Anyone else have some input on this?

30-40 queries

This is probably what you were seeing:

code:
// loop through all the days of the month
while ( $d <= $lastday) {
   ...
   select E_ID,E_Date,E_Time,E_Location,B_Subject, B_Number, B_Replies
      FROM w3t_Events, w3t_Posts
      WHERE E_Date >= '$lowdate'
      AND   E_Date < '$highdate'
      AND   B_Number = E_Number
      AND   B_Board  = '$Board_q'
   ...
}

---

(This query originally was also selecting U_Username, but the username wasn't used anywhere, so I simply took it out, and there was no need to add a join to the users table.)

Maybe that's what dimopoulos was talking about in his Fetching data in an array post.

I suppose the query could be done before the loop, extracting the data for the whole month, and storing it in an associative array. Do you think it would make sense to do that?

Yeah I think it would be much better done that way. I'm not much for calendars but those that use them alot will have a lot less load on their servers.

I am really not too sure about the Load issues but I used a version 3.1 and redid some of the tags so that it would display properly on all the stylesheets. (IE month and other text areas that used the default black text. Also I added some stuff to change the border color on the current day for stylesheets that had light table and dark table using the same or similar backgroud colors. My server is at www.greatlakesalliance.com and our Calendars are used fairly often and have events for most days. I am really a newbie when it comes to actually writing any code that works. Lots of trial and error here and I am not sure if any of the stuff I have done is "optimized" I would be very interested in any new stuff done with this. Also Dave, I really apreciate all the effort you and the other Users here have done over the past couple years here and at wwwthreads when it was still live.

Justdave, you used to have a Calendar pal in one of the older IIP versions (3.x I believe?) is there any way I can get a copy of that one from you so I can modify it to work with the current version of threads/IIP?

Thanks a million everyone!!

Pappy

The calendar pal is laying around here somewhere. I'll dig it out this coming week and put in to the next minor upate for IIP. I have IIP working with the upcoming release of .threads and will post the updated IIP when .threads 6.2 is pubicly available.

As far a server load with the calendar addon I don't think smaller sites will have much of an issue with it. I was considering the "what if" when a site has 10 or 20 users browsing the calendar and possibly creating 300 - 800 queries in that area alone.

I think Dave_L will have this problem resolved though.

Ok, I've moved the query out of the loop. The events are now stored in an array. Here's the header comment for the function that stores the data:

// Get all the events for the specified month.
//
// The events are extracted from the database Events table, and stored in the
// array $events_for_month, which is indexed by the day of the month.
//
// Events are stored in ascending order of date (E_Date).
//
// Examples:
// $events_for_month[5] is an array containing the events for the fifth day of the month.
// $events_for_month[5][2] is an array containing the third event for the fifth day of the month.
// $events_for_month[5][2]['E_Location'] is a scalar containing the E_Location column for the third event
// for the fifth day of the month.

function get_events_for_month($month, $year) {

Does this look reasonable? It seems to work correctly.

I don't see any problems with that at all. I bet that dropped the query count considerably too.

I didn't notice the query count before, but it's about 11 now. The number of queries has been reduced by one less than the number of days in the month.

I was wondering if that three-dimensional array might take up a lot of memory, if there were a large number of events for the month.

As far as using the array for storage untill it's sent to the browser I don't think it will be a problem since .threads does the same thing for it's displays before being sent to the templates.

Thanks Dave,

That was exactly what I wanted to do = reduce the number of queries.

Warm regards

Nikos