[Closed] FEEDBACK ON BETA of v1.5.5

stellarweb:

The issue below in quotes is still present with latest version tested today, vanilla DB, no mods, no demo products installed.

After adding a Text option Name.... then clicking Attribute Controller or going to product list and clicking the "A" by the product
goes to /options_values_manager.php
Warning: No Option Values have been defined
https://github.com/zencart/zencart/pull/799 has now been merged, which should address this.

torvista:

admin_page_registration
id missing. I added it a long time ago, can't remember why...maybe just because all the others have one!
Fixed .

Works perfectly!!

DrByte:

https://github.com/zencart/zencart/pull/799 has now been merged, which should address this.

Hi Guys,

Not sure if it a bug or if it's the way the category editor, product editor and page editor is meant to behave in the new version but I thought I'd mention it. The eror happen with the text in the files or when adding your own content with HTML tags and as plain text with paragraphs.

Better safe then sorry huh? :)

This is a straight out of the zip installation and setup, with no edits, no mods, and no addons installed.

Formatting of text via the Define Pages Editor function

EG: Open the Shipping file vis the Define Pages Editor function in tools ... the text looks like normal.

When it is saved

All the HTML tags are converted and display on the shipping page:

The tags have been converted to:

And when it is formatted in plain text with paragraphs like:

Shipping Information

We haven't updated this page yet. Please use the Contact Us form to let us know!

The page text looks like one long paragraph:

Conditions of Use Sample Text We haven't updated this page yet. Please use the Contact Us form to let us know!

Please feel free to contact if you need further clarification. :)

Kind Regards

Les :)

stellarweb:

Had one problem with install - Running zc_install it says...
"We did not change your admin directory automatically as it already seems to have been changed from the default." but it DID automatically change the directory and does not allow it to be edited on that page.
This should be fixed now. https://github.com/zencart/zencart/pull/825

webmanstudios:

Hi Guys,

Not sure if it a bug or if it's the way the category editor, product editor and page editor is meant to behave in the new version but I thought I'd mention it. The eror happen with the text in the files or when adding your own content with HTML tags and as plain text with paragraphs.

<snip snip>

The page text looks like one long paragraph:

Conditions of Use Sample Text We haven't updated this page yet. Please use the Contact Us form to let us know!

Please feel free to contact if you need further clarification. :)

Kind Regards

Les :)

Les this is exactly the same problem I'm having. I cannot get HTML text to display like HTML, even if I copy, say, define_checkout_success.php from my running 1.5.4 site, they just come up exactly as you say.

I'm running zen-cart on Windows Server 2012 R2, MySQL 5.6 and PHP 5.6.17. I've deleted the database several times and tried different creation options but ended up with my preferred option of UTF8_general_ci but this problem still perists.

Anyone got any idea about what is happening here?

Thanks, Andy

hard coded text

if (IS_ADMIN_FLAG === true && (MODULE_PAYMENT_MONEYORDER_PAYTO == 'the Store Owner/Website Name' || MODULE_PAYMENT_MONEYORDER_PAYTO == '')) $this->title .= '<span class="alert"> (not configured - needs pay-to)</span>';

webmanstudios:

Not sure if it a bug or if it's the way the category editor, product editor and page editor is meant to behave in the new version but I thought I'd mention it.
It's a bug. We're working on a fix for our over-zealous input cleaner-upper :)
The fix for it is still in-progress, but initial code is at: https://github.com/zencart/zencart/pull/828 (and has been merged, but also followed-up with a few other commits subsequently).

I'm encountering a lot of difficulties in getting OzPost shipping module to work in v155.
Obvious signs of failure is the repeatable effect of wiping out checkbox options if they are changed, leading to an inability of the module to provide shipping estimates - in fact the options don't appear at all in the shopping cart or at checkout.
Before Update showing checked boxes

After Update showing all checkboxes have been cleared

Note that the radio button which was changed from No to Yes shows yes after updating as expected
Examination of the Configuration table shows that the checkboxes are represented in OzPost records as arrays and are set using this function, stored in the set function field for that record e.g.:

