Event Calendar v3

Events Calendar 139h for php5.3 is available for download.

http://www.zen-cart.com/downloads.php?do=file&id=521

Is there anything new with this? I'm trying to put it into a v1.5.1. I'm finding that:

1. the sidebox for it tries to pull up a full page instead of just the include
2. no link in the admin
3. actual page not showing my test entry
   http://www.htmldoctor.com/guardian/index.php?main_page=events_calendar

Mod has not yet been upgraded for v1.50+.

Looking into upgrading this mod for v150, I am wondering whether the sql needs entries for the configuration and configuration group tables, that is, that the sql only needs admin page registration. After all, there is no further configuration required for the mod once the events calendar table has been created.

Clarity appreciated.

dw08gm:

Looking into upgrading this mod for v150, I am wondering whether the sql needs entries for the configuration and configuration group tables, that is, that the sql only needs admin page registration. After all, there is no further configuration required for the mod once the events calendar table has been created.

Clarity appreciated.You need to create admin page registrations and a definition file for ANY page the add-on uses whether they are visible on the menus or not. So for example in Super Orders, there are a number of "pages" that are actually pop-up windows. They must include a page registration with a visibility setting of "N" because they will not appear on a menu. However if the store admin creates a profile that will be accessing any page which calls this popup, they must be registered so permissions to the page can be granted.

There is a LOT more info on this and a whole discussion thread surrounding this on the 1.3 - 1.5 migration thread..

Hi Folks

Please find attached Events Calendar update for zencart 151 and php5.3.

Comments and criticisms appreciated prior to my uploading to Plugins.

Attachment #12195

Cheers

dw08gm:

Hi Folks

Please find attached Events Calendar update for zencart 151 and php5.3.

Comments and criticisms appreciated prior to my uploading to Plugins.

Attachment #12195

Cheers

Hello,

First let me thank you for the job you did on the events calendar...thanks!

I installed your ec_4_alpha.zip with zen cart v1.5.1 (LAMP Centos 6.4 x86_64), and it appears to be working fine. I ran into some problems, (probably old ones or zen cart 1.5.1 induced) and made some changes to a few of the programs. I am just getting involved with zen carts and if I'm stepping on toes or am not following protocol I apologize...I just figured that the changes I made could help someone somewhere.

If you are looking to see what I cut/changed/added then look for remarks in the php files with the word "rus" in them.

First I made 2 changes to:
.../your_www/includes/templates/your_template/templates/tpl_events_calendar_default.php

1) I altered the view all_events query to not look at H:i:s: since the dates when written to the events table had no time.  This defaults the times to midnight (00:00:00) which means you would never see events that ended today (because your current date & time would always be greater, unless you clicked exactly at midnight).
2) Put in a simple change to not create html code for an event image if none existed in the db events table.

Next I made a number of changes to the following programs:
.../your_www/your_zen_admin/events_manager.php
.../your_www/your_zen_admin/includes/events_manager_drop_dns.php

1. I noticed that any file type could be uploaded when attaching images. If a client doesn't know what they are doing and they upload certain file types that could be a security risk. So I check for jpg, jpeg, gif, and png and if the file is not any of these it shows an error.
2. When you go to review an added event the file appears to be written regardless of which error flag is set. The only way to easily (without chasing down the code) avoid writing the image would be to blank the _POST image variable and reload the script. To avoid that I put in a workaround that deletes the file at the end of the script if an error was flagged.
3. I put in a define (EVENT_FILE_MAX_WIDTH) at the beginning of events_manager.php (it is currently set to 600) that is used to check against the width of the uploaded file, if it is greater then the image is reduced to 600 px wide...height is proportionate.
4. In my scenario I could think of no good reason not to overwrite an existing file. Perhaps it would have been better to use a popup and ask to overwrite the image...instead I just check for the old, remove it and save the new. This means any pre-existing event that used the old image will now use the new image.
5. changed FILENAME_DEFAULT_CATALOG to reflect "index" instead of "index.php" when creating links to manufacturers/categories/products. This may be a zen 1.5.1 thing that was missed.
6. I was having an issue with the manufacturer always overriding the categories and products when ceating a shop link. I added some javascript changes and a new manufacturer select box option ("No Manufacturer") that will remove the shop link. Perhaps a checkbox in the future would be cleaner, this works, a little ugly...for instance to remove a category or product shop link you have to select a manufacturer first then select "No Manufacturer" to remove the link.
7. Since the manufacturer isn't saved to the db event table I pull the manufacturer id from the shop link so that the correct manufacturer remains highlighted ("selected") in the select box. I may eventually do this for categories and products but it would require not using zen cart's "box" class and I hadn't researched it enough (yet) to know what kind of dependencies I might be affecting.
8. On a parsing error when file is uploaded no error was being reported, it does now.
9. The manufacturer created links would open a new tab, categories and products would not, now they all act the same way (by opening a new tab).

