Event Calendar v3

dw08gm:

Times, like location/directions/maps, available amenities, pre-requisites and such, are at a level of detail below the inital function of promoting "dates" in calendar format.

The recurring event feature was never intended to break up events into smaller components, but only to make it easier to input mulitple events of similar character.

As currently developed, the calendar is sufficiently flexible to provide for all manner of details, while not requiring vendors to input levels of detail they may or may not wish to provide.

Cheers

This add-on provides some BASIC event management functionality, and yes there is some flexibility within these BASIC functions. However, this add-on still does NOT TRULY support a single event spanning over multiple days where each day has a different start/end time, and it really doesn't include features which would make selling tickets to such an event possible.. To do this would require a substantial re-write to this module to support it, not the least of this being that there are no start/end time fields currently..

and YES I know that one could come up with a way to work around this and create something that works, but a workaround doesn't make this add-on capable of this kind of functionality. In fact having to use a workaround to fill in for a missing feature only serves to highlight that this add-on just doesn't contain these features..

Adding start/end time or any other fields doesn't mean that one HAS to enter this data. Clearly if it doesn't apply, then don't fill it out.. Adding a field doesn't make it a REQUIRED field, and it is very possible to write the code in such a manner that non-required fields that do not contain data need not be displayed on the event page.

Right now the only way to achieve creating something resembling a multi-day event where each day has a different start/end time with this add-on is to enter multiple single events. That said, I never said that the recurring events functionality was meant to bring this functionality to this module (it doesn't), but it does make it possible to easily enter something resembling a multi-day event by allowing one to enter multiple single events (so that EACH day can have it's own start/end time).

dw08gm:

I have been so looking forward to this moment. Immense thanks.

I never really liked forced target_blanks, since I prefered to do same with my right-mouse-button. Now that the month/year sidebox dropdown selection has been retained, target_blanks could be removed altogether without a worry. Will look into this problem though.

One thing I noticed with my recent upgrade to FF20 is that FF has added such a myriad of additional links to the right-mouse-button that the options now exceed the height of my screen, and which makes selecting "open in new window/tab" a veritable pain to find. This could be peculiar to my PC, but it annoys me no end.

Cheers
The product/manufacturer/categories links opening inside a new window/tab on the admin side is fine since they are opening store side links, but in the front-end it looks silly and unpolished.. Like one doesn't know how to develop a website since there is no reason to open internal links on the store side in a new window.

DivaVocals:

This add-on provides some BASIC event management functionality, and yes there is some flexibility within these BASIC functions. However, this add-on still does NOT TRULY support a single event spanning over multiple days where each day has a different start/end time, and it really doesn't include features which would make selling tickets to such an event possible.. To do this would require a substantial re-write to this module to support it, not the least of this being that there are no start/end time fields currently..

and YES I know that one could come up with a way to work around this and create something that works, but a workaround doesn't make this add-on capable of this kind of functionality. In fact having to use a workaround to fill in for a missing feature only serves to highlight that this add-on just doesn't contain these features..

Adding start/end time or any other fields doesn't mean that one HAS to enter this data. Clearly if it doesn't apply, then don't fill it out.. Adding a field doesn't make it a REQUIRED field, and it is very possible to write the code in such a manner that non-required fields that do not contain data need not be displayed on the event page.

Right now the only way to achieve creating something resembling a multi-day event where each day has a different start/end time with this add-on is to enter multiple single events. That said, I never said that the recurring events functionality was meant to bring this functionality to this module (it doesn't), but it does make it possible to easily enter something resembling a multi-day event by allowing one to enter multiple single events (so that EACH day can have it's own start/end time).

Having long been aware of the limitations of this mod wrt events management, I am inclined to change the beginning of your readme to the following, as I feel it better reflects what the mod actually does:

PURPOSE

This add-on essentially provides a form of DIY or in-house marketing, whereby shop-owners can promote events together with associated products from within their store, and so provide customers with extra incentive to buy, or at least reason to remember their store. In certain situations, events could become products in themselves, or be used to generate additional products.

Customers are initally introduced to events via the current calendar month displayed in a sidebox, which expands to reveal events in other time frames, all of which ultimately drill down to your products. Used wisely, opportunities should abound.

Cheers

dw08gm:

