Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by ecartz

  1. 17 minutes ago, syscon said:

    If not I'll have to install an older version of php. 5.6 and hopefully it will run on debian-stable or Gentoo.

    Note that mysql_connect went in one of the PHP 5 versions -- I think 5.5 (look at the commit message that I linked previously).  So PHP 5.6 probably won't help with the specific problem that you're trying to work around now.  It would likely help you with other problems. 

    5 minutes ago, syscon said:

    I imported my database (in Debian stable) to  MariaDB so can I install the new Phoenix-osCommerce and point it to that database?

    Burt posted instructions for updating from osCommerce to Phoenix.  It's probably somewhere in the Phoenix Club if you join that.  I don't remember specifics, but I believe that he was suggesting to build the Phoenix store first and then import the data into the tables there (not attempt to point Phoenix at the osC database).  There's also a list of tables not to port over, e.g. address_format, configuration, and sessions. 

  2. Go back through the old versions of osCommerce until you find where they switched from mysql_connect to mysqli_connect and then apply that set of changes.  Note that this is just the first of many changes that you will have to make, even just in that file.  Because every mysql_ function was deprecated, not just mysql_connect.  And there are many other changes needed for PHP 7. 

    But anyway, the specific commit that you want is probably https://github.com/osCommerce/oscommerce2/commit/0064f6ce2208eaa972ebcc9e6772e45c7e3ee6fc#diff-611dd0e5f90ff998c01f8365dff385c1b0167b05eaf99d58fec24539b9a5b8fc

    It might be easier to update to a newer version of osCommerce than to patch that one.  In particular, CE Phoenix is already PHP 7 compatible. 

  3. 1 minute ago, Jack_mcs said:

    This isn't due to this addon

    That is incorrect. 

    This add-on rewrites the tep_href_link function to require specifying whether the connection is SSL or non-SSL.  Since that is not necessary in, there is a conflict.  The add-on should be revised to not require choosing a "connection method" and just ignore the third parameter to tep_href_link. 

    The expectation should be that more things will ignore the connection type in the future, further highlighting the difference between how this add-on handles it and how core does. 

  4. I think that a "non-consecutive numerical sort order" is probably the best solution.  Note that it doesn't need to be a database entry.  A hook file in includes/hooks/system would work as well. 

    The closest thing to documentation is the commit notes (and the commit itself):  https://github.com/gburton/CE-Phoenix/commit/ae01e0d4d91b2e4a561735168ef4fbe6ba8e6899

    Related commit:  https://github.com/gburton/CE-Phoenix/commit/d2adabebe2efbdcd28513c6057758cd25ed48fc4

    I don't think that it is very complicated.  HTTP_SERVER . DIR_WS_CATALOG should always be used now, where previously it was only sometimes used (in the ENABLE_SSL false case).  For the most part, this is just simpler.  Because instead of having to check various things to determine the correct link, the code can just consistently use one thing.  The old system was complicated, as it had to try to mix SSL and non-SSL pages.  But this always uses whatever the HTTP_SERVER is configured to provide. 

  5. 41 minutes ago, lyonsperf said:

    I don't understand the reasoning in why they do this

    Three things: 

    1.  They may be using this to send spam email.  If the email address is for someone else but the personalized information is for "product/link they want to spam", they can use your email system to send their spam. 

    2.  They may want you to read the messages.  I.e. they are spamming you. 

    3.  They may simply be paid to do this.  Even if ineffective, they still get paid. 

    There are several Captcha mods, including two from Burt for Phoenix. 

    Apache includes the ability to block IP ranges.  I think there may be mods that help you configure Apache. 

  6.     if ( isset($trInfo->s2p_id) && ($s2p['s2p_id'] == $trInfo->s2p_id) ) {
          echo '              <tr class="dataTableRowSelected" onmouseover="this.style.cursor=\'hand\'" onclick="document.location.href=\'' . tep_href_link('ship2pay.php', 'page=' . $_GET['page'] . '&s2p_id=' . $trInfo->s2p_id . '&action=edit') . '\'">' . "\n";
          $icon = tep_image('images/icon_arrow_right.gif', '');
        } else {
          echo '              <tr class="dataTableRow" onmouseover="this.className=\'dataTableRowOver\';this.style.cursor=\'hand\'" onmouseout="this.className=\'dataTableRow\'" onclick="document.location.href=\'' . tep_href_link('ship2pay.php', 'page=' . $_GET['page'] . '&s2p_id=' . $s2p['s2p_id']) . '\'">' . "\n";
          $icon = '<a href="' . tep_href_link('ship2pay.php', 'page=' . $_GET['page'] . '&s2p_id=' . $s2p['s2p_id']) . '">' . tep_image('images/icon_info.gif', IMAGE_ICON_INFO) . '</a>';

    That's replacing 112-116.  Then at 128

                    <td class="dataTableContent" align="right"><?= $icon ?>&nbsp;</td>


  7. The notice is suggesting that there is a problem in the display_input function of cd_wholesale.php such that the $input_id is not getting set.  Perhaps a corrupted copy of that file?  Or it's barely possible that there is one configuration where it does get set and another where it does not. 

  8. 3 hours ago, ArtcoInc said:

    2) Aren't you supposed to have commas after each WHERE/AND line (except the last line)?

    3) I'm not sure if there are supposed to be commas after the JOIN/ON lines ... 

    No.  Only commas in the list between SELECT and FROM. 

    This is not supposed to be a subquery.  It's just supposed to replace the SELECT list, of, things with SELECT COUNT(*)

    It works by looking for ' FROM'.  For some reason, it is not finding ' FROM'.  If it is using the standard split class, go into the calling files and add an extra space before the FROM.  Not a tab or anything else.  A space. 

  9. 1 hour ago, Fredi said:

    SELECT COUNT(p.products_id) AS total SELECT

    Whenever I have encountered this problem, it was because the admin/includes/classes/split_page_results.php file was using case sensitive string functions.  So I went through and changed them to be case insensitive.  So one possibility would be that you aren't using the standard version of that file.  That's reinforced by the appearance of p.products_id in the COUNT clause, although that might suggest that this isn't using split_page_results.php at all.  At line 21, the standard version has

          $pos_from = stripos($sql_query, ' from');

    The next word after total should be FROM, not SELECT. 

    I would check what version of split_page_results.php is being used.  Then check that there isn't an App that uses something else instead. 

  10. 23 minutes ago, Omar_one said:

    Maybe using cURL instead will fix the issue. 

    Although then you have the problem of when curl isn't available. 

    It might be overengineering, but a generic remote file access class that could use whatever was available might be worth it.  

    A beginning:  https://stackoverflow.com/questions/3979802/alternative-to-file-get-contents/21177510#21177510

    Note that that still hard codes some of the curl options, which should probably be configured or parameterized instead.  I'd be willing to write something, but testing it would be a pain.  Because we would have to find people with all the alternatives or recreate all the different setups to verify that the failovers worked correctly. 

  11. In PHP 7.4, the actual problematic line is

          $cat_name = $category['categories_name'];

    which makes more sense with the error (dereferencing of null).  It's saying that there is no global variable named $category.  Perhaps this code predated the category_tree change.  I think it should be

          $cat_name = $GLOBALS['OSCOM_category']->getData($GLOBALS['current_category_id'], 'name');

    in the cm_in_featured_products.php file.  And in cm_i_featured_products.php, I think that line and all references to $cat_name in the template file should be removed.  Because the root category doesn't have a name. 

  12. German forum:  https://forums.oscommerce.com/clubs/6-german-community/

    This is the general English forum.  https://forums.oscommerce.com/topic/496159-installation-oscommerce/

    Perhaps you started from a German forum link (I think it used to be on a separate domain; perhaps it redirects to the English domain).  It looks like you can set the English forum to show the non-post content as German.  But the only German-specific section is the German Club/Community. 

  13. 9 minutes ago, ufty73 said:

    so weit alles ok und wurde alles auf den Server geladen, nur bei der Installation bekomme ich dann diese Meldung hier. 



    I'm sorry; I don't speak German.  Which is why I expect that you might get better help in the German Club, where German-speakers are more likely to reside.  I have to use Google Translate to read your posts.  I suppose I could use Google Translate to post my responses, but overall I think that would make things less clear.  Because then no one would be able to see the original English version.  This way, yes, you have to use Google Translate to convert my English into something you find readable, but at least there are my actual words. 

    That error says that there is a problem with the hosting settings.  You would need to ask your host to get the correct value for Database Server (the top field in your screenshot).  Apparently s274.goserver.host is either not the correct value to put there or your host has to reconfigure something to allow it.  Either way, that's something that your host would have to help you do. 

  14. Note that in the short term, store owners can get rid of the notices by changing the configure.php files to add

    & ~E_NOTICE

    to the error_reporting line.  While I think it is better to run at E_ALL because occasionally notices warn of actual problems, if they are getting in your way, that option is always open to you.  That's why error_reporting is now set in the configure.php file and not in the code.  So you can choose the level that works with the Apps that you have installed.  In fact, the update instructions from to included setting these to the old values for compatibility reasons. 

  15. 1 hour ago, ce7 said:

    if the some addon involve to modify code, let say order.php do i modify one of the file or do i modify all or something else?

    This has nothing to do with Rainer's Wholesale App (so this really isn't the right place to ask), but you should copy the latest version into includes/system/override (which you may have to create) and modify it there. 

  16. 9 minutes ago, René H4 said:

    Hi Matt, your Dutch reading skills are excellent! 🙂

    Thanks for getting into this - if it's a specific problem there's one more possible cause I can think of: After the language installation the language if for Dutch was 2 (English=1), I changed that to 4 since that came with other tables in the database (legacy shop). Could that cause the problem?

    Credit Google. 

    Perhaps check what language_id the customer_data_groups table has?  If that were 2 but it is 4 elsewhere, that could cause the fields to disappear entirely.  I was thinking that you were saying that ENTRY_WHATEVER was appearing.  But if you meant that it just isn't showing fields, an inconsistent language ID is possible. 

    It's also possible that it needs you to go to admin > Localization > Customer Data Groups and enter those values manually, like you would with order statuses.  I don't see anywhere that the language pack provides them.  Of course, it would be harder to Google Translate files than stuff on the web, so I might be missing something in the instructions.