Finally I added:
.../your_www/your_zen_admin/includes/classes/image_manipulator.php

This is Phil Brown's image manipulator class (<https://gist.github.com/philBrown/880506>) used to resize uploaded images.

Zip is attached.

After installing ec_4_alpha.zip from previous message just put the 4 files in the appropriate directories.

Thanks again and I hope this helps,
Rus Camus

Not stepping on toes at all, and the community ALWAYS welcomes those who roll up their sleeves and jump in with GOOD stuff.. I'm sure **dw08gm **will TOTALLY appreciate someone jumping in to help with this since he's been solo on this for a while now.. Another set of eyes (and hands) NEVER hurts!!

Going back to lurk mode on this thread.. :laugh:

LaCamus:

Hello,

First let me thank you for the job you did on the events calendar...thanks!

I installed your ec_4_alpha.zip with zen cart v1.5.1 (LAMP Centos 6.4 x86_64), and it appears to be working fine. I ran into some problems, (probably old ones or zen cart 1.5.1 induced) and made some changes to a few of the programs. I am just getting involved with zen carts and if I'm stepping on toes or am not following protocol I apologize...I just figured that the changes I made could help someone somewhere.

If you are looking to see what I cut/changed/added then look for remarks in the php files with the word "rus" in them.

First I made 2 changes to:
.../your_www/includes/templates/your_template/templates/tpl_events_calendar_default.php

1) I altered the view all_events query to not look at H:i:s: since the dates when written to the events table had no time.  This defaults the times to midnight (00:00:00) which means you would never see events that ended today (because your current date & time would always be greater, unless you clicked exactly at midnight).
2) Put in a simple change to not create html code for an event image if none existed in the db events table.

---

Next I made a number of changes to the following programs:
.../your_www/your_zen_admin/events_manager.php
.../your_www/your_zen_admin/includes/events_manager_drop_dns.php

1. I noticed that any file type could be uploaded when attaching images. If a client doesn't know what they are doing and they upload certain file types that could be a security risk. So I check for jpg, jpeg, gif, and png and if the file is not any of these it shows an error.
2. When you go to review an added event the file appears to be written regardless of which error flag is set. The only way to easily (without chasing down the code) avoid writing the image would be to blank the _POST image variable and reload the script. To avoid that I put in a workaround that deletes the file at the end of the script if an error was flagged.
3. I put in a define (EVENT_FILE_MAX_WIDTH) at the beginning of events_manager.php (it is currently set to 600) that is used to check against the width of the uploaded file, if it is greater then the image is reduced to 600 px wide...height is proportionate.
4. In my scenario I could think of no good reason not to overwrite an existing file. Perhaps it would have been better to use a popup and ask to overwrite the image...instead I just check for the old, remove it and save the new. This means any pre-existing event that used the old image will now use the new image.
5. changed FILENAME_DEFAULT_CATALOG to reflect "index" instead of "index.php" when creating links to manufacturers/categories/products. This may be a zen 1.5.1 thing that was missed.
6. I was having an issue with the manufacturer always overriding the categories and products when ceating a shop link. I added some javascript changes and a new manufacturer select box option ("No Manufacturer") that will remove the shop link. Perhaps a checkbox in the future would be cleaner, this works, a little ugly...for instance to remove a category or product shop link you have to select a manufacturer first then select "No Manufacturer" to remove the link.
7. Since the manufacturer isn't saved to the db event table I pull the manufacturer id from the shop link so that the correct manufacturer remains highlighted ("selected") in the select box. I may eventually do this for categories and products but it would require not using zen cart's "box" class and I hadn't researched it enough (yet) to know what kind of dependencies I might be affecting.
8. On a parsing error when file is uploaded no error was being reported, it does now.
9. The manufacturer created links would open a new tab, categories and products would not, now they all act the same way (by opening a new tab).

