oscommerce phoenix Installation Problems

[spoma 0]

All

Thank you for any help that you can offer.

I'm currently running a website on v2.3.4 and I decided to give oscommerce phoenix a go on my local server.  My plan is to upgrade the v2.3.4 system to oscommerce phoenix.

When installing phoenix out of the box, with default database I am receiving an error:

1525 - Incorrect DATETIME value: ''

select banners_id, date_scheduled from banners where date_scheduled != ''

 I can see in the admin error that this error is coming from this SQL (as an example) and seems to be something to do with MYSql change to date comparison.  I'm wondering if this is a problem others have come across.  The only thread I can find on this appears the user was running v2.3.4 and he was told to upgrade to phoenix.

Are there certain versions of MySQL, PHP and Apache that are supported with Phoenix?  Here is what I am running:

- Apache 2.4.41

-PHP version 7.2.21

-MySQL 8.0.17 via Homebrew

-OSCOM CE Phoenix v1.0.2.0

I'm hoping maybe something i'm running isn't a supported version and this is an easy change. 

Any help would be appreciated.

Thanks.

 

Edited August 18 by spoma

[spoma 0]

I downgraded my version of mysql to 5.7.X and everything is working fine.  My guess is it's a compatibility issue with mysql 8.  Thanks

[♥Heatherbell 141]

@spoma When we migrated, we were advised to create a new database and install Phoenix in a sub-directory on our live server (running Apache, MySQL 5.7, PHP 7.1) so we knew it was OK in that environment. When it was all loaded and ready, we just moved the whole new site up from the sub-directory.

[♥JcMagpie 1,421]

8 hours ago, spoma said:

1525 - Incorrect DATETIME value

https://bugs.mysql.com/bug.php?id=95466

public_html/includes/functions/banner.php

Edited August 19 by JcMagpie

[spoma 0]

@Heatherbell  thank you

 

@JcMagpie  I saw that link as well earlier which is what lead me to try downgrading MySQL.  In reading that, it's not quite clear to me if they are treating as a bug of if this is an intended change.  Seems to be some debate.  If left like this it will mean an incompatibility with MySQL 8.  I believe this is all correct if I'm reading the bug report correctly.  Thanks for the feedback.

I do seem to be up and running at this point.  I have the base system working.  I'm going through and making my admin changes so that they match my old system.  From here I'm going to migrate over my products and try to get that piece working.  From what I am reading it seems like installing Easy Populate and using that for the migration might be the best / safest way to go.  I see that some have migrated tables on a case by case basis, but I have found a list yet that shows which tables to migrate and which to avoid.  I'll likely try and do some kind of table comparison between v2.3.4 and CE Phoenix and see where I get with that.  

 

Thanks again for the quick responses and feedback. 

[♥Heatherbell 141]

@spoma We just imported table data from tables related to 'shopping history', if you know what I mean,  customers, orders. categories, products etc. You could also do zone related data but you could do that in admin. You know what you're doing more than us, we just did it by trial and error!

[♥JcMagpie 1,421]

13 minutes ago, spoma said:

treating as a bug of if this is an intended change

I belive it is an intended change, I was unabe to reproduce your fault as all my sites run on MariaDB 10.2 which has no issues with the banner function, it's working fine on my sites with the latest Phoenix.

 

 

[spoma 0]

I made some pretty good progress today.  I got my data almost all moved over.  I have all products, orders and categories moved over.  I still to work on users.  I kept notes and will post them once I clean everything up.  I did a comparison of database tables between 2.3.4 and Phoenix on those tables that were being migrated over. 

I do appear to be hitting a problem in regards to categories.  It seems to be related to deprecated functionality in PHP 7.2.X.  I'm running v7.2.21.  I thought I read that it was supported on php 7.2 and even 7.3.  Is this not the case?  Should I downgrade to PHP 7.1? 

Here is the error that I am receiving when I click on a category.

Use of undefined constant MODULE_CONTENT_IN_CATEGORY_LISTING_DISPLAY_ROW_SM - assumed 'MODULE_CONTENT_IN_CATEGORY_LISTING_DISPLAY_ROW_SM' (this will throw an Error in a future version of PHP) in /usr/local/var/www/xxxx/includes/modules/content/index_nested/templates/tpl_cm_in_category_listing.php on line 16

