[Closed] FEEDBACK ON BETA of v1.5.5

[Dayo]

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.

[lat9]

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:

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);
 }

Shouldn't it be:

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

[DrByte]

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.

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

[DrByte]

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.

[lhungil]

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?

[lhungil]

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

[dbltoe]

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:

[DrByte]

First time to test this new one and decided to start with one of our dinosaurs at 1.3.9.

Greatly appreciating the feedback on upgrading.

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

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.

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

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.

[frank18]

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

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.

So, did as told and removed the zc_install folder, then reloaded http://192.168.0.20/onefivefiveupgradetest/ - result ok.

Then loaded http://192.168.0.20/onefivefiveupgradetest/admin-test/ and got this:



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

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

[DrByte]

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.

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.