Event Calendar v3

[DivaVocals]

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>
            <td class="event_description"><?php echo $event_array['ZC_link'];?></td>

for some reason there were 2 php echos for the built url with only one closing tag, not sure why.

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>

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..

[DivaVocals]

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)) );
          }
        $events->fields['ZC_link'] = preg_replace("/(\s*target\s*=\s*('|\")?\s*_blank\s*('|\")?)\s*/i","",$events->fields['ZC_link']);  //**rus:add
        $event_array = array('id' => $events->fields['event_id'],
                             'title' => $events->fields['title'],

that will strip any reference to target=_blank (w/spaces, quotes, etc).

Rus

Ha!! thanks Rus.. this worked!!!

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..

Well that was quick.. I cry uncle.. HELP!!!!!

[LaCamus]

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".

[LaCamus]

Ha!! thanks Rus.. this worked!!!
Well that was quick.. I cry uncle.. 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("/(\s*target\s*=\s*('|\")?\s*_blank\s*('|\")?)\s*/i","",$events->fields['ZC_link']);  //**rus:add
        $events->fields['ZC_link'] = preg_replace("#https?://#i",(isset($_SERVER['HTTPS']) ? "https://" : "http://"),$events->fields['ZC_link']);  //**rus:add
        $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'];?></a></td>

Rus

[DivaVocals]

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("/(\s*target\s*=\s*('|\")?\s*_blank\s*('|\")?)\s*/i","",$events->fields['ZC_link']);  //**rus:add
        $events->fields['ZC_link'] = preg_replace("#https?://#i",(isset($_SERVER['HTTPS']) ? "https://" : "http://"),$events->fields['ZC_link']);  //**rus:add
        $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'];?></a></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"><a href="http://<?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??

[LaCamus]

...
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.

[DivaVocals]

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..

[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. 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

[DivaVocals]

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..

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.

thanks

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.

[dw08gm]

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?

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.