Having long been aware of the limitations of this mod wrt events management, I am inclined to change the beginning of your readme to the following, as I feel it better reflects what the mod actually does:

Cheers

I do not think that your intro should REPLACE what I currently wrote because what I wrote brief as it is is factual and relevant to shopwoners contemplating using this module. I propose that it instead be ammended as follows:

This Events Calendar add-on is ported from the OSC events calendar. It allows the shopowner to create and display events in their store. This add-on is fully integrated within the Zen Cart admin and it does not modify any core files. So there are no default override files to contend with.

This add-on essentially provides a form of DIY or in-house marketing, whereby shop-owners can promote events together with associated products from within their store, and so provide customers with extra incentive to buy, or at least reason to remember their store. **In certain situations, events could become products in themselves, or be used to generate additional products.

**Customers are initally introduced to events via the current calendar month displayed in a sidebox, which expands to reveal events in other time frames, all of which ultimately drill down to your products. Used wisely, opportunities should abound.

The brief features list should be included because frankly the current module description does not give anyone an idea what this module does, nor does it tell anyone how it differes fromt he other calendar module.. (and there are some KEY differences which I've highlighted.. The least of them is the full integration with the Zen Cart admin)

However, regarding the item in bold: This statement seems a tad misleading as written, and I am inclined to say it should not be included. Because if this can be done, I didn't see any such capability when running my test cases against this module..

How exactly do you see this module being capable of accomplishing this using it's existing features without some additional workflow/workaround that must be manually executed outside this module.

Quite frankly the distinct LACK of this feature is why I stopped pursuing using this module (or the other Zen Cart events calendar module as well) for the site I was working on for 2 years ago. I instead opted for a custom solution that REALLY allows for turning an event into a product or rather linking an event to a distinct product which allowed one to register for the event. The workflow to accomplish this didn't require any secondary steps, it was part of the event module workflow.

Regarding this section:

Customers are initally introduced to events via the current calendar month displayed in a sidebox, which expands to reveal events in other time frames
This is true, but there are two other possible means to means to access the events if a shopowner chose NOT to use the Events Calendar sidebox.. I completely forgot to add this to the readme.

1. Option 1 - Inpsipred by one of Clyde Jones' modules where he provides instructions for adding links to his modules to the Information sidebox, I had intended to include an optional file which bundles up the Information sidebox with these changes already done with an admin option (provided I can get the code for this to work) so that one can turn the Event links on/off via an admin setting in the configuration menu for this module. I will update the readme to night with this info and add in my modified Information sidebox..
2. Option 2 - Adding a link to the events pages via and EZ Page

DivaVocals:

One last bug I found that is kinda a showstopper IMHO..

The product/manufacturer/categories links open inside a new window/tab which is silly. Internal links should simply open in the current window.. I've gone though every file that had target="_blank" and target=_blank and no dice.. I can't get this to stop happening and I can't figure out why.. See this page to see what I mean..
http://zentestcart(dot)overthehillweb(dot)com/index.php?main_page=events_calendar&select_event=1Having a tab open up for the additional link (most likely external) is preferred...as a shop owner you don't want to lose focus on your store front.

That being said, the reason you can't stop it from happening by editing the store side scripts is that the link is created on the admin side with target=_blank in the tag, and then it is saved to the db. If I remember correctly, the blank targets were already being used on 3 out of the 4 link types, so I changed the last to match the others...for consistency's sake. It appeared to be an error. In order to maintain compatibility with past versions (where the target=_blank links were already written to the db) I think the easiest way is to just strip it out of the url on the store side. If you feel this is a switch that should be offered to the owners you can add it to the other admin config variables (maybe 1 for each link type). My feeling (in a perfect world) is you should be able to check a box when creating the event as to whether you want an additional link to open another tab or not. That's just for additional links, manufacturer/category/product links should be a config var or hard coded, your choice.

Here's the front side fix...in tpl_events_calendar_default.php around line 122, add:```
$date_end = ( EVENTS_LONG_DATES ? zen_date_long($events->fields['end_date'])
: date($dateDisplayFormat, mktime(0,0,0,$month_end,$day_end,$year_end)) );
}
[B]$events->fields['ZC_link'] = preg_replace("/(\starget\s=\s*('|")?\s*_blank\s*('|")?)\s*/i","",$events->fields['ZC_link']); //**rus:add[/B]
$event_array = array('id' => $events->fields['event_id'],
'title' => $events->fields['title'],

Rus

Than> LaCamus:

Having a tab open up for the additional link (most likely external) is preferred...as a shop owner you don't want to lose focus on your store front.

That being said, the reason you can't stop it from happening by editing the store side scripts is that the link is created on the admin side with target=_blank in the tag, and then it is saved to the db. If I remember correctly, the blank targets were already being used on 3 out of the 4 link types, so I changed the last to match the others...for consistency's sake. It appeared to be an error. In order to maintain compatibility with past versions (where the target=_blank links were already written to the db) I think the easiest way is to just strip it out of the url on the store side. If you feel this is a switch that should be offered to the owners you can add it to the other admin config variables (maybe 1 for each link type). My feeling (in a perfect world) is you should be able to check a box when creating the event as to whether you want an additional link to open another tab or not. That's just for additional links, manufacturer/category/product links should be a config var or hard coded, your choice.

Here's the front side fix...in tpl_events_calendar_default.php around line 122, add:```
$date_end = ( EVENTS_LONG_DATES ? zen_date_long($events->fields['end_date'])
: date($dateDisplayFormat, mktime(0,0,0,$month_end,$day_end,$year_end)) );
}
[B]$events->fields['ZC_link'] = preg_replace("/(\starget\s=\s*('|")?\s*_blank\s*('|")?)\s*/i","",$events->fields['ZC_link']); //**rus:add[/B]
$event_array = array('id' => $events->fields['event_id'],
'title' => $events->fields['title'],

> 
> Rus
The issue is not the behavior applied to external links (desireable), but that this behavior is being applied to INTERNAL links too (undesireable). I actually did make the changes to the admin side after doing a little sleuthing I found where the links were created.. I realized on the way to work that the reason none of my LOGICAL changes were working was because the URL is probably being stored in the database..:laugh: So thanks for confirming this..

That said it appears that your code strips "target=_blank" for all links and this just creates another issue in that external links will open in the parent window which is NOT what should be happening.. internal links should NOT include "target=_blank". It makes the site look like children who don't know better built it.. EXTERNAL links should absolutely open in a new window/tab for the reasons you stated.. "as a shop owner you don't want to lose focus on your store front." How do we get there??

and yes I suppose it COULD be an admin configurable item with 1 option for external links and another configurable option for internal links (for those who LIKE the old way silly as I think it is.. to each his own right?? let everybody be happy as my BFF would say :laugh:)..

DivaVocals:

This add-on provides some BASIC event management functionality, and yes there is some flexibility within these BASIC functions. However, this add-on still does NOT TRULY support a single event spanning over multiple days where each day has a different start/end time, and it really doesn't include features which would make selling tickets to such an event possible.. To do this would require a substantial re-write to this module to support it, not the least of this being that there are no start/end time fields currently..I think multiple times could probably be coded in a few days. As for the selling of tickets, this could be easy (after the ability to create multiple times per event is added), that is if you just want to link a start and end time to a product...it's the additional info that could be needed that becomes problematic. Like seating, collection of personal info (say for seminars), availability (sold out)...but in truth all of that should be a separate module on the product side (possibly a few new product types?). The event calendar should really only provide dates, times and links to info and products...2 enhancements that would be helpful when handling things like concerts or seminars would be to show availability on the event page (by using the count of the linked product remaining in stock...an existing field) and the ability to group events (think something like Jazzfest in New Orleans that covers multiple days over multiple weekends) so that all dates and times for that group could be viewed on the same page.

and YES I know that one could come up with a way to work around this and create something that works, but a workaround doesn't make this add-on capable of this kind of functionality. In fact having to use a workaround to fill in for a missing feature only serves to highlight that this add-on just doesn't contain these features..if someone knows of a workaround explain it to me, I am interested in this so I can understand the exact functionality you are looking for.

Adding start/end time or any other fields doesn't mean that one HAS to enter this data. Clearly if it doesn't apply, then don't fill it out.. Adding a field doesn't make it a REQUIRED field, and it is very possible to write the code in such a manner that non-required fields that do not contain data need not be displayed on the event page.Right...I'm thinking it would be a popup that would allow you to add multiple start/end times that could span across any of the dates within your start and end date range. An example (again) would be Jazzfest, on Friday from 7pm to 9pm on stage 2 link it to tickets for concert #1, on Friday from 11pm to Saturday 1am on main stage link to tickets for concert #2...etc. Add as many of these time slots as you like, or none at all.

Right now the only way to achieve creating something resembling a multi-day event where each day has a different start/end time with this add-on is to enter multiple single events. That said, I never said that the recurring events functionality was meant to bring this functionality to this module (it doesn't), but it does make it possible to easily enter something resembling a multi-day event by allowing one to enter multiple single events (so that EACH day can have it's own start/end time).

Rus

DivaVocals:

That said it appears that your code strips "target=_blank" for all links and this just creates another issue in that external links will open in the parent window which is NOT what should be happening.. internal links should NOT include "target=_blank". It makes the site look like children who don't know better built it.. EXTERNAL links should absolutely open in a new window/tab for the reasons you stated.. "as a shop owner you don't want to lose focus on your store front." How do we get there??That code only strips target=_blank from the links that are built from existing manufacturers/categories/products...in no case that I can think of (again, I am new to Zen Carts) is that url not going to link internally, so with that in mind it should always be stripped on the store front. There are a # of places it displays on the admin side (3 I can think of) so that meant more code changes, this one line provides simplicity and maintains backward compatibility. Even with making the changes on the admin side you still are going to need this line of code to strip all those events added with past versions of the events calendar. When you stripped those targets from the admin side did you try clicking on one of the links? ...they now will pull you out of edit mode meaning you could inadvertently lose some of your changes.

and yes I suppose it COULD be an admin configurable item with 1 option for external links and another configurable option for internal links (for those who LIKE the old way silly as I think it is.. to each his own right?? let everybody be happy as my BFF would say :laugh:)..

I forget to put this in the other post...I found a bug around line 175, the line should read:```
<tr> <!-- event ZC_Link row -->
<td class="event_heading" nowrap="nowrap">
<strong><?php echo TEXT_EVENT_ZC_LINK;?></strong></td>
[B]<td class="event_description"><?php echo $event_array['ZC_link'];?></td>[/B]

Another thing, those links in the admin are being built with https:// (instead of http://) if your site supports ssl.  I don't think it should have been programmed that way.  It should use whatever the default prefix is for the front side, instead it is using the back (admin) prefix.  There should probably be some code in there to check the main url and pull the prefix from it to build the store link url.

LaCamus:

Right...I'm thinking it would be a popup that would allow you to add multiple start/end times that could span across any of the dates within your start and end date range. An example (again) would be Jazzfest, on Friday from 7pm to 9pm on stage 2 link it to tickets for concert #1, on Friday from 11pm to Saturday 1am on main stage link to tickets for concert #2...etc. Add as many of these time slots as you like, or none at all....this also allows for having overlapping times. Say two concerts going on at the same time. For seminars you may want to open up another one in another room at the same time if the event becomes popular and sells out.

LaCamus:

I think multiple times could probably be coded in a few days. As for the selling of tickets, this could be easy (after the ability to create multiple times per event is added), that is if you just want to link a start and end time to a product...it's the additional info that could be needed that becomes problematic. Like seating, collection of personal info (say for seminars), availability (sold out)...but in truth all of that should be a separate module on the product side (possibly a few new product types?). The event calendar should really only provide dates, times and links to info and products...2 enhancements that would be helpful when handling things like concerts or seminars would be to show availability on the event page (by using the count of the linked product remaining in stock...an existing field) and the ability to group events (think something like Jazzfest in New Orleans that covers multiple days over multiple weekends) so that all dates and times for that group could be viewed on the same page.
You are right event ticket sales SHOULD be handled as a new product type. The event manager is meant to create/manage events. However linking a product to an event product doesn't have to require a new module persay.. It WILL require a custom product type to manage all the data collection that comes with event sales. ie: Like collection of personal info (say for seminars), etc. Availability doesn't require anything new.. It can be managed using default Zen Cart inventory management features.. set the inventory level for your event product to the number of seats available.

The custom module I had built allowed me to link an event to an existing "regular" product/category/manufacturer (not unlike this module). However if I wanted to create a NEW event product so that I could sell tickets to that event, I could do so from the event manager. Creating an event and adding an event product in one workflow is much more efficient from a user POV versus making the user create the event product, then create the event and THEN link the event product to the event.. In my custom event manager, the high level workflows for this was as follows:
One Day Event Workflow
Create an event
Set the start/end date
Set the start/end time
Set location (locations were managed as part of the Event Manager)
Link a "regular" product/category/manufacturer
OR
Create a product to sell tickets for this event. (the event product would be linked to the event at the end of the workflow)

Multi-Day Day Event Workflow
Create an event
Set the start/end date
Set the number of days this event spans
Set the start/end times for each day
Set location (locations were managed as part of the Event Manager)
Link a "regular" product/category/manufacturer
OR
Create a product to sell tickets for this event. (the event product would be linked to the event at the end of the workflow)

Ticket options (like child ticket vs adult ticket, register for one day versus three days of a three day event) were managed using the default attributes features build into Zen Cart. We used a little custom code to manage things like early bird registration discounts based on the day tickets were purchased (discount was a field set on the event product type).. Free events which still required registration simply meant that we created a zero dollar product. As for locations my custom module was not setup for managing specific seats (like in the concert venue example). My custom module was designed more for organizing camping trips, little league registrations, seminars, tradeshows, and other similar type of events. So locations contained addresses, Google Map info, phone numbers, hours of operation, etc.

Now my custom module also managed RSVPS and had other guestlist management functions which I am NOT suggesting should be added to this module. In fact I am not really suggesting any of the stuff I'm talking about should be added RIGHT NOW.. I think what's in place right now is good enough to submit once these last few cleanup items are addressed.. However, I am saying that in order for this module to become something mature and really feature packed it should be the direction/roadmap that this thing SHOULD be headed for eventually..

LaCamus:

if someone knows of a workaround explain it to me, I am interested in this so I can understand the exact functionality you are looking for.

Right...I'm thinking it would be a popup that would allow you to add multiple start/end times that could span across any of the dates within your start and end date range. An example (again) would be Jazzfest, on Friday from 7pm to 9pm on stage 2 link it to tickets for concert #1, on Friday from 11pm to Saturday 1am on main stage link to tickets for concert #2...etc. Add as many of these time slots as you like, or none at all.

RusThere is no workaround for this.. I can SIMULATE a multiple day event by creating multiple single events that have the same title/description with the different dates.. but I would have to enter the start/end times in the event description, and I could jerryrig up an event product to sell tickets using attributes, but it would only work for very simple events, and there would be no way to register multiple registrants for an event like a seminar. Each registrant ticket wold have to be purchased separately or you'd have to rely on folks using the order comments to enter registrant data.. Bottomline it would be error prone and messy..

LaCamus:

...this also allows for having overlapping times. Say two concerts going on at the same time. For seminars you may want to open up another one in another room at the same time if the event becomes popular and sells out.

LaCamus:

I forget to put this in the other post...I found a bug around line 175, the line should read:```
<tr> <!-- event ZC_Link row -->
<td class="event_heading" nowrap="nowrap">
<strong><?php echo TEXT_EVENT_ZC_LINK;?></strong></td>
[B]<td class="event_description"><?php echo $event_array['ZC_link'];?></td>[/B]

Should I make the same change to this line as follows:

        <td class="event_details_description"><a  href="<?php echo $event_array['ADDL_link'];?>"  target="_blank"><?php echo  $event_array['ADDL_link'];?></td>

Becomes:

        <td class="event_details_description"><?php echo $event_array['ADDL_link'];?></td>

> **LaCamus:**
>
> Another thing, those links in the admin are being built with https:// (instead of http://) if your site supports ssl.  I don't think it should have been programmed that way.  It should use whatever the default prefix is for the front side, instead it is using the back (admin) prefix.  There should probably be some code in there to check the main url and pull the prefix from it to build the store link url.Agreed.. I think I know how to make this change.. I'll give it a whirl.. :smile:

LaCamus:

Having a tab open up for the additional link (most likely external) is preferred...as a shop owner you don't want to lose focus on your store front.

That being said, the reason you can't stop it from happening by editing the store side scripts is that the link is created on the admin side with target=_blank in the tag, and then it is saved to the db. If I remember correctly, the blank targets were already being used on 3 out of the 4 link types, so I changed the last to match the others...for consistency's sake. It appeared to be an error. In order to maintain compatibility with past versions (where the target=_blank links were already written to the db) I think the easiest way is to just strip it out of the url on the store side. If you feel this is a switch that should be offered to the owners you can add it to the other admin config variables (maybe 1 for each link type). My feeling (in a perfect world) is you should be able to check a box when creating the event as to whether you want an additional link to open another tab or not. That's just for additional links, manufacturer/category/product links should be a config var or hard coded, your choice.

Here's the front side fix...in tpl_events_calendar_default.php around line 122, add:```
$date_end = ( EVENTS_LONG_DATES ? zen_date_long($events->fields['end_date'])
: date($dateDisplayFormat, mktime(0,0,0,$month_end,$day_end,$year_end)) );
}
[B]$events->fields['ZC_link'] = preg_replace("/(\starget\s=\s*('|")?\s*_blank\s*('|")?)\s*/i","",$events->fields['ZC_link']); //**rus:add[/B]
$event_array = array('id' => $events->fields['event_id'],
'title' => $events->fields['title'],

> 
> Rus
Ha!! thanks Rus.. this worked!!!:clap:
> **LaCamus:**
>
> Another thing, those links in the admin are being built with https:// (instead of http://) if your site supports ssl.  I don't think it should have been programmed that way.  It should use whatever the default prefix is for the front side, instead it is using the back (admin) prefix.  There should probably be some code in there to check the main url and pull the prefix from it to build the store link url.> **DivaVocals:**
>
> Agreed.. I think I know how to make this change.. I'll give it a whirl.. :smile:Well that was quick.. I cry uncle.. :laugh: HELP!!!!!

DivaVocals:

Should I make the same change to this line as follows:actually no, not sure why but the product links and the additional links are stored differently. Man/cat/prod links have the full tag already wrapped around the link text (done on admin side). The additional link uses just the address then builds the tag on the frontside wrapping the address around itself as descriptive text and adding target="_blank".

DivaVocals:

Ha!! thanks Rus.. this worked!!!:clap:
Well that was quick.. I cry uncle.. :laugh: HELP!!!!!in admin/includes/configure.php zen cart has this as a comment:```
/**

• WE RECOMMEND THAT YOU USE SSL PROTECTION FOR YOUR ENTIRE ADMIN:
• To do that, make sure you use a "https:" URL for BOTH the HTTP_SERVER and HTTPS_SERVER entries:
  /
  now if you do what they suggest (which I did) it means anything that references those variables is going to use the secure prefix. What I suggest is to just fix it on the front side and not only for the same reasons as the target fix we just added, but because we should feed the link to the user with whatever the current prefix is at that time...the time of viewing. The user may have come out of a secure section or the owner is feeding his whole site through ssl, who knows. So my suggestion is to add, right after the last line we just added:
  $events->fields['ZC_link'] = preg_replace("/(\starget\s*=\s*('|")?\s*_blank\s*('|")?)\s*/i","",$events->fields['ZC_link']); //**rus:add
  [B]$events->fields['ZC_link'] = preg_replace("#https?://#i",(isset($_SERVER['HTTPS']) ? "https://" : "http://"),$events->fields['ZC_link']); //**rus:add[/B]
  $event_array = array('id' => $events->fields['event_id'],
  Also, after looking at that additional link again I noticed that they didn't close the link there, so:
  <tr> <!-- event Additonal Link row -->
  <td class="event_heading" nowrap="nowrap">
  <strong><?php echo TEXT_EVENT_LINK;?></strong></td>
  <td class="event_description"><a href="http://<?php echo $event_array['ADDL_link'];?>" target="_blank">
  <?php echo $event_array['ADDL_link'];?>[B]</a>[/B]</td>

Rus

LaCamus:

in admin/includes/configure.php zen cart has this as a comment:```
/**

• WE RECOMMEND THAT YOU USE SSL PROTECTION FOR YOUR ENTIRE ADMIN:
• To do that, make sure you use a "https:" URL for BOTH the HTTP_SERVER and HTTPS_SERVER entries:
  /
  now if you do what they suggest (which I did) it means anything that references those variables is going to use the secure prefix. What I suggest is to just fix it on the front side and not only for the same reasons as the target fix we just added, but because we should feed the link to the user with whatever the current prefix is at that time...the time of viewing. The user may have come out of a secure section or the owner is feeding his whole site through ssl, who knows. So my suggestion is to add, right after the last line we just added:
  $events->fields['ZC_link'] = preg_replace("/(\starget\s*=\s*('|")?\s*_blank\s*('|")?)\s*/i","",$events->fields['ZC_link']); //**rus:add
  [B]$events->fields['ZC_link'] = preg_replace("#https?://#i",(isset($_SERVER['HTTPS']) ? "https://" : "http://"),$events->fields['ZC_link']); //**rus:add[/B]
  $event_array = array('id' => $events->fields['event_id'],
  Also, after looking at that additional link again I noticed that they didn't close the link there, so:
  <tr> <!-- event Additonal Link row -->
  <td class="event_heading" nowrap="nowrap">
  <strong><?php echo TEXT_EVENT_LINK;?></strong></td>
  <td class="event_description"><a href="http://<?php echo $event_array['ADDL_link'];?>" target="_blank">
  <?php echo $event_array['ADDL_link'];?>[B]</a>[/B]</td>

> Rus

Okay that's done.. The links block now looks like this:

<!-- begin event ZC_Link/Additional row -->

      <tr>
        <td class="event_heading" nowrap="nowrap"><?php echo TEXT_EVENT_ZC_LINK;?></td>
        <td class="event_details_description"><?php echo $event_array['ZC_link'];?></td>
      </tr>
      <?php
      }
      if($event_array['ADDL_link'])
      {
      ?>
      <tr> 
        <td class="event_heading" nowrap="nowrap"><?php echo TEXT_EVENT_LINK;?></td>
        <td class="event_details_description"><[B]a href="http://[/B]<?php echo $event_array['ADDL_link'];?>" target="_blank"><?php echo $event_array['ADDL_link'];?></a></td>
      </tr>
      <?php
      }
      ?>

<!-- end event ZC_Link/Traditional row -->

Which brings to mind an additional question.. As you stated "because we should feed the link to the user with whatever the current  prefix is at that time...the time of viewing.  The user may have come  out of a secure section or the owner is feeding his whole site through  ssl, who knows." It would appear that this is not being applied to the additional links. (see red highlight above) How do we fix that??

DivaVocals:

...
Which brings to mind an additional question.. As you stated "because we should feed the link to the user with whatever the current prefix is at that time...the time of viewing. The user may have come out of a secure section or the owner is feeding his whole site through ssl, who knows." It would appear that this is not being applied to the additional links. (see red highlight above) How do we fix that??
I actually had a fix worked in, setting a variable and applying it to both. Then I thought about it and took it out. The additional link should not be forced to use the same prefix as the internal (ZC) link since it is most likely external. We could actually test the additional link to see if it is located on the same site as the store and if so apply the current prefix, but I would just let it go and do it right in the next version. Meaning, put a checkbox on the admin side to keep the additional link in the same window or not (target=_blank on/off), let the user put the http prefix in the url themselves (it currently tells them not to), and also add an input field to allow them to add their own decriptive text...then build the link on the admin side and save it to the db, just like the ZC link does. That would also be a good time to pull those _blank's from the ZC link code and build a function to force the target to _blank... only on the admin side.

LaCamus:

I actually had a fix worked in, setting a variable and applying it to both. Then I thought about it and took it out. The additional link should not be forced to use the same prefix as the internal (ZC) link since it is most likely external. We could actually test the additional link to see if it is located on the same site as the store and if so apply the current prefix, but I would just let it go and do it right in the next version. Meaning, put a checkbox on the admin side to keep the additional link in the same window or not (target=_blank on/off), let the user put the http prefix in the url themselves (it currently tells them not to), and also add an input field to allow them to add their own decriptive text...then build the link on the admin side and save it to the db, just like the ZC link does. That would also be a good time to pull those _blank's from the ZC link code and build a function to force the target to _blank... only on the admin side.
But isn't the module using the additional links code for files linked to the event?? These files are all internal links..

Few problems upon uploading diva's latest version (and after comparing previous versions)

a) The admin resize image function no longer works, ie the button gets highlighted but the image does not get resized up or down.

b) Admin > Configration > Event Calendar Settings

Include the IMG tag height and width = true, yields

<!-- bof event image -->
  <div class="event_image_outer">
    <div class="event_image_inner">
	<img src="images/events_images/850x850_zen_logo.gif" alt="april end" title=" april end " width="700" height="700" class="event_calendar_image" />	</div>
    <div class="clearLeft"> </div>
  </div>
<!-- eof event image -->

Include the IMG tag height and width = false, yields

<!-- bof event image -->
  <div class="event_image_outer">
    <div class="event_image_inner">
	<img src="images/events_images/850x850_zen_logo.gif" alt="april end" title=" april end " class="event_calendar_image" />	</div>
    <div class="clearLeft"> </div>
  </div>
<!-- eof event image -->

The result was that the true setting does not preserve proportionality, while the false does. There must be a way to preserve proportionality with the true setting, while also catering for accessibility. I had the max width and max height settings both at 600

c) includes\templates\amanita\templates\tpl_events_calendar_default.php

      $event_array[] = array('id' => $q_events->fields['event_id'], 'text' => $dd_months[$month - 1] . ' ' . $day . ' - ' . $q_events->fields['title']);

In the main column dropdown, I would prefer events to be prefaced by Mmm-dd eg Apr-23, or better still 23-Apr-2013, rather than APR-23, which looks a little too loud. However, if putting the day before the month will affect the chronological display in the dropdown, 2013-Apr-23 would be OK.

thanks

dw08gm:

Few problems upon uploading diva's latest version (and after comparing previous versions)

a) the admin resize image function no longer works, ie the button gets highlighted but the image does not get resized up or down.