[I]zen_cfg_select_multioption(array([/I]
[I][I]                           'Skippy Post Air',[/I][/I]
[I][I][I]                           'Skippy Post Air Insured',[/I][/I][/I]
[I][I][I][I]                           'Skippy Post Air with Tracking',[/I][/I][/I][/I]
[I][I][I][I]                           'Skippy Post Air with Tracking and Insurance',[/I][/I][/I][/I]
          [I]                 'Skippy Post Air +Proof of postage',[/I]
[I][I][I][I]                           'Skippy Post Air Insured +Proof of postage',[/I][/I][/I][/I]
[I][I][I][I]                           'Skippy Post Air with Tracking +Proof of postage',[/I][/I][/I][/I]
[I][I][I][I]                           'Skippy Post Air with Tracking and Insurance +Proof of postage' ),[/I][/I][/I][/I]

In v154 the Ozpost code works just fine but in v155 since at least January 13 it has been failing.
Logs created by an OzPost configuration update event show lots of entries like this:

[16-Feb-2016 00:14:08 Australia/Sydney] PHP Warning:  htmlspecialchars() expects parameter 1 to be string, array given in /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php on line 314
[16-Feb-2016 00:14:08 Australia/Sydney] PHP Stack trace:
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   1. {main}() /zc_1545/nimrod/modules.php:0
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   2. require() /zc_1545/nimrod/modules.php:10
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   3. require() /zc_1545/nimrod/includes/application_top.php:171
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   4. require() /zc_1545/includes/autoload_func.php:48
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   5. AdminRequestSanitizer->runSanitizers() /zc_154/nimrod/includes/init_includes/init_sanitize.php:226
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   6. AdminRequestSanitizer->processBuiltIn() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:75
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   7. call_user_func:{/zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:90}() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   8. AdminRequestSanitizer->filterStrictSanitizeValues() /zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90
[16-Feb-2016 00:14:08 Australia/Sydney] PHP   9. htmlspecialchars() /zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:314
[16-Feb-2016 00:14:08 Australia/Sydney] Request URI: /nimrod/modules.php?set=shipping&module=ozpost&action=save, IP address: fe80::226:8ff:fede:e711
#1  htmlspecialchars() called at [/zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:314]
#2  AdminRequestSanitizer->filterStrictSanitizeValues()
#3  call_user_func() called at [/zc_154/nimrod/includes/classes/AdminRequestSanitizer.php:90]
#4  AdminRequestSanitizer->processBuiltIn() called at [/zc_1545/nimrod/includes/classes/AdminRequestSanitizer.php:75]
#5  AdminRequestSanitizer->runSanitizers() called at [/zc_1545/nimrod/includes/init_includes/init_sanitize.php:226]
#6  require(/zc_154/nimrod/includes/init_includes/init_sanitize.php) called at [/zc_154/includes/autoload_func.php:48]
#7  require(/zc_154/includes/autoload_func.php) called at [/zc_1545/nimrod/includes/application_top.php:171]
#8  require(/zc_154/nimrod/includes/application_top.php) called at [/zc_154/nimrod/modules.php:10]

The first line of the PHP Warning suggests that the sanitiser is being troubled by an array that it wasn't expecting.
Have I found the smoking gun?
I should add that this warning was generated by the v155 beta that contains the #828 fix.
All tests have been conducted on vanilla copies of v154 with only sample data and OzPost added, then upgrading to v155
Testing environment: MAMP Pro, PHP Version: 5.6.10 (Zend: 2.6.0), MySQL 5.5.42

lucidlee:

In v154 the Ozpost code works just fine but in v155 since at least January 13 it has been failing

Notes to devs.
I've not been able to replicate this fault. It doesn't to exist in the v155 that I tested with at the end of December.

I've not tried it with any of the later updates, partly because I've only recently been informed of the problem, partly because I've been pretty busy working on updates for another system, but mainly because this aspect of the ozpost code hasn't had any changes for several years now (other than adding new carrier/methods and removing the obsolete ones.).

I suspect that it is due to the input cleaner upper (expecting strings only, and failing when confronted with an array). The array data isn't unique to ozpost though, and I've asked the OP to see if the same issue exists with any of the other shipping modules (awaiting a reply)
The Skippy post example provided by the OP is just one of many similar code snippets used by the ozpost module and apparently all are effected.
The text/numeric inputs are (apparently) saving just fine. The OP has identified the problem to relating to the radio button multi select. The ozpost config options also include single select dropdown menus. I am awaiting feedback from the OP to see if these are also affected (I suspect that they won't be).

If it weren't for the Dr's comment about "it's a bug due to an overzealous input cleaner upper", even though it was in regards to a different issue " I'd be downloading the latest code to do my own debugging, but I can't help thinking that the two are related, so on that basis I'm inclined to just sit back for a wee bit longer and hoping it'll all be ok (again) when v155 is officially released. In fact it is due to this kind of unexpected issue that I've been holding the next ozpost update for... Just in case I do need to tweak/change something for compatibility.

My questions at the moment are, am I just being wishful that the problem is with zen rather than ozpost? Is the input cleaner upper bug likely to affect the multi select options, or do I need to investigate this further myself?

Cheers
RodG

I'm 90% certain it's part of the bug we're still working on.

I have uploaded the new 1.5.5 beta copied the new files to a test file set and used the zc_install.
The result is what cen be seen by the screen captures I made.
It tells that the db was correctly updated to 1.5.3 but then it says I need to update it because I am on 1.5.2!
kind of confusing and no way to proceed with the upgrade.
Please help if possible.
Thanks

enzo-ita:

I have uploaded the new 1.5.5 beta copied the new files to a test file set and used the zc_install.
The result is what cen be seen by the screen captures I made.
It tells that the db was correctly updated to 1.5.3 but then it says I need to update it because I am on 1.5.2!
kind of confusing and no way to proceed with the upgrade.
Please help if possible.
Thanks
It's very possible that you've triggered a database error during the upgrade. Look in the /logs/ folder for zcInstall-DEBUG.log files, to find out the details.

Dreaded Admin SuperUserName/Password after db update error.

Install 1.5.5 in subfolder of our sandbox domain which is on a different server/same host.
1st run, all looked good except no access to Admin after completion. Admin configure created, but zero contents (empty file).
2nd run of zc-install, all functioned as expected. Looks fine with demo data.
Drop all db tables
Import backup 1.5.4 database
Run zc_install as Upgrade. Don't remember any errors.
Attempt admin login using 1.5.4 superuser credentials. No good.

Used this https://www.zen-cart.com/content.php?44-how-do-i-change-or-reset-my-admin-password-%28i-lost-it%29

AND that worked. Admin access using Admin/admin.
However, none of the admin logins from the imported database will function.

Sandbox: MariaDB 10.0.23/mySQL5.5.5
Live: mySQL 5.6.29
PHP both servers: 5.5.30

i have found a small bug in v1.5.4 which seems to carry over to v1.5.5. not sure if it is worthy of a fix, but i thought i would share it.

in includes/init_includes/init_sanitize.php, on line 72, there is an unset($GLOBALS[$key]).

if someone tries passing over a "db" variable in the URL, it would unset the $db and then zen-cart would generate some error logs, as now one could no longer access the database.

perhaps the dev team is already aware of this behavior, and chosen to do nothing about it. perhaps it has already been covered in the forums before (and if so, i do apologize). perhaps it might be worth wild to have a white-list of variables that can not be manipulated by GET variables. i'm not really sure what the way to go would be...

best.

DrByte:

I'm 90% certain it's part of the bug we're still working on.

Are you still working on this?

The reason for asking is that I've just downloaded a fresh .zip from github, and I've not been able to reproduce
lucidlee's error/problem.

This suggests that the problem, if with the zencart/ozpost code was ok on Jan3rd (my previous install date), then got busted with the version lucidlee downloaded, and has been fixed again with the most recent update (Feb 15)

OR, if this isn't the case, then lucidlee still has a problem specific to lucidee,

So, I thought I should ask before going any further.

Cheers
RodG

still working on it

includes/modules/payment/paypal.php

/**
   * Used to display error message details
   *
   * @return boolean
    */
  function output_error() {
    return false;
  }

Should not this function be get_error like all the other payment modules? I don't find anything using it.

Could more use be made of the new HTML5 types in input forms? e.g. type="email", type="tel", type="number", etc.

This would make an enormous difference to users on phones and would compliment the new responsive theme. On the iPhone (at least) these type settings cause a modified keyboard to display which makes it easier to enter email addresses, phone numbers and numbers respectively.

Sorry if this is a feature request and not a bug report.

Andy

amayze:

Could more use be made of the new HTML5 types in input forms? e.g. type="email", type="tel", type="number", etc.
v155 does this already