Event Calendar v3

[DivaVocals]

That program is for creating the side box and those month names are for the drop down...I tried it with the long and it fits for my scenario. But you could write it like this (keep in mind $monthShort is just an array, once you set it to the exploded define there's no need to follow it, its just a name, meaning there is no need to change that 3rd line.)....this is and example if you called the define variable EVENTS_LONG_MONTH_SELECT ("true" meaning use long month names):
in tpl_events_calendar_include_default.php

               $monthShort = explode(",", (EVENTS_LONG_MONTH_SELECT ? MONTHS_LONG_ARRAY : MONTHS_SHORT_ARRAY));

in the defines

// Month defines in sidebox month drop-down
define('MONTHS_SHORT_ARRAY', 'JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC');
define('MONTHS_LONG_ARRAY', 'January,February,March,April,May,June,July,August,September,October,November,December');
define('EVENTS_LONG_MONTH_SELECT',true);

Maybe we should stick EVENTS_ in front of those define names...I searched and tpl_events_calendar_include_default.php is the only program to use it.

Another thing to consider would be to use the month names already defined with the base package of zen carts, that way it only has to be changed once...plus if someone already has another language in place and drops this module in then they are good as far as months. I'm not a language expert, but does every language use the 1st 3 letters for the short version of month names? If so we could create the short month just by cutting the rest.

Last thing: If they want the option of long/short names for the drop down, do you think they want them for the side calendar and the yearly views too? If you make the following change to tpl_events_calendar_include_default.php and tpl_events_calendar_default.php it will change all of them...
Just add the line below after "$cal = new Calendar;" in both files:

$cal = new Calendar;
$cal->setMonthNames(explode(",", (EVENTS_LONG_MONTH_SELECT ? MONTHS_LONG_ARRAY : MONTHS_SHORT_ARRAY)));  //**rus: via diva: add

Maybe there should be a separate define (EVENTS_LONG_MONTH_TITLES) for that, up to you guys.

Thanks,
Rus

Just thinking we(maybe mostly me) are making this more complicated then it needs to be. Why not just have 2 fields:

define('EVENTS_MONTHS_DROP_DOWNS', 'JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC');
define('EVENTS_MONTHS_TITLES', 'January,February,March,April,May,June,July,August,September,October,November,December');

Then in tpl_events_calendar_default.php after "$cal = new Calendar;":

$cal = new Calendar;
$cal->setMonthNames(explode(",", EVENTS_MONTHS_TITLES));  //**rus: via diva: add

Then in tpl_events_calendar_default.php
after "$cal = new Calendar;":

$cal = new Calendar;
$cal->setMonthNames(explode(",", EVENTS_MONTHS_TITLES));  //**rus: via diva: add

and for the drop downs:

                $monthShort = explode(",",EVENTS_MONTHS_DROP_DOWNS);
                $month = date('m');
                while (list($key, $value) = each($monthShort))

Simple, now anyone can come in, see what they are, and change to whatever, numbers, short, long, etc.

Rus

thanks for setting me straight on the correct code. as you know I am a software BA, not a developer.. (I just play with them at work..) Okay so the first post I totally understood.. but the second one ya lost me.. kinda.. I'm trying to figure out how that second one ties into an admin setting for selecting long versus short months.. and I am HELLA confused.. To quote Denzel from the movie "Philadelphia",

"Can ya explain it to me like I'm a 3 year old"

[LaCamus]

Notta problem....
Actually if you want to make it admin menu configurable then we need to do it the first way. I was thinking that this would most likely be set once at setup, and didn't need to be in the admin menu configs. But it doesn't matter either way to me. It could be argued both ways. The second way lets them choose one define for titles at the top of calendars, the other for the drop down (which is currently the short names). If you want both long then just type the full month names in both defines. When dw08 mentioned possibly using #'s for the short version I figured just have the 2 defines and let them change either. The 1st way I setup lets them flip ALL month names to short or long, titles and drop down the same.

But like I said, let me know....I am finished the cookies...scratch that, session variables mod to keep month, day, year throughout the users stay. As soon as you tell me option 1 or 2 (for month names) I can put in the code changes and upload the front side programs again.

BTW, I had to put in another define for the first letter of each day name:

define('EVENTS_WEEKDAY_FIRST_CHARS', 'S,M,T,W,T,F,S');

the calendar class that events calendar was using had two static defines, one for month long names and one for the 1st letter of each day. I changed the tpl_ scripts to update the class so it will use our defines now.

Something to add to our list:
The Calendar class is very inefficient. It hits the sql server for every single day while building the monthly calendars...that's a minimum of 28 hits to the db every time you update your page (if using the side box calendar). When you click on a year that's 390+ hits to the db. It should hit it once per month calendar at most and then once when looking at the year. Something to keep in mind.

Thanks,
Rus

[DivaVocals]

Notta problem....
Actually if you want to make it admin menu configurable then we need to do it the first way. I was thinking that this would most likely be set once at setup, and didn't need to be in the admin menu configs. But it doesn't matter either way to me. It could be argued both ways. The second way lets them choose one define for titles at the top of calendars, the other for the drop down (which is currently the short names). If you want both long then just type the full month names in both defines. When dw08 mentioned possibly using #'s for the short version I figured just have the 2 defines and let them change either. The 1st way I setup lets them flip ALL month names to short or long, titles and drop down the same.

But like I said, let me know....I am finished the cookies...scratch that, session variables mod to keep month, day, year throughout the users stay. As soon as you tell me option 1 or 2 (for month names) I can put in the code changes and upload the front side programs again.

BTW, I had to put in another define for the first letter of each day name:

define('EVENTS_WEEKDAY_FIRST_CHARS', 'S,M,T,W,T,F,S');

the calendar class that events calendar was using had two static defines, one for month long names and one for the 1st letter of each day. I changed the tpl_ scripts to update the class so it will use our defines now.

Something to add to our list:
The Calendar class is very inefficient. It hits the sql server for every single day while building the monthly calendars...that's a minimum of 28 hits to the db every time you update your page (if using the side box calendar). When you click on a year that's 390+ hits to the db. It should hit it once per month calendar at most and then once when looking at the year. Something to keep in mind.

Thanks,
Rus

Like the software I typically spec out requirements for in my day gig, I am a fan of highly configurable software options for end users where it makes sense to do so.. I am also not a fan of novice shopowners having to modify PHP pages in order to setup options they want to use in their shops.. So I like to move these kinds of options to the admin settings page so that the shopowner can select the option they want and the code handles the rest..

Now I understand why I didn't understand the second post..

Okay so that said I do like the idea of having multiple options for both the month titles at the top of the calendar as well as the dropdowns.. What code would we need to achieve this using a define that the shopowner can use to chose his option for the month title and his option for the month dropdowns??

[DivaVocals]

Like the software I typically spec out requirements for in my day gig, I am a fan of highly configurable software options for end users where it makes sense to do so.. I am also not a fan of novice shopowners having to modify PHP pages in order to setup options they want to use in their shops.. So I like to move these kinds of options to the admin settings page so that the shopowner can select the option they want and the code handles the rest..

Now I understand why I didn't understand the second post..

Okay so that said I do like the idea of having multiple options for both the month titles at the top of the calendar as well as the dropdowns.. What code would we need to achieve this using a define that the shopowner can use to chose his option for the month title and his option for the month dropdowns??

Nevermind this.. It appears that the answer was in your other post.. **LOL** (see in red.. are these the right changes to make??)

That program is for creating the side box and those month names are for the drop down...I tried it with the long and it fits for my scenario. But you could write it like this (keep in mind $monthShort is just an array, once you set it to the exploded define there's no need to follow it, its just a name, meaning there is no need to change that 3rd line.)....this is and example if you called the define variable EVENTS_LONG_MONTH_SELECT ("true" meaning use long month names):
in tpl_events_calendar_include_default.php

$monthShort = explode(",", (EVENTS_LONG_MONTH_DROPDOWNS ? EVENTS_MONTHS_LONG_ARRAY : EVENTS_MONTHS_SHORT_ARRAY));

in the defines

// Month defines in sidebox month drop-down
define('EVENTS_MONTHS_SHORT_ARRAY', 'JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC');
define('EVENTS_MONTHS_LONG_ARRAY', 'January,February,March,April,May,June,July,August,September,October,November,December');
define('EVENTS_LONG_MONTH_DROPDOWNS',true);
define('EVENTS_LONG_MONTH_TITLES',true);

Maybe we should stick EVENTS_ in front of those define names...I searched and tpl_events_calendar_include_default.php is the only program to use it.

Another thing to consider would be to use the month names already defined with the base package of zen carts, that way it only has to be changed once...plus if someone already has another language in place and drops this module in then they are good as far as months. I'm not a language expert, but does every language use the 1st 3 letters for the short version of month names? If so we could create the short month just by cutting the rest.

Last thing: If they want the option of long/short names for the drop down, do you think they want them for the side calendar and the yearly views too? If you make the following change to tpl_events_calendar_include_default.php and tpl_events_calendar_default.php it will change all of them...
Just add the line below after "$cal = new Calendar;" in both files:

$cal = new Calendar;
$cal->setMonthNames(explode(",", (EVENTS_LONG_MONTH_TITLES ? EVENTS_MONTHS_LONG_ARRAY : EVENTS_MONTHS_SHORT_ARRAY)));  //**rus: via diva: add

Maybe there should be a separate define (EVENTS_LONG_MONTH_TITLES) for that, up to you guys.

Thanks,
Rus

[LaCamus]

Nevermind this.. It appears that the answer was in your other post.. **LOL** (see in red.. are these the right changes to make??)

Wait, here's the new files....I put in two options, one for dropdowns and 1 for titles...this also has the mod so the month/year stay selected throughout the users session:
ec_4_alpha_rus_alpha.03b-store-side.zip

Here's the fix for the image manipulator, just copy over the old in your_admin/includes/classes/
events_manager_image_manipulator.zip

Thanks,
Rus

[DivaVocals]

Wait, here's the new files....I put in two options, one for dropdowns and 1 for titles...this also has the mod so the month/year stay selected throughout the users session:
ec_4_alpha_rus_alpha.03b-store-side.zip

Here's the fix for the image manipulator, just copy over the old in your_admin/includes/classes/
events_manager_image_manipulator.zip

Thanks,
Rus

Cool.. I'll incorporate this into the my working files and I'll update the admin settings menu script to add the new options.. I may even go an extra step to include an auto-installer file for the admin menu script to further reduce installation errors (this is especially helpful for novice shopowners)

[dw08gm]

Wait, here's the new files....I put in two options, one for dropdowns and 1 for titles...this also has the mod so the month/year stay selected throughout the users session:
ec_4_alpha_rus_alpha.03b-store-side.zip

Here's the fix for the image manipulator, just copy over the old in your_admin/includes/classes/
events_manager_image_manipulator.zip

Thanks,
Rus

Brilliant, will check these tonight. Despite our time differences, I sense the events_calendar camel is almost in train.

Cheers

[dw08gm]

Issues considered fixed:

Admin Side:
GIF/PNG transparencies now preserved upon resizing these types of transparent images in event manager.

Sidebox
Month/Year dropdown selections now retained through subsequent page refreshing or link clicking, and can now be used for greater calendar control (selecting specific calendar months/years, calendar years, and for easily returning to view multiple events within the aforesaid selections).


Except for one minor problem:

Store Side:
Because images larger than the encapsulating divs would not automatically shrink to within the encapsulating divs, nor shrink in proportion, I had to change Line 205 in \includes\templates\amanita\templates\tpl_events_calendar_default.php
from

<?php echo event_flink_small($event_array['image'], $event_array['title'], 'class="c1" hspace="0" vspace="0"', true); ?>

to

<?php echo event_flink_small($event_array['image'], $event_array['title'], 'class="c1" hspace="0" vspace="0"', false); ?>

while the following also worked

<?php echo event_flink_small($event_array['image'], $event_array['title'], 'class="c1"', false); ?>

I found it made no difference toggling through the following Admin > Images settings:
Calculate Image Size = True (default)
Image - Use Proportional Images on Products and Categories = 1 (default)

or switching zen_image_OLD with zen_image in \includes\functions\extra_functions\events_calendar_functions.php (Line 70).

$dumi = ($usew ? zen_image_OLD($wf, $alt, '', '', $params) : ('<img src="'.$wf.'" alt="'.$alt.'" title=" '.$alt.' " '.$params.' />'));

While I remain unclear what that true/false setting in tpl_events_calendar_default.php is intended to do exactly, I have not yet found any other way to fix this problem.

As I contemplate re-writing the readme, I am wondering how to explain this setting, and whether or not the changing of this setting can or should be placed in a language file or elsewhere.

Has anyone else experienced the same or similar problem with images larger than the encapsulating divs?



As I consider all known bugs have now been fixed or otherwise resolved, and notwithstanding the minor problem raised above, further problems, comments, criticisms or objections, I would be immensely pleased to undertake the final packaging of this mod for submission to Plugins beginning this weekend.

Rus and Diva, I cannot thank you enough for your fabulous contributions and untiring efforts, other than to say brilliant, absolutely brilliant, to the both of you.

Cheers

[DivaVocals]

My post expired so I wanted to add this.. Also I need to explain why I am advocating for admin settings versus having novice shopowners edit PHP files.. I know from experience of being a member of this community that most novice web designers and shopowners often run afoul of things when they make edits in PHP files. Putting admin and configuration items into a settings menu minimizes this possibility as fewer problems are seen when these kinds of configuration/options are properly put into an admin setting menu. The menu provides shopwoners easy access to set things up the way they want, and they do not have to monkey with the code to get there.. Options like day long versus short months should be made an admin option that is accessed via an admin menu so that novice shopowners will have fewer issues installing and setting this module up.

[DivaVocals]

Something to add to our list:
The Calendar class is very inefficient. It hits the sql server for every single day while building the monthly calendars...that's a minimum of 28 hits to the db every time you update your page (if using the side box calendar). When you click on a year that's 390+ hits to the db. It should hit it once per month calendar at most and then once when looking at the year. Something to keep in mind.

Didn't want this to get lost because you make a VERY good point.. Is this something that you are working on for this module or is it something you are raising that should be put on a to-do later list??