b)Admin > Configration > Event Calendar Settings

Include the IMG tag height and width = true, yields

<!-- bof event image --> <div class="event_image_outer"> <div class="event_image_inner"> <img src="images/events_images/850x850_zen_logo.gif" alt="april end" title=" april end " width="700" height="700" class="event_calendar_image" /> </div> <div class="clearLeft"> </div> </div> <!-- eof event image --> ``` > > Include the IMG tag height and width = false, yields > > ``` <!-- bof event image --> <div class="event_image_outer"> <div class="event_image_inner"> <img src="images/events_images/850x850_zen_logo.gif" alt="april end" title=" april end " class="event_calendar_image" /> </div> <div class="clearLeft"> </div> </div> <!-- eof event image --> ``` > > The result was that the true setting does not preserve proportionality, while the false does. There must be a way to preserve proportionality with the true setting, while also catering for accessibility.

The short answer is no you can't have both.. this is why Rus proposed the code without the height and width for your desire for the container to control the height and width of the image.. I merely wrapped in an if statement so that those who wanted resizing could use it. The YES setting is really meant for folks who want to use the image re-sizing feature..

dw08gm:

c) includes\templates\amanita\templates\tpl_events_calendar_default.php

// date format
// Short month name Capitalised + day
$event_array[] = array('id' => $q_events->fields['event_id'], 'text' => $dd_months[$month - 1] . ' ' . $day . ' - ' . $q_events->fields['title']);

For the main column dropdown, I would prefer events to be prefaced by Mmm-dd eg Apr-23, or better still 23-Apr-2013, rather than APR-23, which looks a little too loud. However, if putting the day before the month will affect the chronological display in the dropdown, 2013-Apr-23 would be OK.

thanksThen simply change the defines for the short months.. (ie: APR becomes Apr) We can change that now or leave it as is and leave it to individial shopowners to modify those as they see fit.

DivaVocals:

The short answer is no you can't have both.. this is why Rus proposed the code without the height and width for your desire for the container to control the height and width of the image.. I merely wrapped in an if statement so that those who wanted resizing could use it. The YES setting is really meant for folks who want to use the image re-sizing feature..

I hope you noticed the image I inserted was square. The displayed result was rectangular shown in portrait.

Is there no other way to provide for accessibility?

DivaVocals:

Then simply change the defines for the short months.. (ie: APR becomes Apr) We can change that now or leave it as is and leave it to individial shopowners to modify those as they see fit.

But changing the define to short month changes the sidebox also. I wish to keep the sidebox as short months all in capitals.