---

Finally I added:
.../your_www/your_zen_admin/includes/classes/image_manipulator.php

This is Phil Brown's image manipulator class (<https://gist.github.com/philBrown/880506>) used to resize uploaded images.

---

Zip is attached.

After installing ec_4_alpha.zip from previous message just put the 4 files in the appropriate directories.

Thanks again and I hope this helps,
Rus Camus

Hi Rus

Thanks for looking into the code and offering numerous improvements. The mod has a long history of problems, but since coding is not my forte, I have been unable to do anymore than superficial upgrades. Give me a few days to back to you, probably over Easter.

Cheers

dw08gm:

Hi Rus

Thanks for looking into the code and offering numerous improvements. The mod has a long history of problems, but since coding is not my forte, I have been unable to do anymore than superficial upgrades. Give me a few days to back to you, probably over Easter.

CheersI totally relate to this! You've been holding this thing together pretty well though..

DivaVocals:

I totally relate to this! You've been holding this thing together pretty well though..

Hi Diva

Thanks for your kind words.

Cheers

Hi Rus

I have yet to install your amendments, and have only had a brief opportunity to compare your code.

Something I discovered since, however, is that my event image code in tpl_events_calendar_default (lines 172-180) seems to work if zen_image is replaced by zen_image_OLD.

In an effort to understand why zen_image_OLD works, I created the following thread:

http://www.zen-cart.com/showthread.php?207170-zen_image-vs-zen_image_OLD

While I await responses, I am wondering whether all the fine work you did with image manipulation could be replaced by simply using zen_image_OLD.

Cheers

ps No malice intended.

dw08gm:

Hi Diva

Thanks for your kind words.

CheersWell deserved praise my friend!!!

dw08gm:

Hi Rus

I have yet to install your amendments, and have only had a brief opportunity to compare your code.

Something I discovered since, however, is that my event image code in tpl_events_calendar_default (lines 172-180) seems to work if zen_image is replaced by zen_image_OLD.

In an effort to understand why zen_image_OLD works, I created the following thread:

http://www.zen-cart.com/showthread.php?207170-zen_image-vs-zen_image_OLD

While I await responses, I am wondering whether all the fine work you did with image manipulation could be replaced by simply using zen_image_OLD.

Cheers

ps No malice intended.

Coming out of lurk mode
Though I haven't reviewed the latest versions of this module (when I was looking at this I opted for a custom solution that included event invites and member only capabilities -- so I ended up not using this mod down for that project) basedon the descriptionof the changes alone, it doesn't appear that Rus' changes would interfere:

2. When you go to review an added event the file appears to be written regardless of which error flag is set. The only way to easily (without chasing down the code) avoid writing the image would be to blank the _POST image variable and reload the script. To avoid that I put in a workaround that deletes the file at the end of the script if an error was flagged.
3. I put in a define (EVENT_FILE_MAX_WIDTH) at the beginning of events_manager.php (it is currently set to 600) that is used to check against the width of the uploaded file, if it is greater then the image is reduced to 600 px wide...height is proportionate.
4. In my scenario I could think of no good reason not to overwrite an existing file. Perhaps it would have been better to use a popup and ask to overwrite the image...instead I just check for the old, remove it and save the new. This means any pre-existing event that used the old image will now use the new image.

