Printable View
Just to be clear, you're talking about the light-grey vs the dark-grey boxes being not-exactly-sitting-perfectly-aligned-on-each-other at all resolutions?Quote:
Originally Posted by bn17311
Is this "on specific devices" ... or is it because you're resizing a desktop browser and noticing a progressive change?
I just want to be sure we're talking about the same thing.
iPad doesn't line up and desktop noticable when resizing window, maybe because everything else seems to sit well it catches your eyeQuote:
Originally Posted by DrByte
only posting hoping its being helpful as i do think its looking good.
bn
Just FYI ... while we'd hoped to release v1.5.5 sometime in the past 3 days, in some of our testing today we ran into some bugs that will cause SQL query errors in the latest MySQL versions ... and there are still a few mobile-related CSS things we want to tidy up.
We'd rather not release it with known bugs like that, so we'll try again for tomorrow and thru the weekend.
It'll be released as soon as we can.
In the meantime, we want to wish you all a Happy New Year!
I have just installed from a fresh download and ran it through the validatorQuote:
Originally Posted by picaflor-azul
As you can see there are several errors that are template related and these also seem to be standard with most of your templates
1.5.5 install
https://jigsaw.w3.org/css-validator/...rning=&lang=en
1.5.4 with the westminster_new template
https://jigsaw.w3.org/css-validator/...rning=&lang=en
Are these to be addressed at the developer level or left to the community to fix for each install
Happy New Year ... back at you! Since I've got the chance, I figured that I'd request just a few::P more notifiers:Quote:
Originally Posted by DrByte
/includes/classes/order.php:
Code:function create_add_products($zf_insert_id, $zf_mode = false) {
global $db, $currencies, $order_total_modules, $order_totals;
// initialized for the email confirmation
$this->products_ordered = '';
$this->products_ordered_html = '';
$this->subtotal = 0;
$this->total_tax = 0;
// lowstock email report
$this->email_low_stock='';
for ($i=0, $n=sizeof($this->products); $i<$n; $i++) {
$custom_insertable_text = '';
$this->notify ('NOTIFY_ORDER_CREATE_ADD_PRODUCTS_BEGIN', array ( 'i' => $i)); //-products_options_stock-lat9 *** 1 of 2 ***
$this->doStockDecrement = (STOCK_LIMITED == 'true');
$this->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_INIT', array(), $this->products[$i], $i);
// Stock Update - Joao Correia
if ($this->doStockDecrement) {
Code:
$this->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_END', $i);
$sql_data_array = array('orders_id' => $zf_insert_id,
'products_id' => zen_get_prid($this->products[$i]['id']),
'products_model' => $this->products[$i]['model'],
'products_name' => $this->products[$i]['name'],
'products_price' => $this->products[$i]['price'],
'final_price' => $this->products[$i]['final_price'],
'onetime_charges' => $this->products[$i]['onetime_charges'],
'products_tax' => $this->products[$i]['tax'],
'products_quantity' => $this->products[$i]['qty'],
'products_priced_by_attribute' => $this->products[$i]['products_priced_by_attribute'],
'product_is_free' => $this->products[$i]['product_is_free'],
'products_discount_type' => $this->products[$i]['products_discount_type'],
'products_discount_type_from' => $this->products[$i]['products_discount_type_from'],
'products_prid' => $this->products[$i]['id']);
zen_db_perform(TABLE_ORDERS_PRODUCTS, $sql_data_array);
$order_products_id = $db->Insert_ID();
$this->notify('NOTIFY_ORDER_DURING_CREATE_ADDED_PRODUCT_LINE_ITEM', array_merge(array('orders_products_id' => $order_products_id, 'i' => $i), $sql_data_array), $order_products_id); //-products_options_stock-lat9 *** 2 of 2 ***
$this->notify('NOTIFY_ORDER_PROCESSING_CREDIT_ACCOUNT_UPDATE_BEGIN');
$order_total_modules->update_credit_account($i);//ICW ADDED FOR CREDIT CLASS SYSTEM
Code://comments area
if ($this->info['comments']) {
$email_order .= zen_db_output($this->info['comments']) . "\n\n";
$html_msg['ORDER_COMMENTS'] = nl2br(zen_db_output($this->info['comments']));
} else {
$html_msg['ORDER_COMMENTS'] = '';
}
//-bof-multiship-lat9 *** 1 of 2 ***
$this->notify('NOTIFY_ORDER_EMAIL_BEFORE_PRODUCTS', array(), $email_order, $html_msg);
//-eof-multiship-lat9 *** 1 of 2 ***
//products area
$email_order .= EMAIL_TEXT_PRODUCTS . "\n" .
EMAIL_SEPARATOR . "\n" .
$this->products_ordered .
/includes/modules/attributes.php:Code:
$html_msg['EMAIL_FIRST_NAME'] = $this->customer['firstname'];
$html_msg['EMAIL_LAST_NAME'] = $this->customer['lastname'];
// $html_msg['EMAIL_TEXT_HEADER'] = EMAIL_TEXT_HEADER;
$html_msg['EXTRA_INFO'] = '';
$this->notify('NOTIFY_ORDER_INVOICE_CONTENT_READY_TO_SEND', array('zf_insert_id' => $zf_insert_id, 'text_email' => $email_order, 'html_email' => $html_msg), $email_order, $html_msg);
//-bof-multiship-lat9 *** 2 of 2 ***
$this->notify('NOTIFY_ORDER_INVOICE_CONTENT_READY_TO_SEND2', array('zf_insert_id' => $zf_insert_id), $email_order, $html_msg);
//-eof-multiship-lat9 *** 2 of 2 ***
Code:$tmp_attributes_image = '';
$tmp_attributes_image_row = 0;
$show_attributes_qty_prices_icon = 'false';
//-bof-attribute_image_swatch-lat9 *** 1 of 4 ***
$zco_notifier->notify('NOTIFY_ATTRIBUTES_MODULE_START_OPTION', $products_options_names->fields);
//-eof-attribute_image_swatch-lat9 *** 1 of 4 ***
while (!$products_options->EOF) {
// reset
$products_options_display_price='';
$new_attributes_price= '';
$price_onetime = '';
$products_options_array[] = array('id' => $products_options->fields['products_options_values_id'],
'text' => $products_options->fields['products_options_values_name']);
//-bof-posm_price_weight-lat9 *** 1 of 1 ***
$zco_notifier->notify ('NOTIFY_ATTRIBUTES_MODULE_START_OPTIONS_LOOP', array (), $products_options->fields);
//-eof-posm_price_weight-lat9 *** 1 of 1 ***
Code:}
$tmp_html .= $products_options_details;
}
//-bof-attribute_image_swatch-lat9 *** 2 of 4 ***
$zco_notifier->notify('NOTIFY_ATTRIBUTES_MODULE_FORMAT_VALUE', $products_options->fields);
//-eof-attribute_image_swatch-lat9 *** 2 of 4 ***
// collect attribute image if it exists and to be drawn in table below
if ($products_options_names->fields['products_options_images_style'] == '0' or ($products_options_names->fields['products_options_type'] == PRODUCTS_OPTIONS_TYPE_FILE or $products_options_names->fields['products_options_type'] == PRODUCTS_OPTIONS_TYPE_TEXT or $products_options_names->fields['products_options_type'] == '0') ) {
if ($products_options->fields['attributes_image'] != '') {
Code:}
$options_html_id[] = 'drp-attrib-' . $products_options_names->fields['products_options_id'];
$options_menu[] = zen_draw_radio_field('id[' . $products_options_names->fields['products_options_id'] . ']', $products_options_value_id, 'selected', 'id="' . 'attrib-' . $products_options_names->fields['products_options_id'] . '-' . $products_options_value_id . '"') . '<label class="attribsRadioButton" for="' . 'attrib-' . $products_options_names->fields['products_options_id'] . '-' . $products_options_value_id . '">' . $products_options_details . '</label>' . "\n";
$options_comment[] = $products_options_names->fields['products_options_comment'];
$options_comment_position[] = ($products_options_names->fields['products_options_comment_position'] == '1' ? '1' : '0');
break;
//-bof-attribute_image_swatch-lat9 *** 3 of 4 ***
case ($products_options_names->fields['products_options_type'] == PRODUCTS_OPTIONS_TYPE_SELECT): // Was default:
//-eof-attribute_image_swatch-lat9 *** 3 of 4 ***
// normal dropdown menu display
if (isset($_SESSION['cart']->contents[$prod_id]['attributes'][$products_options_names->fields['products_options_id']])) {
/YOUR_ADMIN/attributes_controller.phpCode:$options_html_id[] = 'drp-attrib-' . $products_options_names->fields['products_options_id'];
$options_menu[] = zen_draw_pull_down_menu('id[' . $products_options_names->fields['products_options_id'] . ']', $products_options_array, $selected_attribute, 'id="' . 'attrib-' . $products_options_names->fields['products_options_id'] . '"') . "\n";
$options_comment[] = $products_options_names->fields['products_options_comment'];
$options_comment_position[] = ($products_options_names->fields['products_options_comment_position'] == '1' ? '1' : '0');
break;
//-bof-attribute_image_swatch-lat9 *** 4 of 4 ***
default:
$zco_notifier->notify('NOTIFY_ATTRIBUTES_MODULE_DEFAULT_SWITCH', $products_options_names->fields, $options_name, $options_menu, $options_comment, $options_comment_position, $options_html_id);
break;
//-eof-attribute_image_swatch-lat9 *** 4 of 4 ***
/YOUR_ADMIN/options_values_manager.phpCode:case 'delete_attribute':
// demo active test
if (zen_admin_demo()) {
$_GET['action']= '';
$messageStack->add_session(ERROR_ADMIN_DEMO, 'caution');
zen_redirect(zen_href_link(FILENAME_ATTRIBUTES_CONTROLLER, $_SESSION['page_info'] . '¤t_category_id=' . $_POST['current_category_id']));
}
if (isset($_POST['delete_attribute_id']))
{
$attribute_id = zen_db_prepare_input($_POST['delete_attribute_id']);
//-bof-options_stock-lat9 *** 1 of 3 ***
$zco_notifier->notify ('NOTIFY_ATTRIBUTE_CONTROLLER_DELETE_ATTRIBUTE', array ( 'attribute_id' => $attribute_id));
//-eof-options_stock-lat9 *** 1 of 3 ***
$db->Execute("delete from " . TABLE_PRODUCTS_ATTRIBUTES . "
where products_attributes_id = '" . (int)$attribute_id . "'");
// added for DOWNLOAD_ENABLED. Always try to remove attributes, even if downloads are no longer enabled
$db->Execute("delete from " . TABLE_PRODUCTS_ATTRIBUTES_DOWNLOAD . "
where products_attributes_id = '" . (int)$attribute_id . "'");
// reset products_price_sorter for searches etc.
zen_update_products_price_sorter($products_filter);
zen_redirect(zen_href_link(FILENAME_ATTRIBUTES_CONTROLLER, $_SESSION['page_info'] . '¤t_category_id=' . $_POST['current_category_id']));
}
break;
// delete all attributes
case 'delete_all_attributes':
//-bof-options_stock-lat9 *** 2 of 3 ***
$zco_notifier->notify ('NOTIFY_ATTRIBUTE_CONTROLLER_DELETE_ALL', array ( 'pID' => $_POST['products_filter']));
//-eof-options_stock-lat9 *** 2 of 3 ***
zen_delete_products_attributes($_POST['products_filter']);
$messageStack->add_session(SUCCESS_ATTRIBUTES_DELETED . ' ID#' . $products_filter, 'success');
$action='';
$products_filter = (int)$_POST['products_filter'];
// reset products_price_sorter for searches etc.
zen_update_products_price_sorter($products_filter);
zen_redirect(zen_href_link(FILENAME_ATTRIBUTES_CONTROLLER, 'products_filter=' . $products_filter . '¤t_category_id=' . $_POST['current_category_id']));
break;
case 'delete_option_name_values':
//-bof-options_stock-lat9 *** 3 of 3 ***
$zco_notifier->notify ('NOTIFY_ATTRIBUTE_CONTROLLER_DELETE_OPTION_NAME_VALUES', array ( 'pID' => $_POST['products_filter'], 'options_id' => $_POST['products_options_id_all'] ));
//-eof-options_stock-lat9 *** 3 of 3 ***
$delete_attributes_options_id = $db->Execute("select * from " . TABLE_PRODUCTS_ATTRIBUTES . " where products_id='" . $_POST['products_filter'] . "' and options_id='" . $_POST['products_options_id_all'] . "'");
while (!$delete_attributes_options_id->EOF) {
// remove any attached downloads
$remove_downloads = $db->Execute("delete from " . TABLE_PRODUCTS_ATTRIBUTES_DOWNLOAD . " where products_attributes_id= '" . $delete_attributes_options_id->fields['products_attributes_id'] . "'");
// remove all option values
/YOUR_ADMIN/includes/classes/order.phpCode:case 'delete_value':
// demo active test
if (zen_admin_demo()) {
$_GET['action']= '';
$messageStack->add_session(ERROR_ADMIN_DEMO, 'caution');
zen_redirect(zen_href_link(FILENAME_OPTIONS_VALUES_MANAGER, $_SESSION['page_info']));
}
$value_id = zen_db_prepare_input($_GET['value_id']);
//-bof-options_stock-lat9 *** 1 of 1 ***
$zco_notifier->notify ('OPTIONS_VALUES_MANAGER_DELETE_VALUE', array ( 'value_id' => $value_id ));
//-eof-options_stock-lat9 *** 1 of 1 ***
and, at the very end of the file:Code:class order extends base { //-products_options_stock-lat9 (Added 'extends base') *** 1 of 2 ***
var $info, $totals, $products, $customer, $delivery;
Code:
//-bof-products_options_stock-lat9 *** 2 of 2 ***
$this->notify ('ORDER_QUERY_ADMIN_COMPLETE', array ('orders_id' => $order_id));
//-eof-products_options_stock-lat9 *** 2 of 2 ***
}
}
Bulletin-board notifier support. Needs a change to /includes/modules/pages/account_edit/header_php.php to be able to distinguish between an email-address check for the current customer vs. an overall check for the email address, changing:
toCode:// check external hook for duplicate email address, so we can reject the change if duplicates aren't allowed externally
// (the observers should set any messageStack output as needed)
$nick_error = false;
$zco_notifier->notify('NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL', $email_address, $nick_error);
Otherwise, a customer with a bulletin-board account can't change their password because the (unchanged) email address already associated with the nickname is going to come back as "already used".Code:// check external hook for duplicate email address, so we can reject the change if duplicates aren't allowed externally
// (the observers should set any messageStack output as needed)
$nick_error = false;
$zco_notifier->notify('NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL', $email_address, $nick_error, $nick);
These are all related to the font awesome stylesheet. See this:Quote:
Originally Posted by kobra
https://github.com/FortAwesome/Font-Awesome/issues/6489
Thanks,
Anne
There are also several "unknown vendor extension" errorsQuote:
Originally Posted by picaflor-azul
OK, I obviously needed some more coffee before I wrote that. The existing code-block reads:Quote:
Originally Posted by lat9
and the highlighted lines need to be removed. Note that the $nick input still needs to be sent on the first notifier!Code:// check external hook for duplicate email address, so we can reject the change if duplicates aren't allowed externally
// (the observers should set any messageStack output as needed)
$nick_error = false;
$zco_notifier->notify('NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL', $email_address, $nick_error);
if ($nick_error) $error = true;
$zco_notifier->notify('NOTIFY_NICK_CHECK_FOR_DUPLICATE', $nick, $nick_error);
if ($nick_error) $error = true;
These will show as errors or warnings depending on how you have the validator settings. It is true that vendor-specific extensions are invalid CSS. They help support browser compatibility. The vendor extensions are proprietary code and will always be invalid. Is there a way to make them validate?Quote:
Originally Posted by kobra
http://stackoverflow.com/questions/1...webkit-and-moz
Thanks,
Anne
lolQuote:
Originally Posted by lat9
A few questions ...
1. Is there a reason why you want to add NOTIFY_ORDER_CREATE_ADD_PRODUCTS_BEGIN when NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_INIT already provides that info?
2. What's the purpose of the duplication provided by NOTIFY_ORDER_INVOICE_CONTENT_READY_TO_SEND2?
3 ... more after I review the attributes proposals
See replies embedded above.Quote:
Originally Posted by DrByte
What about the create_account.php file too?Quote:
Originally Posted by lat9
Any objection to us just fixing that?Quote:
Originally Posted by lat9
Er, um, in v1.5.5 it does already allow changing them.Quote:
Originally Posted by lat9
Nope, in the create-account process you want to ensure that the nickname chosen is unique; in the account-edit process, the nickname's already chosen (and not modifiable).Quote:
Originally Posted by DrByte
Where's that coffee ... you're correct, of course. I'll be making some changes in my plugins.Quote:
Originally Posted by DrByte
Can you talk a bit about the sort of testing you've done, and logic considered, to ensure there are no ill side-effects of changing this default?Quote:
Originally Posted by lat9
I know Ajeh's probably grinding fingernails on the blackboard trying to anticipate potential problems with this...
The reason that I'd created another notifier to add those fields (that it turns out isn't needed!) is that I didn't want to introduce version-specific notifiers! The last thing that I, as a plugin developer, want is to have to know which version of Zen Cart is being used for my plugin to determine how to handle a specific notifier.Quote:
Originally Posted by DrByte
Yes, I fully appreciate that challenge. But it's a necessary evil. We do try to defer "big" changes to "big" versions, but I'm a believer in progressive change especially since some people delay upgrading terribly long but try to use new plugins against old code so having new hooks or improvements integrated sooner than later tends to be better. Fortunately there are a few ways to handle version control, including just testing whether a certain thing has been passed or not, etc.Quote:
Originally Posted by lat9
Okay. I'm staging these changes here: https://github.com/zencart/zencart/pull/733Quote:
Originally Posted by lat9
Those notifiers are (as the comments imply) used by one of my commercial plugins. That plugin adds a brand-new option type and the majority of the notifiers in the attributes.php file allow the plugin to deal with this.Quote:
Originally Posted by DrByte
The one thing that I did run into when changing the default processing was the "configuration_group 0" mis-handling (i.e. when configuration_group_id=0 gets wiped from the configuration table by improperly-coded SQL install scripts). The change in Zen Cart v1.5.4 (I think) where those configuration items are now moved to configuration group 6 (modules) corrected that issue (which is also included as part of that plugin's distribution).
Submit buttons readiness for cssButtons
If this has not already been done, can we have class="button" OR class="submitButton" AND/OR (perhaps) id="submit_Button" OR id="submit_Button" uniformly inserted within all <input type="submit"...> for cssButton readiness.
includes/modules/pages/checkout_success/header_php.php // class="submitButton" and id="submitbutton"
includes/modules/pages/payer_auth_auth/header_php.php
includes/modules/pages/payer_auth_verifier/header_php.php
includes/modules/payment/authorizenet/authorizenet_admin_notification.php
includes/templates/template_default/sideboxes/tpl_search.php
includes/templates/template_default/sideboxes/tpl_search_header.php
admin/banner_statistics.php
admin/categories.php
admin/coupon_restrict.php
admin/developers_tool_kit.php
admin/document_general.php
admin/document_product.php
admin/includes/modules/newsletters/product_notification.php
admin/login.php // class="button" and id="btn_submit"
admin/media_manager.php
admin/option_name.php
admin/option_values.php
admin/password_forgotten.php // class="button"
admin/product.php
admin/product_free_shipping.php
admin/product_music.php
admin/products_to_categories.php
Thanks in advance.
But as a header_php.php file, doesn't it actually have direct access to $nick by declaring the variable as global within the observer making the passing of the value(s) unnecessary? This way the observer knows the value of $nick and any change will be available to follow after the notify was executed.Quote:
Originally Posted by lat9
I mean I guess yeah the value could be passed to the observer, but it seems excessive unless there is some plan to modify the observer class operation to restrict it's access to only information specifically fed to it. Though the extra "hint" about what data should be handled does help those that seek to design further...
Quote:
Originally Posted by lat9
I try to do a mix of both, though I could imagine with a sufficient quantity of plugins and enough versions of ZC it will/can get to a point of too much.. Really can make a simple action take up a lot of code space covering for pre 1.5.3 versions where the observer class is limited to just the array of immutable data passed by the notifier and there is a need to change something that is to follow... (Meaning, very thankful for the added features of the observer class at least providing the 9 additional modifiable variables, though haven't considered packaging that up to use on older ZC versions.. Mostly for some of what is described above, want updating to continue to occur for safety/security.)Quote:
Originally Posted by DrByte
I had been considering adding these notifiers into an attributes.php modifying file, but also was somewhat wondering about the rework of the case... Why not at the current default insert a begin and end notifier allowing the observer code to either take action or let the default code do its part. That way don't run into the issue that lat9 identified regarding the value of 0 problemQuote:
Originally Posted by DrByte
Code:
case default:
$zco_notifier->notify('NOTIFY_ATTRIBUTES_MODULE_DEFAULT_SWITCH_BEGIN', $products_options_names->fields, $options_name, $options_menu, $options_comment, $options_comment_position, $options_html_id);
default code to occur...
$zco_notifier->notify('NOTIFY_ATTRIBUTES_MODULE_DEFAULT_SWITCH_END', $products_options_names->fields, $options_name, $options_menu, $options_comment, $options_comment_position, $options_html_id);
While we're on the notifier request path:
includes/templates/templates_default/common/tpl_footer.php
at the end add:
or add some form of notifier into includes/templates/templates_default/common/tpl_main_page.php that would activate on each and every page load preferably towards the start of the page?Code:$zco_notifier->notify('NOTIFY_FOOTER_END');
Plugin User Tracking adds the above notifier, but of course being in the footer, if anything prevents the footer from being processed (intentionally or not) then it doesn't get activated. Headers have notifiers, but newly created pages would be missed as the specific notify must be identified and if not mistaken it is not possible to use some form of pattern match to which to attach, therefore would have to initially identify all existing header notifiers, then users would have to 1) validate that they update the particular header notifier when they copy/create a new page and 2) add the particular notifier to the list of headers to which to observe...
includes/modules/pages/checkout_success/header_php.php
suggest modifying line 99 (99-104 shown below):
Code:$products_query = "SELECT products_id, products_name
FROM " . TABLE_ORDERS_PRODUCTS . "
WHERE orders_id = :ordersID
ORDER BY products_name";
$products_query = $db->bindVars($products_query, ':ordersID', $orders_id, 'integer');
$products = $db->Execute($products_query);
Prevents repetitive display of the product name in an order that has the same products_id multiple times.Code:$products_query = "SELECT DISTINCT products_id, products_name
FROM " . TABLE_ORDERS_PRODUCTS . "
WHERE orders_id = :ordersID
ORDER BY products_name";
$products_query = $db->bindVars($products_query, ':ordersID', $orders_id, 'integer');
$products = $db->Execute($products_query);
admin/options_name_manager.php
Under update_options_valuesCode:case 'delete_option':
// demo active test
if (zen_admin_demo()) {
$_GET['action']= '';
$messageStack->add_session(ERROR_ADMIN_DEMO, 'caution');
zen_redirect(zen_href_link(FILENAME_OPTIONS_NAME_MANAGER, $_SESSION['page_info'] . '&option_order_by=' . $option_order_by));
}
$option_id = zen_db_prepare_input($_GET['option_id']);
$remove_option_values = $db->Execute("select products_options_id, products_options_values_id from " . TABLE_PRODUCTS_OPTIONS_VALUES_TO_PRODUCTS_OPTIONS . " where products_options_id='" . (int)$option_id . "'");
while (!$remove_option_values->EOF) {
$zco_notifier->notify ('OPTIONS_NAME_MANAGER_DELETE_OPTION', array ('option_id' => $option_id, 'options_values_id' => (int)$remove_option_values->fields['products_options_values_id'] ));
$db->Execute("delete from " . TABLE_PRODUCTS_OPTIONS_VALUES . " where products_options_values_id='" . (int)$remove_option_values->fields['products_options_values_id'] . "' and products_options_values_id !=0");
$remove_option_values->MoveNext();
}
Totally open to the naming of the above and combination of data to be provided. Anything that would provide at least that amount of information would better than nothing.Code:} else {
// action delete
while (!$all_update_products->EOF) {
// get all option_values
$all_options_values = $db->Execute("select products_options_id, products_options_values_id from " . TABLE_PRODUCTS_OPTIONS_VALUES_TO_PRODUCTS_OPTIONS . " where products_options_id='" . (int)$_POST['options_id'] . "'");
$updated = 'false';
while (!$all_options_values->EOF) {
$check_all_options_values = $db->Execute("select products_attributes_id from " . TABLE_PRODUCTS_ATTRIBUTES . " where products_id='" . (int)$all_update_products->fields['products_id'] . "' and options_id='" . (int)$all_options_values->fields['products_options_id'] . "' and options_values_id='" . (int)$all_options_values->fields['products_options_values_id'] . "'");
if ($check_all_options_values->RecordCount() >= 1) {
// delete for this product with Option Name options_value_id
// echo '<br>This should be deleted: ' . zen_get_products_name($all_options_values->fields['products_options_id']);
// change to delete
// should add download delete
$db->Execute("delete from " . TABLE_PRODUCTS_ATTRIBUTES . " where products_id='" . (int)$all_update_products->fields['products_id'] . "' and options_id='" . (int)$_POST['options_id'] . "'");
$zco_notifier->notify('OPTIONS_NAME_MANAGER_UPDATE_OPTIONS_VALUES_DELETE', array('products_id'=>$all_update_products->fields['products_id'], 'options_id'=>$all_options_values->fields['products_options_id'], 'options_values_id'=>$all_options_values->fields['products_options_values_id']));
} else {
Thank you for the notifier updates that I'd requested in post #205. There were, unfortunately, two that didn't (yet?) make it to /includes/modules/attributes.php:
Code:$tmp_attributes_image = '';
$tmp_attributes_image_row = 0;
$show_attributes_qty_prices_icon = 'false';
//-bof-attribute_image_swatch-lat9 *** 1 of 4 ***
$zco_notifier->notify('NOTIFY_ATTRIBUTES_MODULE_START_OPTION', $products_options_names->fields);
//-eof-attribute_image_swatch-lat9 *** 1 of 4 ***
while (!$products_options->EOF) {
// reset
$products_options_display_price='';
$new_attributes_price= '';
$price_onetime = '';
$products_options_array[] = array('id' => $products_options->fields['products_options_values_id'],
'text' => $products_options->fields['products_options_values_name']);
//-bof-posm_price_weight-lat9 *** 1 of 1 ***
$zco_notifier->notify ('NOTIFY_ATTRIBUTES_MODULE_START_OPTIONS_LOOP', array (), $products_options->fields);
//-eof-posm_price_weight-lat9 *** 1 of 1 ***
Quick Question having not used ZC for a few years but about to set up a site for someone.
Looking at the code for 1.5.5 on Github, I note that we still have the countries and zones set up for a few selected countries during the installation process. Is there still scope to submit something that provides this for the other missing countries/territories before release?
This will obviously leave those already in place alone and just add the other countries so that people can select as required when installing?
I would use this as a source: http://download.geonames.org/export/...CodesASCII.txt and just update the SQL queries.
I have a separate question about the proposed use of Foundation for 1.6.0 but will try to figure out where to ask that.
Hi.
While it would be wonderful to have more country/zones available in the installer, we need to make sure that the information we are using is correct.
For example, I'm from the UK, and looking at the information in the link you sent
http://download.geonames.org/export/...CodesASCII.txt
The information for the UK is wrong. It only splits the UK into four zones,
e.g.
whereas the UK has many more counties/zonesCode:GB.WLS Wales Wales 2634895
GB.SCT Scotland Scotland 2638360
GB.NIR Northern Ireland Northern Ireland 2641364
GB.ENG England England 6269131
see https://www.zen-cart.com/downloads.php?do=file&id=818
Quote:
Originally Posted by Dayo
Not opposed to them. How are you using them?Quote:
Originally Posted by mc12345678
Snap. Saw those and got distracted by something shiny probably :wow:Quote:
Originally Posted by lat9
Hi Wilt,
The UK is a special case as the Home Countries listed are indeed the next step down from the Union and other countries do not have that set up.
So, for the UK, the local counties would be listed instead of the Home Countries ... or just leave out the UK and let people use the list you linked for instance.
Whichever the case, this is a one off, UK specific, quirk which can be managed ... just like no other country has constituent parts represented in FIFA for instance.
I just looked at the geonames.org list you linked to and noticed that most non-US countries in that list have "numbers" for their representative province/state/regions, instead of the official 2-char ISO codes for those said divisions. Do they have another list that uses the actual ISO zone codes?Quote:
Originally Posted by Dayo
Why would a PHP-driven user-tracking plugin need to fire a notifier at the template level? If the plugin is firing off some PHP code, then it could be triggered earlier and then there's no need to fire it at the end of template output generation. Now, if its sole purpose is to output some javascript then that's another issue.Quote:
Originally Posted by mc12345678
Hi
Will be done soon
https://github.com/zencart/zencart/pull/738
Thanks for the fix.
Quote:
Originally Posted by mc12345678
I don't believe there is a full set of official 2 digit ISO codes for every second level national subdivision in the world and outside the US, would be meaningless to most anyway. There isn't some 2 digit representation for Somerset or Newcastle in the UK for instance. Just doesn't exist. (There is a an obscure code for the two: GB-SOM/GB-NET) but I am sure Wilt, from Newcastle in the UK, probably never came across "GB-NET" before.Quote:
Originally Posted by DrByte
Basically, the abbreviations for the second tier subdivisions are not generally not significant outside the US and can be left blank in the database for most countries. Other Countries such as Australia which I believe do have some widespread use of 3 digit abbreviations for the subdivisions are probably already covered.
So my suggestion is to compile the list, exclude the countries already covered in the installation DB and leave the abbreviations empty for the new ones added.
To clean up other database data that was added related to the option values no longer existing. Hadn't previously used a notifier, but having one would remove the need to touch those files when combined with the ones lat9 suggested earlier...Quote:
Originally Posted by DrByte
Specific use/code that would be moved to an observer can be found in the SBA plugin currently at http://www.gthub.com/mc12345678/Stoc...butes_Combined
In the respective ZC version's admin directory.
Umm, early like first use of notifiers/observers and keeping the trigger point as it was by previous developers? :)Quote:
Originally Posted by DrByte
Okay, will look at a "sounder" trigger point for future revision as there is nothing external (template related)provided by the plugin, just picks up information. Thanks for the "code check".
Hi.
I don't want us to get fixated on ISO codes for zones, as you say there isn't anything official.
I guess my point is that the list you provided does not provide a proper list of county/zones for UK/GB
And if it doesn't do it for UK, can we trust it for other countries?
I don't want to discourage you, as what you are proposing is a good idea and really useful.
Maybe it's worth looking at what contributions we already have, that add country/zones, and think about updating those and adding them to core.
Quote:
Originally Posted by Dayo
Difference of opinion as the list does identify the UK's Second Level Subdivisions, which are the Home Nations, correctly.Quote:
Originally Posted by wilt
That the UK has a quirky set up where the second level (Home Nations) are not critical in some instances and the subdivisions of those (Counties) are instead, is a separate matter.
Anyway, if there is still time before release, I can put together an update to the SQL. I suppose that with all the recent additions from this thread, there must be significant pre-release testing to be re-done.
Are you proposing just an updated set of countries only?Quote:
Originally Posted by Dayo
Or also more granularly adding "all zones" for all countries in the world?
I think what wilt's saying is he doesn't trust the source you quoted as being reliable for "all zones in all countries".
Yeah, I got Wilt's point but my response was that this was not really valid as the list does correctly identify the UK's second level subdivisions (England, Scotland, Wales and Northern Ireland). That these are not what would be key in UK addresses is a separate and unique issue to the UK.Quote:
Originally Posted by DrByte
My intention was simply to granularly adding "all zones" for all countries in the world as already identified in the ZC setup. From your query about the updated set of countries, is it the case that the ZC list of countries/territories might need an update? Even if this was the case, I would think it would be best to maintain what is there already and leave such an update for a bigger dot point update.
That is, if a territory is one the zones list but not in the ZC list (New Territories), I'll leave it out and do the same for any in the ZC list but not in that list (Defunct Territories).
Alternative, is simply to supply the zones for Bahrain where I live and the nearby UAE although I think the "Full" proposal should be done and happy to do it if acceptable.
In my opinion it is of no use to add every zone of every country. For a lot of countries the zones are never used for shipping. Like in the Netherlands we only use the zip code, not the zone. I think it is better to add zones only when needed. This will prevent the database from becoming bloated.Quote:
Originally Posted by Dayo
I'd recommend submitting 2 Pull Requests: one for Bahrain and UAE, and another with all the other updates you're proposing.Quote:
Originally Posted by Dayo
Either way, we'd have to review both before merging. And things that are smaller are definitely easier to review and do any corresponding additional research necessary.
While I realize you trust the single data source you quoted, it seems apparent to me that wilt doesn't trust it as its treatment of UK data is clinical and not practical (ie: while the 4 UK-related zones it contains are indeed accurate, they're not at all what anyone living in the UK actually uses day-to-day in relation to commerce or shipping).
Multiple data sources confirming the same information certainly help qualify validity of any proposal.
Please understand, that when something gets merged into core there is automatically a community-wide assumption that the core developers are assuming responsibility to maintain that information to be completely accurate for all future perpetuity ... and, while that's an unrealistic assumption it's still nonetheless part of the pressure considered when reviewing proposed changes. So, if a proposed change contains multiple verifiable sources that can be used for occasional future checking, it's more likely that we'll be willing to accept the proposal. Basically I'm talking about maintainability here.
That said, I'm glad you're offering to contribute. Many many thanks!
But my point is valid. The second level entries in the list you provided are things that would never be used as a set of UK zones.
My point is, if the UK zones can't be trusted, why should I trust anything else.
That said.
If you have specific local experience for say Bahrain/UAE then sure, post details for this.
Quote:
Originally Posted by Dayo
... or ... a squirrel! I don't see the changes in the GitHub repository, yet; will look again in the morning.Quote:
Originally Posted by DrByte
True that Post/Zip codes are unique identifiers and so, for countries that use them, you don't really need the zone for shipping. However, there can be tax and other things tied to zones.Quote:
Originally Posted by Design75
Anyway, was just a thought. Would probably just do it for personal use.
Seems best to let things be ... especially since no one is complaining about missing zones.Quote:
Originally Posted by DrByte
They've just been merged :)Quote:
Originally Posted by lat9
Quote:
Originally Posted by Dayo
Fair enough. Still, thanks for engaging in the discussion and offering to contribute.Quote:
Originally Posted by Dayo
Perhaps preparing a plugin/addon that contains your proposed updates would be another option ... and we could get some community feedback, a crowd-sourced testing of sorts?
Wherever zen_image_submit() is used, the CSS Buttons logic will output appropriate classes for that purpose. Catalog-side that's pretty much universal. Admin-side will get it with upcoming revisions.Quote:
Originally Posted by dw08gm
Was tryng to work on something related to attributes being displayed in the proper sequence and came across something I thought may be mysql server dependent, but on further testing does not appear to be so simple of a .
Discovery was in includes/modules/attributes.php and may be an issue in other files if in the same format.
When the sort order for option names is identified in product info as by sort order followed by name, then in the file, the sort order becomes: order by LPAD(popt.products_options_sort_order,11,"0")
But, when this is run perhaps the first time, then the data is presented as desired in sort order followed by option name order, but if that page is reloaded or the query performed again then the sort order is lost to return to being in the order of the options_id.. I thought that I had posted about this once before a long while back, and maybe the "solution" still stands that nothing need be done, but I thought I would bring it to light again.
This is fine if a sort order is applied to the option name, but when the sort order is 0 for all option names (or the same) the result is by option name id not by option name.
I then went to phpmyadmin and entered the exact query as created for the Execute, and got the same result, but the query was also slightly modified to add a space after each piece of information in the LPAD statement. When I then refed that query in, the result came back correctly sequenced (the first time)...
When I then went back to the attributes.php file and added the same space after each comma, then the attributes were presented in the correct sequence once correctly and then subsequent tries while on the same page were again presented incorrectly...
So yes it seems odd that it sorts properly one time but then subsequently incorrectly, but also the statement in admin is to sort by sort order and option name or to sort by option name. The sort provided to the query though only enforces either sort order or option name not both.
So my recommendation after all this is to change the LPAD statement here (and in other places entered the same) to be like:
Server OS: Linux 3.2.61-grsec-modsignCode:if (PRODUCTS_OPTIONS_SORT_ORDER == '0') {
$options_order_by= ' order by LPAD(popt.products_options_sort_order, 11, "0"), popt.products_options_name';
} else {
$options_order_by= ' order by popt.products_options_name';
}
Database: MySQL 5.6.25-log
HTTP Server: Apache
PHP Version: 5.6.10 (Zend: 2.6.0)
PHP Memory Limit: 128M
PHP File Uploads: On
Max Size: 20M
PHP Safe Mode: Off
POST Max Size: 20M
Let me know if there is any specific or other data needed to reproduce this issue...
Even after accessing tools->Store Manager->Update All Products' Attribute Sort Orders
to match Option Value Default Sort Orders, the data still appears not in the sequence described by the admin option for sorting option names... Evidence also seen in the attributes controller.. Looks like either the admin description is incorrect, or the code at some point along the way is missing something to provide the response described... I found several other locations where the sort order of option_names was generated the same as provided in includes/modules/attributes.php Would be nice to have the full functionality described by adding the sort of products_options_name instead of removing the text of the option selection. :/
Uh-oh! The admin-level configure.php file for ZC1.5.5 was reworked to discontinue the use of the ENABLE_SSL_ADMIN setting -- unfortunately, no one told
- admin/includes/functions/html_output.php (lines 21 and 44)
- admin/includes/init_includes/init_general_funcs.php (line 59)
- admin/includes/init_includes/init_sessions.php (line 23)
EDITED BY AJEH:
also referenced: /includes/functions/html_output.php
In the interim, the defined_paths.php file defines HTTPS_SERVER so as to minimize the need to hack out a bunch of code. We've deferred the bigger change to v160 where lots of improvements are made to how those defines are used.Quote:
Originally Posted by lat9
Small suggestion: admin/customers.php lines 1245, 1265 - "pwreset" should be "pwdreset" to match "pwdresetconfirm" and TEXT_PWDRESET_INTRO (line 306 and 1247-1248).
Hi Finally had a bit of time to start looking at the new version. Sorry if any of these are duplicated I have tried to read through the previous messages.
On a brand new install I have a few issues/ suggestions
1) "Main /includes/configure.php file does not exist (isn't readable) or is not writeable" error is clickable but no extra help provided. Same for admin (do you want empty files in place?)
2) if you copy over the config template file from zc_install errormessage appears "Probems with database connection based on the entries in your current configure.php
2005:Unknown MySQL server host '%%_DB_SERVER_%%' (2)" this links to itself again.
3)Database setup. Should you add note to this page to say that you need to create a database before completing the fields. (I know that you should know this but is it better to cover all bases). the errormessage if you don't is "There are some problems. Problems with Database Connection 1049:Unknown database 'zencart'.
Also you recommend not using root but do not test for its use.
Hope this is useful if duplicated please ignore.
Thanks!Quote:
Originally Posted by brittainmark
Will look into the help text for that.Quote:
Originally Posted by brittainmark
The correct "source" to copy from is the /includes/dist-configure.php file ... which is why it's in that folder.Quote:
Originally Posted by brittainmark
Will mention that further in the help text.
Good point.Quote:
Originally Posted by brittainmark
These are all mentioned in the /docs/Implementation_Guide-v155.pdf file, but we all know nobody reads written docs despite the time it takes to write them. The on-screen help text can use some updates. Thanks for pointing these out!
Correct. On live production sites, root should not be used. But on offline localhost dev sites sometimes it's quite desirable, hence we're not preventing that.Quote:
Originally Posted by brittainmark
Thanks! That would be a pain otherwise.Quote:
Originally Posted by DrByte
I kinda see the discussion of silence about using root at that point as a request to have something additional stated... Not to prevent. Either a confirmation that root should really be used and all the blah blah of doing so on a production server versus development or a simple display/further display/disclaimer about it before accepting. Neither is "fun" to have to incorporate into the code, but one more attempt to help the unknowing user at the onset.
LOL, I for one always read the docs of a new release. Imagine the outcry and complaints of many if the docs would be superficial or non-existent. Apart from a few improvements suggested in this thread the docs are well written. And those who won't read them only have themselves to blame if an installation stuffs up.Quote:
Originally Posted by DrByte
Just my 2 cents.
What you mean with "NOBODY READS DOCS"??? :shocking: I read them... That was the first thing I was looking for before installing and was :( when didn't see it included.Quote:
Originally Posted by DrByte
The docs are usually the last bit to be included but meanwhile they are available from https://www.zen-cart.com/docs/Quote:
Originally Posted by ideasgirl
As posted several pages back there is a set of docs available from github, but are not (at the moment) included in the download by clicking the zip button. Personally, I'd gone to look at them a few days ago, saw the "file(s)", but got distracted with other coding.Quote:
Originally Posted by frank18
Docs: https://www.zen-cart.com/docs/whatsnew_1.5.5.html
Part in bold below "looks" like should be 1.5.5, unless there is some sort of recursive loop I missed. :P
Quote:
Upgrade Instructions
This document only mentions the actual changes specific to v1.5.5 since v1.5.4.
From v1.5.4
Simple: if you are using v1.5.4 already and have not customized any of the files listed in the changed_files-v1-5-5.html document, then simply replace those files with the new files as listed.
If you HAVE customized or altered certain files, simply re-do your customizations in the new version of those particular files by making the same changes needed.
If you are using Addons/Plugins that have made alterations to those files, it is best to compare those changed files against the original Zen Cart files for the version those plugins were built for, and see what changes were there ... and then re-build those changes in the v1.5.4 file.
Must be really important/proud. :P
I know, work in progress and all, didn't remember seeing comment, so... :)
Same item/concept listed twice. Personally, glad the option is now there.Quote:
Added customer-password reset via Admin
...
...
customer password reset via Admin,
https://www.zen-cart.com/docs/whatsnew_1.5.5.html
Quote:
Originally Posted by frank18
Quote:
Originally Posted by ideasgirl
Hi all, Thanks for confirming that some folks do read the docs. It's insane how many hours go into writing documentation that then I have to go and just repeat to people again on the forum because they couldn't be bothered to read. Finalizing a release can sometimes take longer than all the development and testing leading up to the release!Quote:
Originally Posted by mc12345678
Haha... Just too many sets of details from the roadmap, trying to merge everything together with tired eyes.Quote:
Originally Posted by mc12345678
http://www.zen-cart.com/content.php?...ecommendations
This may be preemptive as haven't done the after install comparison with this version, but with ZC 1.5.4 there were changes made making the below statement inaccurate for the zc_install directory as (at least as I found) a fresh zc_install directory was needed when trying to run it again on the same system.
Okay after writing the above paragraph, I at least went back to compare the installation files that I used for the first (recent) install of ZC 1.5.5 and this go round it appears that the zc_install files remain intact and unaltered, so I now agree with the below regarding the zc_install folder being able to be downloaded and reused to upload again. Not so much for ZC 1.5.4, but okay for ZC 1.5.5 (unless other changes happen "soon"). Leaving the above just for consideration because of previous/recent "other" version operation.
Same "file" as above I think one line is all that is necessary:Quote:
REMOVE THE FOLLOWING FOLDERS (and all the files inside them), TO MINIMIZE SECURITY RISKS:
- /docs
- /extras
- /zc_install
- /install.txt (this file can be removed, too)
It is safe to keep these files on your own computer, since they can be used as references/documentation, or used to aid in troubleshooting as diagnostic tools, or for upgrading/installing again in the future. But those folders/files should *not* be on a live webserver.
As posted about earlier by a few, this action is automatically taken as part of a new install... Haven't reviewed/performed an upgrade yet to ZC 1.5.5, especially as the rename admin folder "might" apply to an upgrade from a super older version or something but I'm pulling at straws on that... Seems like this topic (admin rename) is covered from the perspective of this version so not sure how specific the docs are compared to the version or if they need to provide individual version specific information in this case. (For non-version specific instruction should there be something like: works like this in version X, but like this in version Y).Quote:
Rename your /admin folder
Hello,
I see that in https://www.zen-cart.com/docs/whatsnew_1.5.5.html, it says that "Zen CartŪ v1.5.5 is compatible with PHP 5.3.7 through PHP 7.0, and MySQL 5.1 thru 5.7" but I seemed to notice from skimming the Github commits that changes were made recently to allow PHP 5.2.9 support.
I don't think that the following block of code from /includes/templates/responsive_default/common/html_header.php will produce the results expected if the Mobile_Detect class is previously defined:
Shouldn't it be:Code:if (!class_exists('Mobile_Detect')) {
include_once(DIR_WS_CLASSES . 'Mobile_Detect.php');
$detect = new Mobile_Detect;
$isMobile = (isset($detect) && $detect->isMobile() && !$detect->isTablet() || $_SESSION['layoutType'] == 'mobile');
if (!defined('MAX_DISPLAY_PAGE_LINKS_MOBILE')) define('MAX_DISPLAY_PAGE_LINKS_MOBILE', 3);
}
Code:if (!class_exists('Mobile_Detect')) {
include_once(DIR_WS_CLASSES . 'Mobile_Detect.php');
}
$detect = new Mobile_Detect;
$isMobile = (isset($detect) && $detect->isMobile() && !$detect->isTablet() || $_SESSION['layoutType'] == 'mobile');
if (!defined('MAX_DISPLAY_PAGE_LINKS_MOBILE')) define('MAX_DISPLAY_PAGE_LINKS_MOBILE', 3);
Acknowledged.Quote:
Originally Posted by Dayo
While the majority of v155 will work on PHP 5.2, it's not a supported environment ... ie: we don't intend to even try to support PHP 5.2 (which ended on 6 Jan 2011) in ZC v1.5.5.
In fact, someone using a modern server should be using PHP 5.6 or 7.x
Already today, PHP 5.5 is no longer actively being developed, and is in security-patches-only mode until July 2016 after which it will be obsolete.
Ref: http://php.net/supported-versions.php
It's with much hesitation that we even mention PHP 5.3 compatibility of any sort. If I had my way I'd say "only on 5.6 or newer". But, we do try hard to support as broad a platform as possible.
FYI ... we're exploring the pros/cons of doing a complete swap to HTML5
The challenge is weighing the value of throwing minor "w3c validator" warnings vs providing modern markup.
Modern browsers will not croak when encountering deprecated markup, but using unsupported HTML5 markup on XHTML/HTML4 is potentially more problematic (such as for people attempting to use templates built for older versions).
IMPORTANT NOTE: FOR v155, WE'RE MAINTAINING template_default AND CORE CODE IN A WAY THAT ALLOWS UPGRADERS TO UPGRADE THE SITE WITHOUT INSTALLING THE NEW responsive_classic TEMPLATE BUT STILL BENEFIT FROM AS MANY OF THE CHANGES AS POSSIBLE WITHOUT HAVING TO SIGNIFICANTLY TOUCH THEIR CURRENT TEMPLATE. The intention is to advise people to upgrade everything OTHER THAN changing templates (but still upgrade their own template using all changes made to template_default, as per a normal upgrade) ... but then separately decide whether they want to consider the new responsive_classic template.
My personal preference is to jump fully to HTML5. But I don't want to create a world of hurt for current users.
So, I'm throwing this out there for comments/feedback.
Why not just code using polyglot HTML?
This way the pages can be validated as HTML5 when served as text/html and as XHTML5 when served as application/xhtml+xml?
Just to clarify, I'm in favor of HTML5 versus XHTML 1.x. Personally I've only encountered a handful of sites serving content as application/xhtml+xml (with most using text/html). I prefer the HTML also being a well formed XML document (thus liking polyglot).
Perhaps for 1.5.5 maintain a "legacy_default" and "responsive_default" theme? Perhaps with a selector (or better yet an indicator for responsive required in "child" themes based on the "responsive_default")? Might help those needing to maintain an older theme until they can update / replace the older theme (to HTML5 + "responsive_default")... Just some thoughts (and apologies if this is already what is planned - I've not yet found time to look over 1.5.5 as much as I want).
First time to test this new one and decided to start with one of our dinosaurs at 1.3.9.
<opinion>Most of the world doesn't read centered text that well. Can't we make the default something else? </opinion>
First of all, my trifocals had problems with the Super Temp Password. Using 1, l, I, 0, and O are not always as legible as they are here on the forum. I finally gave up and started over. Granted I could have done a capture or copy but, I think the user will not stop to do so.
Next was the database upgrade. Since I have Navicat, it's easy to drop the new and bring in the old. Using zc_install, the upgrade went without incident until I got the green bar stating "Upgrade to version 1.5.3 completed". The next bar is red and states, "Could not update to version 1.5.4. We detect that you currently have 1.5.2, and must perform the updates to get to version 1.5.3 first."
Beneath that is the heading, "Please confirm your desired upgrade steps" followed by two entries both of which are checked. 1.5.3 to 1.5.4 and 1.5.4 to 1.5.5.
I understand the difference between passwords in versions 1.5.# And originally thought I would use the super user currently in a 1.5.4 site. That did not work. I then thought that the conflicting version statements might be the problem.
I went back to the site's install and went through the upgrade option once again.
This time, I'm told that the database is NOT at 1.53 and will need to go to 1.5.3, then 1.5.4, to 1.5.5. AND, nothing I do to change the User Name and Password will satisfy the Admin Credentials for upgrade. Not even the Admin admin suggested in the link for reset.
Odd part is that, using the user from a 1.5.4 site, I am able to access both the store and admin. The admin, of course, states that I should upgrade. BUT, the Tools menu, Server/Version Info states that I am sitting at Database Patch Level: 1.5.3
**************************************************
Server Information Server Host: host.mysite.com (***.***.***.***)
Server OS: Linux 2.6.32-504.3.3.el6.x86_64
Server Date: 01/07/2016 20:19:22
Server Up Time: 20:19:22 up 369 days, 8:30, 0 users, load average: 0.29, 0.14, 0.06
HTTP Server: Apache/2.4.10 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4 PHP/5.4.36
PHP Version: 5.4.36 (Zend: 2.4.0)
PHP File Uploads: On Upload Max Size:2M
PHP Memory Limit: 128M
POST Max Size: 8MDatabase: MySQL 5.5.47-cll
Database Host: mysite.com (***.***.***.***)
Database Date: 01/07/2016 20:19:22
Database Data Size: 13,371 kB
Database Index Size: 1,032 kB
MySQL Slow Query Log Status: On
MySQL Slow Query Log File: /var/lib/mysql/host-slow.log
MySQL Mode:
Greatly appreciating the feedback on upgrading.Quote:
Originally Posted by dbltoe
Will take a look. Admittedly we've been expecting people to copy+paste that password, not write it down anyplace, especially since it's only used once.Quote:
Originally Posted by dbltoe
Thanks. We'll look deeper into the logic which is detecting each version step. It can be quite challenging in some cases where there's virtually no schema changes between versions.Quote:
Originally Posted by dbltoe
Ok, first upgrade attempt.
Installed a vanilla 1.5.1 on my local LAMP dev server (OS Linux Mint 17.3).
Tested: ok
Then (using Beyond Compare) copied the latest ZC 1.5.5 BETA over to the 1.5.1 installation and deleted all old files. Renamed admin folder back to admin but left the 2 configure.php files read-only.
Then loaded http://192.168.0.20/onefivefiveupgradetest/zc_install (onefivefiveupgradetest is the installation folder)
and was told that there is an old configure.php which needs upgrading first.
Also had the alert that the 2 configure.php files are not writable (as expected), so I made them writable, reloaded and was given the choice to upgrade or do a clean install.
So far so good.
I chose UPGRADE and tick the upgrade steps (all), entered the admin credentials and proceeded.
Within a flash I was greeted with
So, did as told and removed the zc_install folder, then reloaded http://192.168.0.20/onefivefiveupgradetest/ - result ok.Quote:
Setup Finshed
Congratulations, your upgrade is now complete.
You need to remove the /zc_install/ folder so that someone can't re-install your shop again and wipe out your database! A message will appear and you will not be able to log into your admin until the folder has been removed.
Then loaded http://192.168.0.20/onefivefiveupgradetest/admin-test/ and got this:
Attachment 15941
The interesting bit is that the address jumps from http:// to https:// and I did not enable SSL during the installation or upgrade procedure. So naturally that screen must display (the server works as expected.....)
Renamed the admin folder again to something simpler and got the same screen.
So I searched the DB for 'SSL' and in the table configuration I found these entries:
configuration_key SSLPWSTATUSCHECK was set with configuration_title 'login mode https' - manually changed that to 'login mode http' and reloaded the admin: Bingo, the admin login page appears. Tried to log into admin and get the same screen as above. The address is again https:// ..... :huh:
Also noted that the admin folder was not automatically renamed as it happend during a fresh install.
So, it seems that there is still some work to be done to get an upgrade from a vanilla install working smoothly. I do understand that my scenario is not a typical scenario as most sites have been customized before upgrading. But it should work smoothly with an upgrade from a vanilla 1.5.1 installation - so me thinks.
Other than that last bit everything went smooth as - thumbs up!! :cheers:
So ... despite the absence of much feedback, changes to support HTML5 and fix (important) validation errors have now been built-in to the new responsive_classic template. So responsive_classic is HTML5 out-of-the-box.Quote:
Originally Posted by DrByte
Further, template_default also passes HTML5 validation (if the html_header is changed to output HTML5 headers).
The changes to template_default were basically just to move a lot of table-related markup into CSS. While template_default does still contain a "layout" table in tpl_main_page, for the most part the rest of template_default uses tables just for actual tabular data.
Nice move!!!!! I gave my thumbs up opinion for HTML5 a few pages back.. Glad that you guys made the move anyway.. I say that ANYPLACE ya'll can modernize is ALWAYS gonna be a good thing.. the key is that you are addressing the IMPORTANT validation errors.. EVERY validation error doesn't necessarily need to be run down.. The validator is supposed to be a GUIDELINE anyway not GOSPEL..Quote:
Originally Posted by DrByte
dbltoe, I've spent the better part of the day simulating upgrades of various combinations. Unfortunately I've not been able to trigger these same symptoms.Quote:
Originally Posted by dbltoe
But, in the interest of attempting to detect upgrade options more reliably, I've added some more inspection cases which may help the installer know better when it needs to do a particular step.
I've not been able to make the upgrader reject my password unless I actually go and mangle it in the db, even when testing by starting with various different older versions from real live site databases.
I may have to try to find a server running exactly PHP 5.4.36 and MySQL 5.5.47 to get a more exact simulation ... but I'm not optimistic about that.
Many thanks for testing this and giving your detailed feedback. Much appreciated!Quote:
Originally Posted by frank18
I'm curious why it switched to SSL.Quote:
Originally Posted by frank18
- What's your HTTP_SERVER setting in your admin configure.php?
- Did the installer incorrectly set that to an https URL?
When running zc_install, one of the first things it attempts to do is run itself over SSL if possible, by testing whether the https URL to your zc_install responds as valid, and then redirects to https. This allows for secure passing of all settings data on servers that support it.
But, if it can't run itself over https, it shouldn't force your Admin URL to be https ... unless you didn't see that it had put https in there for some reason.
Most of my test environments are using SSL now, especially since Let's Encrypt makes SSL free.
I just tested using the same steps as you outlined, and even tried a few different no-SSL-possible VMs of different configurations, and can't seem to trigger your symptoms.
One unique case you raise that I seldom test in is an IP-Address-only domain. There's been a long-standing issue with that, and I may have identified a solution. A pull-request is being submitted tonight, and will hopefully be merged tomorrow afternoon.
But, that situation wasn't related to "flipping your admin into SSL unexpectedly". ... that still feels more like the configure.php file got an https in it somehow.
That's a display-only "title", so editing it wouldn't solve the https redirect.Quote:
Originally Posted by frank18
That said, there was a separate bug related to that setting, which has been fixed in the latest code up on github.
Thanks DrByte.Quote:
Originally Posted by DrByte
LOL, me too.Quote:
Originally Posted by DrByte
After posting I checked the HTTP_SERVER setting and it was indeed set to
I changed that toCode:define('HTTP_SERVER', 'https://192.168.0.20');
define('HTTP_SERVER', 'http://192.168.0.20');
and (as expected) manged to get into the admin in a flash.
Why it configured itself to https I just don't know, that's the bit which puzzled me as I never enable SSL when I install a test or development version on my local server, be it for my own use or for the development of a client site.
BTW, since running this local dev server all my local sites had/have the setting
and I never had a problem with this. Goes back to 1.3.8a sites.Code:define('HTTP_SERVER', 'http://192.168.0.20');
BTW, is it intentional that the admin name does not automatically change from admin to something else during an upgrade? I was very pleased to see this happening during a fresh install, saves another step in setting up a new site.
Wasn't my intent to keep you from other endeavors. Won't be able to do a retry till Tuesday but, if you need it, I will gladly give you full access to the server/site. Easy to do as we are the host.Quote:
Originally Posted by DrByte
Note that PHP 5.4 is past end of life. http://php.net/supported-versions.php
Yes, during an upgrade it leaves the directory name alone.Quote:
Originally Posted by frank18
Question: Should the value of the default template change to responsive_classic after zc_install is run in upgrade mode?
(not sure if this would be more intuitive or not ... just an idea.)
OMG! Please, no!Quote:
Originally Posted by swguy
That would have many plugin-related implications, since the assumption made by plugins to-date is that any template-related changes are relative to good ol' classic-green.
Nope.Quote:
Originally Posted by swguy
Upgrades are independent of the template, and have no requirement to use the responsive_classic template at all.
(That said, just like in the past, alterations in template_default files should still be replicated into whatever template one is actually using, as part of the normal upgrade of PHP/CSS/JS files.)
Whats new in 1.5.5? Just a new responsive classic template or anything else as well? when is 1.6 coming, its been ages I am waiting for it!
Fully aware but, we do have customers that have been unable to upgrade for one reason or another. We are in the process of strongly suggesting they upgrade or move on. We will not be able to maintain their server at this level for much longer.Quote:
Originally Posted by swguy
MEANWHILE.... Back at the problems with the 1.3.9h to 1.5.5 upgrade...
When doing:
- complete new install of 1.5.5 zip using download from last night.
- new database populated by 1.5.5 install
- delete tables on new install
- import tables from old site
- run database upgrade using zc_install
- upgrade stops saying we are not at 1.5.3 and cannot upgrade to 1.5.4
- backing up to the zc_install directory and selecting database upgrade once again.
- Get Attachment 15947
- Go to admin and get Attachment 15948
- Look at database with Navicat and get Attachment 15949
Nothing we do can get us past this point.
For "What's New" see https://www.zen-cart.com/docs/whatsnew_1.5.5.htmlQuote:
Originally Posted by mani
ZC 1.6 will be coming when it's ready. The devs are working to release 1.5.5 in a week or 2.
ZC 1.5.5 is a stepping stone to ZC 1.6
There are 2 things at play here:Quote:
Originally Posted by dbltoe
- the actual SQL changes in the 152-to-153 upgrade .sql file .... vs what's actually/already in your database
- the "inspection" criteria in the zc_install/includes/systemChecks.yml file
For some reason the checks in the yml file are failing to confirm that the changes normally made in the db upgrade to 153 are actually in your db.
That could be because there's a SQL error happening when it tried to install them (your admin suggests that the 153 steps were done at least once, so we know that it at least ran that 153 sql file). Maybe there's something in the upgrade-exceptions table, or in your /logs/ folder?
Perhaps you had some of the v153 db changes already in your database but they've been altered slightly such that the inspection is failing? If this is the case, I'd be interested in knowing which those were, in case others are likely to have done those changes too for some reason, such as a plugin or otherwise ... so we can change which inspections are done, or at least "how" they're done.
The banner image size in the sidebox:
makes a small h-scroll under 1024px.Code:<img width="140" height="220" title=" eStart Your Web Store with Zen Cart(R) " alt="eStart Your Web Store with Zen Cart(R)" src="images/banners/tall-book.gif">
I know it will be changed, but I guess it gets the width and height from the image, and outputs it in the code, in which case it's not ideal.
Anyhow I tried changing the banner image and when updating the banner I got:
WARNING: An Error occurred, please refresh the page and try again.
Quote:
Originally Posted by keneso
Did you check your /logs folder for relevant entries?
This is only minor but still annoying and only really apparent if the breadcrumb panel is coloured other than white:
[15-Jan-2016 01:14:12 Europe/Rome] Request URI: /zen-155/aadmin/banner_manager.php?page=1&action=upd, IP address: ::1Quote:
Originally Posted by frank18
#1 trigger_error() called at [C:\...path-to...\zen-155\includes\classes\db\mysql\query_factory.php:167]
#2 queryFactory->show_error() called at [C:\...path-to...\zen-155\includes\classes\db\mysql\query_factory.php:139]
#3 queryFactory->set_error() called at [C:\...path-to...\zen-155\includes\classes\db\mysql\query_factory.php:266]
#4 queryFactory->Execute() called at [C:\...path-to...\zen-155\aadmin\banner_manager.php:143]
[15-Jan-2016 01:14:12 Europe/Rome] PHP Fatal error: 1292:Incorrect datetime value: 'null' :: UPDATE banners
SET
date_scheduled = DATE_ADD('null', INTERVAL '00:00:00' HOUR_SECOND),
expires_date = DATE_ADD('null', INTERVAL '23:59:59' HOUR_SECOND),
expires_impressions = null
WHERE banners_id = 8 ==> (as called by) C:\...path-to...\zen-155\aadmin\banner_manager.php on line 143 <== in C:\...path-to...\zen-155\includes\classes\db\mysql\query_factory.php on line 167
Remove the margin-top from the .naNextPrevWrapperQuote:
Originally Posted by lucidlee
Thanks,
Anne
What PHP and MySQL versions are you using on that Windows computer?Quote:
Originally Posted by keneso