Jump to content
spoma

oscommerce phoenix Installation Problems

Recommended Posts

Posted (edited)

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 by spoma

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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! :)

Share this post


Link to post
Share on other sites
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.

 

 


 

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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.



Regards
-----------------------------------------
Loïc

Contact me by skype for business
Contact me @gyakutsuki for an answer on the forum

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.


This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest Responsive osCommerce CE (community edition) here

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Posted (edited)

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 by fridgebox

- ICECAT specialist.
(Icecat: open feed with product information, data-sheets for oscommerce.)
- CSV IMPORT specialist.
(manage your suppliers via supplier manager)
Contact me via PM.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×