Hi Rus

Your amendments installed fine, except for the following issues:

admin/events_manager.php
admin/includes/events_manager_drop_dns.php

1. Using the Browse button to upload images allows me to upload and insert any file type, not just jpe*g, png, gif, despite the error messages. Solution may be to copy and edit .htaccess from /images/ to /images/events_images/, but doing so may negate some of your code.

Generally, however, I prefer to adjust images offline and upload the adjusted images as a separate process, and then only use the browse button to select images from events_images folder.

I am thinking of changing the layout of the image table in event manager so that the name of the selected image and the "delete image" checkbox are both situated directly underneath the browse box. This would provide for a less cramped layout.

2. While I can select a Manufacturer, I cannot select any Category/Product, nor overwrite any selected manufacterer with Category/Product.

Cheers

dw08gm:

Hi Rus

Your amendments installed fine, except for the following issues:

1. Using the Browse button to upload images allows me to upload and insert any file type, not just jpe*g, png, gif, despite the error messages. Solution may be to copy and edit .htaccess from /images/ to /images/events_images/, but doing so may negate some of your code.

Generally, however, I prefer to adjust images offline and upload the adjusted images as a separate process, and then only use the browse button to select images from events_images folder.
From what I can see adding cloning the images/.htaccess file shouldn't hurt anything (and is something you SHOULD include anyway for security purposes) It shouldn't interfere with the new code since based on your description Rus' code does do a check for other filetypes, but isn't preventing the actual upload.. If this is the case, then the images/.htaccess shouldn't interfere..

1. I noticed that any file type could be uploaded when attaching images. If a client doesn't know what they are doing and they upload certain file types that could be a security risk. So I check for jpg, jpeg, gif, and png and if the file is not any of these it shows an error.

First...no offense taken. I am in no way going to try and force code down the throat of someone who has put forth the effort that you have on this project.

Oh boy...I wrote a lengthy reply...took about 45 minutes, I went ahead and hit the spell check, it then asked to install ispell which closed the browser, when it came back up the message was gone. Here's the short version (aww man and that other reply was so witty and interesting):

I have a friend who is an IT manager and he taunts me about spending too much time on resource management. In the world of unlimited storage and bandwidth this idea may be a little "old school". Originally it was done to save the store owner from himself, he uploaded a 3k px wide photo and the results freaked him out a little. Now he has a list of how wide images in different places should be (manufacturer logos, products, etc.) and knows to just re-upload another photo, so me adding the resizing code is just a feature for him now (plus it only works for the events' photos). On the tech side of it the resizing of the image to whatever its max viewable (delivered) width will be for the site will save on storage and bandwidth. I looked at the 2 zen image functions and they resize the image by changing the width and height fields on the html IMG tag. What this does (unless the web server has been enhanced to resize images before delivery) is send the whole disk image of the photo to the client side browser, basically full size, then the browser resizes it before viewing based on the html tag or css code. So for every hit of that photo the server sends out the full size image (1st time, then its cached on client side). If the store owner/admin is not web savvy, they might upload a very large photo and if your new code on the service sevice changes it to fit the container they may never know the true width/height (if they pay attention to the preview before the update this shouldn't happen.) Anyway, I know we are talking about nickels and simes here, but in my opinion (and after I become more familiar with Zen Carts I may try to tackle this...time, time, time, blah.) there should be settings for all the different types of images (manufacturer, inventory, category, etc.) for a max width/height, and then a function that would resize & save at every admin upload. Just talking efficiency in small quantities...over time it could add up. I have 2 virtual servers and my resources are limited on both, but where it really helps is on the client side because they're not being fed images that are larger than need be. Even on those servers that have code to resize before sending (I didn't see this in Zen Carts), your talking extra cpu cycles and disk I/O every time someone on the net is seeing that photo (for the 1st time).

<grin> That's the short version.

Thanks again for your work on this project,
Rus

