[Closed] FEEDBACK ON BETA of v1.5.5

DrByte:

v155 does this already

Sorry. I thought I'd checked this, but I have just done so now and it quite clearly does do it already as you say. My apologies.

Though having tried to create a new customer, I've found a bit of a visual ambiguity for the required field indicator on iPhone screens.
The first picture is of the New Customer section of the Login screen, showing the s for required fields at the end of the fields, which is clear enough.

The second picture shows the same screen on an iPhone 5.

Unfortunately the s end up on a line by themselves and it's not totally clear which field they apply to. Would it be clearer (and possible) to put them after the text label?
i.e.
First Name:
[ Text Field ]
Last Name:
[Text Field ]
etc.

Andy

@amayze, there's another forum through which you can post your template-related issue: https://www.zen-cart.com/showthread.php?219313-Responsive-Classic-%28built-in-to-Zen-Cart-v1-5-5%29-Support-Thread

DrByte:

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.
Thanks for answering.
No I did not trigger any database error.
The problem was simply in the admin table that was a old (1.5.1) version. I managed to delete the table and upload one coming from a 1.5.3 clean install and it did work perfectly.
Ciao from Italy.
enzo

lucidlee:

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

RodG:

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

DrByte:

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

carlwhat:

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.

RodG:

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
Fixed code has been merged into the v155 branch. Should be working fine now.

RixStix:

1st run, all looked good except no access to Admin after completion. Admin configure created, but zero contents (empty file).There was a bug earlier this week where the admin config file might be 0 bytes under certain circumstances. That's been fixed now.

RixStix:

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.
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.30Haven't been able to recreate this sort of situation in any tests in the last couple weeks of importing old databases. Stumped about what's uniquely causing that on your end.

Hi,
I am testing 1.5.5 and found that on an android smartphone, using chrome, the menu with the three lines does not appear. It comes out regularly with firefox and opera for android and also in the "internet browser" usually found as default in a android samsung phone.
I did a small search but did not find mentions of this bug reported in this thread.
Ciao from Itlay.
enzo

I've tested the latest v155beta (downloaded 16_02_20 11.49pm AEDST) on the following setups:

1. virgin v1.5.5 with OzPost 3.6.5 and 4.0.2 and had no problems with OzPost functionality
2. virgin v1.5.4 with OzPost 4.0.2 then upgraded to v1.5.5 and had no problems with OzPost functionality
3. clone of production v1.5.4 system containing a number of other modules including OzPost 4.0.2 and had no problems with OzPost functionality

All running under the same MAMP Pro setup as previously described, so I support Dr Byte's assertion. The mystery remains as to why I repeatedly encountered the problem in the first place when the developer couldn't reproduce it despite heroic efforts on his part. Moot now.

TESTING REQUEST:

We've recently accepted a community code submission to integrate Bootstrap into the Admin in order to make the Admin menu navigation more friendly on mobiles/tablets. It also makes the admin home page easier to read on mobiles because of its responsive stacking of data boxes.
This isn't a wholesale implementation of Bootstrap, as that would be a huge overhaul of the admin and would delay this release another several months and make upgrades even more complicated. We'll leave that overhaul for a later release :)

We'd appreciate some feedback on any issues that might have been caused by this change. Please test the following:
a) admin navigation, on mobiles, tablets, desktops (at standard screen sizes)
b) footer display, particularly on: 1) pages with lots of data, 2) on reports, and 3) when printing the pages you most commonly print.

Using a 155 version downloaded at around 2:20 pm EST today.

In the admin-console, with a two-language store (English and Spanish), there's a white-on-white component so that the selected language (while selected in the HTML) doesn't display the associated text. The <select> tag and its <option> tags are properly formed; it's an issue with the CSS (that I'm having trouble finding).

The overall admin-page padding seems to be "off" (or non-existent). Take a look at the Customers->Orders page, for example:wacko::

• The buttons use the default colors.
• The text butts up to end-of-screen on both the right and left
• There is no padding/margin for the orders-status-history table
• There is no padding between the order totals text/value pairs

Proceeding on to the products' entry. I've got customers who use styling in their product names:

<span style="font-family: Roboto;">#</span>Product Name

... which results in a preview display of that name as:

<span stylfont-family: Roboto;">#</span>Product Name

If it wasn't bad enough that the HTML is now displayed as (er) HTML, the processing has removed characters from the HTML itself! Clicking the "back" button from the preview keeps the malformed HTML.

lat9:

Proceeding on to the products' entry. I've got customers who use styling in their product names:

<span style="font-family: Roboto;">#</span>Product Name

> ... which results in a preview display of that name as:
> ```
<span stylfont-family: Roboto;">#</span>Product Name

If it wasn't bad enough that the HTML is now displayed as (er) HTML, the processing has removed characters from the HTML itself! Clicking the "back" button from the preview keeps the malformed HTML.
That's part of the admin sanitization improvements to mitigate against XSS.

Why exactly are they putting [span]s in the product name? Is this just to insert some icon?

lat9:

Using a 155 version downloaded at around 2:20 pm EST today.

In the admin-console, with a two-language store (English and Spanish), there's a white-on-white component so that the selected language (while selected in the HTML) doesn't display the associated text. The <select> tag and its <option> tags are properly formed; it's an issue with the CSS (that I'm having trouble finding).
I can't seem to recreate this. Not finding any white-on-white.

lat9:

The overall admin-page padding seems to be "off" (or non-existent). Take a look at the Customers->Orders page, for example:wacko::

• The buttons use the default colors.
• The text butts up to end-of-screen on both the right and left
• There is no padding/margin for the orders-status-history table
• There is no padding between the order totals text/value pairs
  Padding issues addressed here: https://github.com/zencart/zencart/pull/848/files?w=0

DrByte:

That's part of the admin sanitization improvements to mitigate against XSS.

Why exactly are they putting [span]s in the product name? Is this just to insert some icon?
They're using the <span> to have a different font for the hash-symbol.

The problem shows up also in the demo products (Test Examples->Test Three), as that product "demonstrates" the use of HTML tags in a product's name (uses <strong> and <br />). The only difference there is that the processing doesn't mangle the HTML associated with the product like it did the <span> with HTML attributes).

To me, it seems like the mitigation is removing a feature that's been around from the get-go.

DrByte:

Padding issues addressed here: https://github.com/zencart/zencart/pull/848/files?w=0
That helped with the padding; the order-navigation buttons on the top of Customers->Orders still "leave a lot to be desired".

DrByte:

I can't seem to recreate this. Not finding any white-on-white.
The language-changer in the header's upper-left corner. It's only visible when multiple languages are defined in the store/admin.

lat9:

That helped with the padding; the order-navigation buttons on the top of Customers->Orders still "leave a lot to be desired".
Lol ... those came directly from the Edit Orders mod.

Will have to look at those separately.

lat9:

They're using the <span> to have a different font for the hash-symbol.
This should help with that: https://github.com/zencart/zencart/pull/847

lat9:

To me, it seems like the mitigation is removing a feature that's been around from the get-go.
Unfortunately security analysts would call it a flaw, not a feature.

Trying to find the balance ...

lat9:

The language-changer in the header's upper-left corner. It's only visible when multiple languages are defined in the store/admin.

I know what you're referring to.
I added another dummy language so that the box would show, and it shows up just fine: