[Closed] FEEDBACK ON BETA of v1.5.5

[DivaVocals]

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.

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

[DrByte]

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: 8M

Database: 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:

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

[DrByte]

Ok, first upgrade attempt.

Many thanks for testing this and giving your detailed feedback. Much appreciated!

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.

I'm curious why it switched to SSL.
- 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.

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'

That's a display-only "title", so editing it wouldn't solve the https redirect.
That said, there was a separate bug related to that setting, which has been fixed in the latest code up on github.

[frank18]

Many thanks for testing this and giving your detailed feedback. Much appreciated!

Thanks DrByte.

I'm curious why it switched to SSL.
- What's your HTTP_SERVER setting in your admin configure.php?
- Did the installer incorrectly set that to an https URL?....

LOL, me too.

After posting I checked the HTTP_SERVER setting and it was indeed set to

define('HTTP_SERVER', 'https://192.168.0.20');

I changed that to

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

define('HTTP_SERVER', 'http://192.168.0.20');

and I never had a problem with this. Goes back to 1.3.8a sites.

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.

[dbltoe]

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.

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.

[swguy]

Note that PHP 5.4 is past end of life. http://php.net/supported-versions.php

[DrByte]

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.

Yes, during an upgrade it leaves the directory name alone.

[swguy]

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

[lat9]

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!

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.

[DrByte]

Question: Should the value of the default template change to responsive_classic after zc_install is run in upgrade mode?

Nope.

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