Pre-release feedback for v1.5.2

[lat9]

FWIW, I was able to work around this restriction by changing /zc_install/includes/application_top.php (line 52) to comment out the lines associated with the restriction:

/**
 * Timezone problem detection
 */
//if (PHP_VERSION >= '5.3' && ini_get('date.timezone') == '')
//{
//  die('ERROR: date.timezone not set in php.ini. Please contact your hosting company to set the timezone in the server PHP configuration before continuing.');
/*} else*/ if (PHP_VERSION >= '5.1') {
  $baseTZ = date_default_timezone_get();
  date_default_timezone_set($baseTZ);
  unset($baseTZ);
}

It turns out that, while 1and1 doesn't set a default timezone in the php.ini, they do set a default via date_default_timezone_set(). That said, modifying the fragment in the installation application_top.php to the following allows the install to (properly) proceed on a 1and1 server while preserving the integrity of the PHP environment (i.e. the date/timezone is set as required for PHP v5.4 and later):

/**
 * Timezone problem detection
 */
if (PHP_VERSION >= '5.3' && /*ini_get('date.timezone')*/ date_default_timezone_get() == 'UTC')
{
  die('ERROR: date.timezone not set in php.ini. Please contact your hosting company to set the timezone in the server PHP configuration before continuing.');
} else if (PHP_VERSION >= '5.1') {
  $baseTZ = date_default_timezone_get();
  date_default_timezone_set($baseTZ);
  unset($baseTZ);
}

[DrByte]

Have the following mods been fully incorporated in 152

search_configuration_keys
Fix_Cache_key utility
Keepalive Timer
time zone offset

The keepalive-timer "stub" is incorporated (ie: the core-file that is altered to make it work is now included), but the rest of that plugin is not.

The timezone offset plugin is now obsolete since the functionality for it has been incorporated.

And yes, as the whats_new file says, the Fix_Cache_Key utility and search-configuration-keys plugins are incorporated. Will add a note to the file to say those plugins are now obsolete.

[DrByte]

In /includes/templates/template_default/templates/tpl_account_default.php, shouldn't the constant used in this fragment:

<?php
  if ((int)ACCOUNT_NEWSLETTER_STATUS > 0 or CUSTOMERS_PRODUCTS_NOTIFICATION_STATUS !='0') {
?>
<h2><?php echo EMAIL_NOTIFICATIONS_TITLE; ?></h2>
<ul id="myAccountNotify" class="list">
<?php
  if ((int)ACCOUNT_NEWSLETTER_STATUS > 0) {
?>
<li><?php echo ' <a href="' . zen_href_link(FILENAME_ACCOUNT_NEWSLETTERS, '', 'SSL') . '">' . EMAIL_NOTIFICATIONS_NEWSLETTERS . '</a>'; ?></li>
<?php } //endif newsletter unsubscribe ?>

be SHOW_NEWSLETTER_UNSUBSCRIBE_LINK instead of ACCOUNT_NEWSLETTER_STATUS? The latter is the default setting for a customer's choice of newsletter sign-up (or not).

Are you saying this is incorrect? https://github.com/zencart/zencart/c...60342af8ca313f ... it was done as a result of your post here: http://www.zen-cart.com/showthread.p...nt_default-php

[DrByte]

Was there a (good) reason why the selectable-countries change introduced in v1.5.2 chose to call the enable/disable field status instead of countries_active as it is in the Selectable Countries plugin? The only reason I ask is that it's going to make the upgrade to v1.5.2 more difficult for current users of the plugin since they'll need to re-disable those countries that they don't want.

I see you've already written a script to migrate their existing settings: http://www.zen-cart.com/showthread.p...83#post1228583

[lat9]

Sorry, "senior" moment ...

[lat9]

I see you've already written a script to migrate their existing settings: http://www.zen-cart.com/showthread.p...83#post1228583

Having received no response for a week, I figured that it was going to be necessary and posted that script as a proposed work-around. If the field name in v1.5.2 is going to "take on" the countries_active name, then I can modify Selectable Countries' upgrade instructions to simply include the list of files to delete.

[DrByte]

Having received no response for a week, I figured that it was going to be necessary and posted that script as a proposed work-around. If the field name in v1.5.2 is going to "take on" the countries_active name, then I can modify Selectable Countries' upgrade instructions to simply include the list of files to delete.

"status" was deemed to be more semantically correct, hence the choice to use it instead of "countries_active"

[lat9]

It turns out that, while 1and1 doesn't set a default timezone in the php.ini, they do set a default via date_default_timezone_set(). That said, modifying the fragment in the installation application_top.php to the following allows the install to (properly) proceed on a 1and1 server while preserving the integrity of the PHP environment (i.e. the date/timezone is set as required for PHP v5.4 and later):

/**
 * Timezone problem detection
 */
if (PHP_VERSION >= '5.3' && /*ini_get('date.timezone')*/ date_default_timezone_get() == 'UTC')
{
  die('ERROR: date.timezone not set in php.ini. Please contact your hosting company to set the timezone in the server PHP configuration before continuing.');
} else if (PHP_VERSION >= '5.1') {
  $baseTZ = date_default_timezone_get();
  date_default_timezone_set($baseTZ);
  unset($baseTZ);
}

Is there a reason why my proposed "fix" didn't make it into RC2? I know that 1and1 can be problematic, but I'm not sure how many people have installed the v1.5.2 candidate on other Linux servers and how many of those servers would have implemented the same (workable) timezone solution as 1and1. Note that using date_default_timezone_get encompasses the date.timezone setting in the php.ini file.

[lhungil]

Minor:

Documentation: "/includes/dist_configure.php". Distribution Zip: "/includes/dist-configure.php"
Documentation: "/admin/includes/dist_configure.php". Distribution Zip: "/admin/includes/dist-configure.php"

[swguy]

The admin page loading issue I experienced in RC1 has been fixed in RC2. Thanks team!