Hi Rus

Well I for one am very glad you came along and took the time to positively respond. It's always good to have another pair of eyes and someone else to talk with, however long the conversations may last.

I have adopted a good number of your changes and intend to submit an update to plugins as soon as I add some words about image sizes etc to the readme and rejig the event_manager image box - hopefully all by this weekend.

At last I am feeling good about the mod.

Cheers

dw08gm:

...

1. Using the Browse button to upload images allows me to upload and insert any file type, not just jpe*g, png, gif, despite the error messages. Solution may be to copy and edit .htaccess from /images/ to /images/events_images/, but doing so may negate some of your code.

Generally, however, I prefer to adjust images offline and upload the adjusted images as a separate process, and then only use the browse button to select images from events_images folder.

I am thinking of changing the layout of the image table in event manager so that the name of the selected image and the "delete image" checkbox are both situated directly underneath the browse box. This would provide for a less cramped layout.

2. While I can select a Manufacturer, I cannot select any Category/Product, nor overwrite any selected manufacterer with Category/Product.

Cheers

1. I remember running into trouble and trying to figure out why I couldn't get the event_image variables to reset. The file is being deleted when it is not an image, but the url was still being written which then shows a broken image box. I see now(I found the code) why it is happening, but the solution wound up being really simple...
   In the code I added to admin/events_manager.php around line 92 I have:

              if (!in_array($fileext, $validext)) {
                $messageStack->add('Uploaded file ' . $working_file->filename . ' is not a jpg, jpeg, png, or gif.', 'error');
                $event_error = true;
                $success = false;
                $file_to_delete = $working_file->destination . $working_file->filename;
              } else {

...just 1 line has to be added, it should look like this:

              if (!in_array($fileext, $validext)) {
                $messageStack->add('Uploaded file ' . $working_file->filename . ' is not a jpg, jpeg, png, or gif.', 'error');
                $event_error = true;
                $success = false;
                $file_to_delete = $working_file->destination . $working_file->filename;
                $_POST['no_image'] = 'on';    //**rus: new line, simulate removal of image url
              } else {

2. Odd, on my version it is working. In the file admin/includes/events_manager_drop_dns.php there are probably 3 places to look:
   around line 31...

  $select_box .= '<option value="-1">No Manufacturer</option>';

...the option's value has to be "-1", it triggers an event in events_manager.php.

Also make sure the following javascript additions are there, that's what zaps the manufacturer option for you.
around line 79...

//** rus: start
    $dum_oc = "document.getElementById('manufacturers_id_sel').value = ''; submit();";
    $info_box_contents[] = array('form'  => '', 'align' => 'left', 'text'  => zen_draw_pull_down_menu('cPath', zen_get_category_tree(), '', 'onChange="' . $dum_oc . '"'));
//** rus: replaced:    $info_box_contents[] = array('form'  => '', 'align' => 'left', 'text'  => zen_draw_pull_down_menu('cPath', zen_get_category_tree(), '', 'onChange="submit();"'));
//** rus: stop

...and around line 113...

//** rus: start
  $info_box_contents[] = array('form' => '', 'align' => 'left', 'text' => zen_draw_pull_down_menu('products_id', $products_array, '','onChange="' . $dum_oc . '"'));
//** rus: replaced:  $info_box_contents[] = array('form' => '', 'align' => 'left', 'text' => zen_draw_pull_down_menu('products_id', $products_array, '','onChange="submit();"'));
//** rus: stop

The javascript will probably have to be added to the upcoming products select box also...my client wasn't using the feature, but I could do that if needed, just let me know.

I'm hoping I remarked all of my changes, I'm going to feel really bad if I didn't. If you want I can look at the 2 files you changed on your end and find out if I missed something.

Also, when I was testing I noticed another bug (and some bad grammar) that I introduced, nothing major, just an annoyance...when there is no file being uploaded an error is triggered which shows a message (...file may be too large). So around line 162 of admin/events_manager.php where it says...

                    $messageStack->add('There was a error uploading your image file (may be too large)', 'error');

...change it to...

                    if ($_FILES['event_image']['error']!=UPLOAD_ERR_NO_FILE) $messageStack->add('There was an error uploading your image file (may be too large)', 'error');

One last thing I saw was another little annoyance. I didn't round the height to an integer when resizing. It didn't affect the functionality, it just showed decimal places when printing the resizing message. So around line 105 of admin/events_manager.php...

                  $nhei = $ehei * ($nwid / $ewid);

...change to...

                  $nhei = intval($ehei * ($nwid / $ewid));

Let me know if I can help in any way.

Thanks again,
Rus

LaCamus:

First...no offense taken. I am in no way going to try and force code down the throat of someone who has put forth the effort that you have on this project.

Oh boy...I wrote a lengthy reply...took about 45 minutes, I went ahead and hit the spell check, it then asked to install ispell which closed the browser, when it came back up the message was gone. Here's the short version (aww man and that other reply was so witty and interesting):

I have a friend who is an IT manager and he taunts me about spending too much time on resource management. In the world of unlimited storage and bandwidth this idea may be a little "old school". Originally it was done to save the store owner from himself, he uploaded a 3k px wide photo and the results freaked him out a little. Now he has a list of how wide images in different places should be (manufacturer logos, products, etc.) and knows to just re-upload another photo, so me adding the resizing code is just a feature for him now (plus it only works for the events' photos). On the tech side of it the resizing of the image to whatever its max viewable (delivered) width will be for the site will save on storage and bandwidth. I looked at the 2 zen image functions and they resize the image by changing the width and height fields on the html IMG tag. What this does (unless the web server has been enhanced to resize images before delivery) is send the whole disk image of the photo to the client side browser, basically full size, then the browser resizes it before viewing based on the html tag or css code. So for every hit of that photo the server sends out the full size image (1st time, then its cached on client side). If the store owner/admin is not web savvy, they might upload a very large photo and if your new code on the service sevice changes it to fit the container they may never know the true width/height (if they pay attention to the preview before the update this shouldn't happen.) Anyway, I know we are talking about nickels and simes here, but in my opinion (and after I become more familiar with Zen Carts I may try to tackle this...time, time, time, blah.) there should be settings for all the different types of images (manufacturer, inventory, category, etc.) for a max width/height, and then a function that would resize & save at every admin upload. Just talking efficiency in small quantities...over time it could add up. I have 2 virtual servers and my resources are limited on both, but where it really helps is on the client side because they're not being fed images that are larger than need be. Even on those servers that have code to resize before sending (I didn't see this in Zen Carts), your talking extra cpu cycles and disk I/O every time someone on the net is seeing that photo (for the 1st time).

<grin> That's the short version.

Thanks again for your work on this project,
RusI agree with your reasoning behind the image code and IMHO something like this SHOULD be incorporated into this module.. The whole purpose of the module Image Handler is to automate the re-sizing and optimization of the product and category images. This helps shopowners do something automatically they may not remember to do on their own.

IMHO, something similar SHOULD be a part of this module for ALL the reasons you stated.. Even with instructions in the readme, novice DIY shopowners are not always going to follow these instructions and the module should include some controls to help shopowners engage in best practices with regards to image management. Adding some "Image Handler" like image size/management features including admin controls to set the max image height and width AND using the Zen Cart option to re-size the images proportionally would do the trick.. This would enforce better image management practices, and give shopowners some measure of control over the image sizes..

the option's value has to be "-1", it triggers an event in events_manager.php.

I recall seeing one instance of -1, but was not aware there were three places to look. Will have to revisit.

The javascript will probably have to be added to the upcoming products select box also...my client wasn't using the feature, but I could do that if needed, just let me know.

Yes thanks. Upcoming products would play nicely with upcoming events.

Cheers

ps. To make code changes easier to spot in the forum, may I suggest changing the color of relevent section of code to say red/blue = old/new.

Must fly now (literally)