Warning: A non-numeric value encountered in /usr/local/var/www/xxxx/includes/modules/content/index_nested/templates/tpl_cm_in_category_listing.php on line 16

Fatal error: Uncaught DivisionByZeroError: Modulo by zero in /usr/local/var/www/xxxx/includes/modules/content/index_nested/templates/tpl_cm_in_category_listing.php:16 Stack trace: #0 /usr/local/var/www/xxxx/includes/modules/content/index_nested/cm_in_category_listing.php(49): include() #1 /usr/local/var/www/xxxx/includes/classes/osc_template.php(146): cm_in_category_listing->execute() #2 /usr/local/var/www/xxxx/index.php(46): oscTemplate->getContent('index_nested') #3 {main} thrown in /usr/local/var/www/xxxx/includes/modules/content/index_nested/templates/tpl_cm_in_category_listing.php on line 16

 

Any help that can be provided would be greatly appreciated. 

[♥Gyakutsuki 115]

It seems this constant do not exist : MODULE_CONTENT_IN_CATEGORY_LISTING_DISPLAY_ROW_SM maybe there is something close, look the files in relation. That's why you have a warning.

[René H4 57]

4 hours ago, spoma said:

atal error: Uncaught DivisionByZeroError: Modulo by zero in /usr/local/var/www/xxxx/includes/modules/content/index_nested/templates/tpl_cm_in_category_listing.php:16 Stack trace: #0 /usr/local/var/www/xxxx/includes/modules/content/index_nested/cm_in_category_listing.php(49): include() #1 /usr/local/var/www/xxxx/includes/classes/osc_template.php(146): cm_in_category_listing->execute() #2 /usr/local/var/www/xxxx/index.php(46): oscTemplate->getContent('index_nested') #3 {main} thrown in /usr/local/var/www/xxxx/includes/modules/content/index_nested/templates/tpl_cm_in_category_listing.php on line 16

I had a number of warnings like this on my test site, I just removed that module an re-installed it.

It appeared that the Phoenix module had some more parameters, after re-installing the modue it picked up these parameters, and the message was gone.

[burt 3,798]

I introduced this Bug in 1.0.2.0 👎
I've pushed a fix in 1.0.2.1 👍

As an easy todo, here and now, fix...do exactly as @René H4 states;  uninstall the module and then re-install the module.

[spoma 0]

All - thanks for the replies.  That did the trick.  I removed Modules->Content->Sub Category List and then reinstalled the module.  When it re-added it had a bunch more criteria with it and the error went away.

Thanks

[fridgebox 6]

just going on from the first reported bug about the banners , in includes/functions/banner.php
around line 26 is say:
 

// Auto activate banners
  function tep_activate_banners() {
    $banners_query = tep_db_query("select banners_id, date_scheduled from banners where date_scheduled != ''");
    if (tep_db_num_rows($banners_query)) {
      while ($banners = tep_db_fetch_array($banners_query)) {
        if (date('Y-m-d H:i:s') >= $banners['date_scheduled']) {
          tep_set_banner_status($banners['banners_id'], '1');
        }
      }
    }
  }

The default installation set's 

date_scheduled

to NULL
untested:
 

// Auto activate banners
  function tep_activate_banners() {
    $banners_query = tep_db_query("select banners_id, date_scheduled from banners where date_scheduled IS NOT NULL");
    if (tep_db_num_rows($banners_query)) {
      while ($banners = tep_db_fetch_array($banners_query)) {
        if (date('Y-m-d H:i:s') >= $banners['date_scheduled']) {
          tep_set_banner_status($banners['banners_id'], '1');
        }
      }
    }
  }

No?
i think there is a difference between !=' ' and IS NOT NULL

 

I not even tested it, but when first schedule it and later on remove the schedule, does it set "date_scheduled" to NULL or just empty.
Not want to be a pain in the ass, but there are more similar problems like these ( cannot even point them all out, as i override them also).
It became all more strict nowadays's.

But i like the strict stuff, as it prevents failure and bad coding.

Edited August 23 by fridgebox