Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

surknight

Pioneers
  • Posts

    20
  • Joined

  • Last visited

Posts posted by surknight

  1. I have a general question regarding deprecated coding. I'm working on installing a module (Advanced Address Management) which uses $HTTP_POST_VARS rather liberally. The affected lines in the cart files (OSC 2.3.3) uses $_POST. For instance, one line in one of the AM contribution files reads 

    $firstname = tep_db_prepare_input($HTTP_POST_VARS['firstname']);
    

    The corresponding line in the cart files reads

    $firstname = tep_db_prepare_input($_POST['firstname']);
    

    I understand that $HTTP_POST_VARS is deprecated and that $_POST isn't an exact equivalent. Should I change all the deprecated syntax to $_POST or just leave it as is?

     

    Thanks in advance.

  2. Yes, the page encoding does show as UTF-8 at all times. Changing it to either Central European ISO or Central European Windows corrects the title bar for the manufacturer's box on the index page, but the rest of the page is in the wrong characters then. The second instance with the 'Canon' manufacturer selected doesn't show correctly no matter what the page encoding is set to. As far as the fonts are concerned it's Lucida sans-serif every time.

     

    It seems to be behaving almost as if there were a separate manufacturer's box for each manufacturer_id, but there isn't. :mellow:

  3. I'm having a problem with the manufacturer's box sometimes showing the wrong characters in the title and sometimes the wrong wording in dropdown list. Here's what it looks like on the store's index page:

     

    post-323813-0-10482100-1395664211_thumb.jpg

     

    The language is Croatian and the word that should be showing is "Proizvođači" (Manufacturers). The word "Odaberite" under it means 'select'. The problem is that it doesn't show up like that all the time. If I select one of the manufacturer's names from the list I get this:

     

    post-323813-0-77179900-1395664633_thumb.jpg

     

    The box title has obviously switched to another codepage, but it's still not right. Going further down the list of manufactures, I get this:

     

    post-323813-0-08433900-1395664825_thumb.jpg

     

    All of a sudden the manufacturer's box is showing the correct characters and the top selection in the dropdown has changed to 'Molima odaberite' (Please select) which is the default dropdown defined in hrvatski.php.

     

    Everything is in UTF-8. All the language files are in UTF-8 without BOM (verified in Notepad ++). The database is in UTF-8. The setlocale for the language file is hr_HR.UTF-8 and the defined character set is UTF-8. Everywhere else on the page the characters show correctly (see the box under the one in question - it never changes). I searched every language file, and nowhere does either 'Odaberite' by itself as a dropdown selection or 'Proizvođači' with incorrect characters appear. Where else would the cart be pulling this from for the manufacturers box?

     

    Cart verion is 2.3.3, localhost installation. PHP version is 5.4.7

     

    Thanks in advance.

  4. @@surknight Sorry, I missed this post. I don't see what's wrong with that line. Possibly a new version of PHP is responsible. I don't know if the .NET update would also update PHP, but I wouldn't be surprised. Or it just could be a bug in PHP.

    Thanks Jim. I'll post if I figure it out.

     

    Fixed it!

     

    Apparently, the stringable objects needed to be explicitly cast to strings as explained in the PHP Manual, so the problem line is now:

     

    if (tep_not_null($iExtras[(string) $val]) && (array_key_exists ('ServiceName', $iExtras[(string) $val]) && tep_not_null($iExtras[(string) $val['ServiceName']]) && ((constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Online' && $val[(string) 'AvailableOnline'] == 'True') || (constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Retail' && $val[(string) 'Available'] == 'True')))) {
    

     

    That gets rid of the warning on international quotes.

     

    Here are the patched files:

     

    Non-vendor: usps.php

    MVS variant (rename to usps.php before installing): usps-mvs.php

  5. The error message is:

     

    Warning: Illegal offset type in C:\xampp\htdocs\mantisosc\includes\modules\vendors_shipping\usps.php on line 149

     

    It's a localhost installation: osCommerce 2.3.3, xampp 1.8.1, PHP 5.4.7, which hasn't changed since I first installed it.

     

    The only thing that got changed about the o/s since Jan 2 was the Microsoft NET framework 4.5.1 for Windows Vista x64-based Systems (KB2858725) on 1/13. I'm not sure if that was when the cart broke again or later when USPS changed the API since I couldn't get back to work on it until last week.

  6. Minor bug swat:

     

    On line 101 of the MVS version of usps.php, the space between the ' and MODULE_SHIPPING_USPS_INTL_SERVICES_ constant needs to be removed or it generates a warning that the constant MODULE_SHIPPING_USPS_INTL_SERVICES_1 can't be found.

     

    Also need help with this warning: Warning: Illegal string offset 'ServiceName' in C:\xampp\htdocs\catalog\includes\modules\vendors_shipping\usps.php on line 149

     

    this is line 149:

    	 if (isset ($iExtras[$val['ServiceName']]) && tep_not_null($iExtras[$val['ServiceName']]) && ((constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Online' && $val['AvailableOnline'] == 'True') || (constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Retail' && $val['Available'] == 'True'))) {
    

     

    This only happens on international quotes, whether or not there are any service extras enabled, which is interesting as line 141 is virtually the same code as above ($dExtras instead of $iExtras) but doesn't generate the same warning.

    Thanks for the bug report. I've fixed that in the master copy.

     

    The second one is PHP being excessively picky. It should not return an error for that test. You could try something like this:

     

    if (array_key_exists ('ServiceName', $iExtras[$val]) && tep_not_null($iExtras[$val['ServiceName']]) && ((constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Online' && $val['AvailableOnline'] == 'True') || (constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Retail' && $val['Available'] == 'True'))) {
    

     

    Regards

    Jim

    That throws a 'Warning: array_key_exists() expects parameter 2 to be array, null given' warning. Odd, since parameter 2 is an array, although an empty one.

    This is getting ridiculous. I'm tempted to just throw an (array) in front of the second parameter. Unless I can come up with a better test....

     

    OK, try adding !tep_not_null($iExtras[$val]) && in front of that first test.

     

    Regards

    Jim

    That got it. Thanks! :)

     

    Line 149 is acting up again for some reason. Nothing's changed since my last post, but for some reason I'm now getting a warning about an illegal offset type in line 149 for international quotes. Here's the modified line 149, which was working fine:

     

    if (tep_not_null($iExtras[$val]) && (array_key_exists ('ServiceName', $iExtras[$val]) && tep_not_null($iExtras[$val['ServiceName']]) && ((constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Online' && $val['AvailableOnline'] == 'True') || (constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Retail' && $val['Available'] == 'True')))) {
    

     

    Thanks in advance.

  7. Minor bug swat:

     

    On line 101 of the MVS version of usps.php, the space between the ' and MODULE_SHIPPING_USPS_INTL_SERVICES_ constant needs to be removed or it generates a warning that the constant MODULE_SHIPPING_USPS_INTL_SERVICES_1 can't be found.

     

    Also need help with this warning: Warning: Illegal string offset 'ServiceName' in C:\xampp\htdocs\catalog\includes\modules\vendors_shipping\usps.php on line 149

     

    this is line 149:

    	 if (isset ($iExtras[$val['ServiceName']]) && tep_not_null($iExtras[$val['ServiceName']]) && ((constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Online' && $val['AvailableOnline'] == 'True') || (constant('MODULE_SHIPPING_USPS_RATE_TYPE_' . $vendors_id) == 'Retail' && $val['Available'] == 'True'))) {
    

     

    This only happens on international quotes, whether or not there are any service extras enabled, which is interesting as line 141 is virtually the same code as above ($dExtras instead of $iExtras) but doesn't generate the same warning.

  8. Need a little help with a preg_replace error. I'm getting this error when I try installing the MVS version of the USPS module provided with MVS:

     

    Warning: preg_replace(): No ending delimiter ',' found in C:\xampp\htdocs\catalog\admin\vendor_modules.php on line 27

     

    This is line 27 of that file:

     

    $value = preg_replace (", --none--", "", $value);

     

    Any help would be appreciated. I've read the PHP documentation on preg statements and can't quite see the problem.

  9. Has anyone successfully modified FedEx Web Services v9 to work with MVS? I tried, using the instructions supplied in the modules.txt file, but it's not returning quotes. I'd use the Fedex1 module included with MVS (which does work), but I need the ability to select services and add % handling charges for different vendors that the webservices module gives.

     

    I did run into some trouble where the instructions say to modify this line:

     

    'cost' => $shipping + MODULE_SHIPPING_change to fedex module_HANDLING)))
    

     

    to

     

    'cost' => $shipping + $handling)));
    

     

    because the first line doesn't exist in the webservices module, but otherwise the instructions were fairly easy to apply.

     

    The unmodified webservices module does work with MVS off (cart version 2.3.3), so it's not an issue with the fedex credentials being rejected.

     

    Attaching the file I modified in case anyone can spot where it went wrong.

    fedexwebservices.php

  10. That's what I thought too, but all the files and edits are there. The problem seems to be with the new files that go in admin and admin\includes\boxes (vendors, etc), which don't have the same style of coding as the files that came with osc 2.3.3. So far I've fixed the MVS issued vendors.php in admin\includes\boxes by editing and renaming the tools.php file in the same folder:

     

    MVS 1.2 vendors.php - gives result in pic on previous post:

     

    <?php
    /*
    $Id: vendors.php,v 1.21 2003/07/09 01:18:53 hpdl Exp $
    $Loc: /catalog/admin/includes/boxes/ $
    $Mod: MVS V1.2 2009/02/28 JCK/CWG $
    osCommerce, Open Source E-Commerce Solutions
    http://www.oscommerce.com
    Released under the GNU General Public License
    */
    ?>
    <!-- vendors //-->
    	 <tr>
    	 <td>
    <?php
    $heading = array();
    $contents = array();
    $heading[] = array('text' => BOX_HEADING_VENDORS,
    				 'link' => tep_href_link(FILENAME_VENDORS, 'selected_box=vendors'));
    if ($selected_box == 'vendors') {
    $contents[] = array('text' => '<a href="' . tep_href_link(FILENAME_VENDORS, '', 'NONSSL') . '" class="menuBoxContentLink">' . BOX_VENDORS . '</a><br>' .
    							 '<a href="' . tep_href_link(FILENAME_PRODS_VENDORS, '', 'NONSSL') . '" class="menuBoxContentLink">' . BOX_VENDORS_REPORTS_PROD . '</a><br>' .
    							 '<a href="' . tep_href_link(FILENAME_ORDERS_VENDORS, '', 'NONSSL') . '" class="menuBoxContentLink">' . BOX_VENDORS_ORDERS . '</a><br>' .
    							 '<a href="' . tep_href_link(FILENAME_MOVE_VENDORS, '', 'NONSSL') . '" class="menuBoxContentLink">' . BOX_MOVE_VENDOR_PRODS . '</a>');
    }
    $box = new box;
    echo $box->menuBox($heading, $contents);
    ?>
    	 </td>
    	 </tr>
    <!-- catalog_eof //-->
    

     

    Fixed vendors.php based on osc2.3.3 tools.php:

    <?php
    /*
    $Id$
    osCommerce, Open Source E-Commerce Solutions
    http://www.oscommerce.com
    Copyright (c) 2010 osCommerce
    Released under the GNU General Public License
    */
    $cl_box_groups[] = array(
    'heading' => BOX_HEADING_VENDORS,
    'apps' => array(
     array(
     'code' => FILENAME_VENDORS,
     'title' => BOX_VENDORS,
     'link' => tep_href_link(FILENAME_VENDORS)
     ),
     array(
     'code' => FILENAME_PRODS_VENDORS,
     'title' => BOX_VENDORS_REPORTS_PROD,
     'link' => tep_href_link(FILENAME_PRODS_VENDORS)
     ),
     array(
     'code' => FILENAME_ORDERS_VENDORS,
     'title' => BOX_VENDORS_ORDERS,
     'link' => tep_href_link(FILENAME_ORDERS_VENDORS)
     ),
     array(
     'code' => FILENAME_MOVE_VENDORS,
     'title' => BOX_MOVE_VENDOR_PRODS,
     'link' => tep_href_link(FILENAME_MOVE_VENDORS)
     )
    )
    );
    ?>
    

     

    This gives this result: :)

     

    post-323813-0-50030900-1381270884_thumb.jpg

     

    Now I need to fix the other files the links call because clicking them now causes this:

     

    post-323813-0-59149600-1381271115_thumb.jpg

  11. Just installed the latest version of MVS and have a quick question: Is the 'vendors' link in the right place (see pic)? It is in the left column the way the usage file says it should be but I'm wondering if it shouldn't be actually contained in the menu rather than riding up above it like that? Thanks.

     

    post-323813-0-47518500-1381140484_thumb.jpg

  12. Someone needs to check the Ukrainian Language pack from October 26, 2011 v2.3: I got error messages trying to extract the files using the built-in windows unzip, so I switched to 7zip which appeared to solve that problem. However, when I tried to name a new folder 'admin' some of the keyboard keys were suddenly producing the wrong letters; I ended up with 'qd,in' instead and had to reboot to fix it.

     

    Incidentally, this is the only language pack or module I've had any real problems with. My compliments to the devs. :)

  13. I actually found the problem in the setlocale in french.php, which was written out like this:

     

    if (strtolower(substr(PHP_OS, 0, 3)) === 'win') {

    @setlocale(LC_TIME, 'fra');

    }else{

    @setlocale(LC_TIME, 'fr_FR.ISO_8859-1');

    }

     

    Once I got rid of the if-else statements and used only the ISO encoding the weird character mismatch went away. Thanks for the assist, I'll keep that in mind if I run into other problems.

     

    Roland

  14. I've installed the pack complet osCommerce2.3.3 (upgraded French language pack) on OSC 2.3.3 and am having an odd problem viewing the storefront. It mostly appears correctly, except for the last word in the 'New Products for August' line (see the attached Page with utf8 encoding.jpg post-323813-0-88471800-1377942580_thumb.jpg). If I change the encoding on the browser to Western European (Windows), the problem word in that line now appears as it should, but the rest of the page doesn't show properly (see second image post-323813-0-11673900-1377943769_thumb.jpg). How do I fix this? That final word (August) is actually being inserted by the %s variable defined in the index.php file and I can't figure out where %s is coming from or why it's not in utf-8 encoding.

     

    The only other add-ons I've got installed are Theme Switcher 1.4.2 by kymation and Consolidated Login with Guest Checkout for 2.3.1 v1.2 by fulluvscents. Thanks for any help.

     

    Roland

×
×
  • Create New...