Ultimate Seo Urls 5 Pro

[Ultimate Seo Urls 5 Pro]

On 12/4/2019 at 7:22 AM, thierryc said:

Use of undefined constant USE_CACHE

This is telling you that the USE_CACHE constant has not been defined but the code is trying to access it.  This can happen if you try to install an App with an old copy of the file in a newer version of the store.  For example, if you copied the includes/functions/general.php from the App and tried to install it in a Phoenix 1.0.4.0 store. 

Another possibility is that the code

if (USE_CACHE == 'true') {
      tep_reset_cache_block('categories');
      tep_reset_cache_block('also_purchased');
}

is part of the code that the App had you add.  If so, delete the entire block as was done in this change:  https://github.com/gburton/CE-Phoenix/commit/880761995f11435e4909a3aa734b0b4ee1f4ba4c#diff-54d4643a07e7e83ca01aafaf92ac8fc3

[USPS Rate V4, Intl Rate V2 (official support thread)]

The ones that remain are the ones that change from store to store.  For example, your catalog directory might be in the root at / or at /catalog/ or at something like /shop/.  Each store can choose to do something different.  Meanwhile, images/icons/ is always images/icons/ -- there is very little reason to ever change it.  Even if you did want to change it in the URL, you could use something like mod_rewrite so that the directory structure would stay the same. 

In general, most of the constant ones have gone, leaving only the few variable choices.  I find it rather unlikely that we'd take out more of the DIR_WS values (except possibly DIR_WS_HTTPS_CATALOG).  More likely to go would be HTTPS values and USE_PCONNECT.  USE_PCONNECT because mysqli does that in the DB_SERVER.  The HTTPS values because very few stores used mixed HTTP and HTTPS today.  So why support something that no one uses? 

The two DIR_FS_DOWNLOAD values may go.  And STORE_SESSIONS. 

The following are pretty safe, although the HTTP ones might get renamed (or not): 

  define('HTTP_SERVER', ''); // eg, http://localhost - should not be empty for productive servers
  define('HTTP_COOKIE_DOMAIN', '');
  define('HTTP_COOKIE_PATH', '');

  define('DIR_FS_CATALOG', dirname($_SERVER['SCRIPT_FILENAME']) . '/');

// define our database connection
  define('DB_SERVER', ''); // eg, localhost - should not be empty for productive servers
  define('DB_SERVER_USERNAME', '');
  define('DB_SERVER_PASSWORD', '');
  define('DB_DATABASE', 'osCommerce');

DIR_WS_CATALOG is defined elsewhere, but also pretty safe. 

[USPS Rate V4, Intl Rate V2 (official support thread)]

6 hours ago, TomB01 said:

Starting near line 462, replace every reference of "TABLE_CONFIGURATION" with "configuration" (minus my quotes).  Note that outside of the big group of references starting about line 462, there are two additional instances near line 499 and 504.

I wouldn't say it that way.  What should be replaced is

" . TABLE_CONFIGURATION . "

and it gets replaced with

configuration

So that the string looks like

insert into configuration (

It will sort of work if you replace TABLE_CONFIGURATION with configuration, but it will generate a notice that may appear in the logs.  And of course if anyone ever made a constant named configuration, it would break. 

Normally, I'd recommend replacing

 $this->icon = DIR_WS_ICONS . 'shipping_usps.gif';

with

$this->icon = DIR_WS_CATALOG . 'images/icons/shipping_usps.gif'; 

Because that will work regardless of where the catalog directory is located. 

If you use the <> tool to insert code in the forums, it will be easier to tell it from the surrounding text. 

[Google XML Sitemap SEO]

On 12/4/2019 at 3:21 PM, Chadduck said:

The insertion of the "Manual IP" text during the install works fine - However when an individual tries to update the IP they are greeted with this error 

Found it.  The App is called Store Configuration Monitor and it has a bug in its helper functions.  In admin/includes/functions/general.php change the two functions to

function tep_configuration_update($cID, $configuration_value) {
        $configuration_values_query = tep_db_query("select configuration_value, configuration_title, configuration_description from configuration where configuration_id = '" . (int)$cID . "'");
        $configuration_values = tep_db_fetch_array($configuration_values_query);
        tep_db_query("insert into configuration_changes (change_date,previous_setting,new_setting,change_title,change_description) values (now(),'". tep_db_input(tep_db_prepare_input($configuration_values['configuration_value'])) ."','". tep_db_input(tep_db_prepare_input($configuration_value)) ."','". tep_db_input(tep_db_prepare_input($configuration_values['configuration_title'])) ."','". tep_db_input(tep_db_prepare_input($configuration_values['configuration_description']))."')");

        // Check to see if the configuration value changed is the Store Owner's Email address - if it is send a configuration change notification to the existing Email address on file.
        if($cID == 3) {
          tep_mail(STORE_OWNER, $configuration_values['configuration_value'], EMAIL_CONFIGURATION_CHANGE_TEXT_SUBJECT, EMAIL_CONFIGURATION_CHANGE_TEXT_BODY, STORE_OWNER, $configuration_values['configuration_value']);
        }
        tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, EMAIL_CONFIGURATION_CHANGE_TEXT_SUBJECT, EMAIL_CONFIGURATION_CHANGE_TEXT_BODY, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);
}

function tep_module_change($action, $class) {
        tep_db_query("insert into configuration_changes (change_date,previous_setting,new_setting,change_title,change_description) values (now(),'','". tep_db_input(tep_db_prepare_input($action)) ."','". tep_db_input(tep_db_prepare_input($class)) ."','')");
        tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, EMAIL_CONFIGURATION_CHANGE_TEXT_SUBJECT, EMAIL_CONFIGURATION_CHANGE_TEXT_BODY, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);
}

Then you should be able to update values normally in admin. 

[Google XML Sitemap SEO]

       array("INSERT INTO configuration (" . $fields_short . ") VALUES ('Manual IP', 'GOOGLE_XML_SITEMAP_MANUAL_IP', '127.0.0.1', 'Enter the IP that you want to cause the manual run to happen. Separate muliple IP\'s with a comma.- <b>Manual mode only</b>', '" . $cfg_group_id . "', '" . ($sortID++) . "', now())"),

There the unnecessary apostrophe is escaped properly. 

insert into configuration_changes

Now that's interesting.  What is configuration_changes and why is something being inserted into it?  Might it possibly be some other change to your site that make it different?  If you figure out what inserts things in configuration_changes, you might know what is breaking.  Then you can fix that so that it escapes apostrophes properly. 

[Phone Orders]

50 minutes ago, LeeFoster said:

For example you wouldn't need a Paypal payment option.

I think that his point is that the store owner should be able to figure this out and simply not click on the PayPal option. 

The harder thing would be that some options, e.g. Already Paid, would need to only appear this way.  Because you don't want people to select that unless they have, indeed, already paid.  Which is something that the store owner should mark, not the customer. 

At the moment, this seems more aimed at just doing an order while talking to the customer.  It doesn't really seem to cover in person options like cash.  So your friend would only be able to use it if he had a payment option like money order, which basically allows the order to proceed and puts the onus on the store owner to validate payment. 

[canada.post.rest.rate.service.oscommerce.V2.3]

What the set_function does is it creates the form input that you use to edit it.  In this case, a bunch of checkboxes.  That is then saved in admin/modules.php .  It's the save case towards the top of the file.  Try changing it to look like

      case 'save':
        foreach ($_POST['configuration'] as $key => $value) {
          if (isset($value) && is_array($value)) {
            implode(', ', $value);
            $value = str_replace(', --none--', '', $value);
          }

          tep_db_query("update configuration set configuration_value = '" . tep_db_input(tep_db_prepare_input($value)) . "' where configuration_key = '" . tep_db_input(tep_db_prepare_input($key)) . "'");
        }
        tep_redirect(tep_href_link('modules.php', 'set=' . $set . '&module=' . $_GET['module']));
        break;
      case 'install':
      case 'remove':

Expect this to change in a future version of Phoenix. 

Sorry, I was getting distracted by the fact that this section of code has not significantly changed in a long time.  If the problem is that other Apps were changing admin/modules.php to add this code, then that makes a lot more sense. 

[HoneyPot Captcha]

I think that should be

    $verify = 'MODULE_HEADER_TAGS_HONEYPOT_VERIFY_TIME_TO_SUBMIT';
    if (defined($verify) && ! empty($verify)) { 

Otherwise it still wouldn't work if the value was there. 

[Product listing]

3 hours ago, Moxamint said:

Is there a drawback if you make KissIt image thumbnailer calculate the width or height automatically if only height or width is provided?

It makes the layout harder to calculate.  Because if the width is set, then the height can change.  Or if the height is set, the width can change.  Consider specifically the situation where the canonical value is set to 300, considering a 300x300 image.  On some products, the image might be 300x60 and on others 300x2100.  Will it look good to mix products where some are 35 times as tall as others?  Or 50x300 and 2000x300.  Some products are most of the width of a screen while others take up just a fraction. 

If you specify width and height, you can make all the images fit into that box and automatically extend the ones that need it.  So a 300x60 image will get 240 rows of padding.  While the 300x2100 will be resized to something like 43x300 and receive 257 columns of padding.  This gives each product a predictable size in the display. 

[HoneyPot Captcha]

7 hours ago, tonymazz said:

Perhaps this should be an option for future versions, to deploy without core code changes? A hook that would show create account (and on which pages) or not.

What core changes did you make? 

As best I can see, the create_account link typically appears in content modules.  You can already disable those in admin without core changes.  I strongly suspect that there is a way to do at least most of this without core changes now. 

The thing that I might change, possibly not as part of my current project, would be to change what pages redirect to the login page.  That would make it easier to install a purchase without account App.  I.e. I'm thinking about moving the block of code that says

// if the customer is not logged on, redirect them to the login page
  if (!tep_session_is_registered('customer_id')) {
    $navigation->set_snapshot();
    tep_redirect(tep_href_link('login.php', '', 'SSL'));
  }

into a hook file.  I'm pretty sure that existing hook calls can be used. 

[HoneyPot Captcha]

3 hours ago, mhsuffolk said:

Looks good, but for OSC should UK be GB

Yes.  The relevant line from install/oscommerce.sql is

INSERT INTO countries VALUES (222,'United Kingdom','GB','GBR','1');

That would have to be changed to make UK work as the key. 

[HoneyPot Captcha]

You could compare a few things though.  In this example:  the country is Australia.  I don't believe that Australia has a state named Alabama (the US does have a state by that name).  I suspect that the postal code is not valid for Australia.  There are probably rules that an Australian could explain.  Wikipedia suggests that in Australia, all post codes are three or four digits. 

In the United States, all zip codes are either five numbers or five numbers followed by a hyphen followed by four more numbers.  So for a US zip code, you could check that the first five characters are numbers and the sixth character was a hyphen followed by digits in seven through ten.  I'm guessing that an Australian could provide similar rules there.  Perhaps add a postal code format regular expression to the countries table.  It could be '{.*}' by default but something like '{\A\d{5}(?:-\d{4})\z}' for the US and  '{\d{3,4}}' for Australia (none tested). 

Given how lazy spammers are, just filling in about ten formats should cover most of what they'll attempt:  Afghanistan, Albania, Algeria, Andorra, Antigua and Barbuda, Argentina, Australia, Canada, United Kingdom, and United States.  Perhaps later you might add Brazil, China, India, and Japan.  Like in the US, single country stores are probably common in those places.  And single country stores can more easily give the format used in their country. 

[HoneyPot Captcha]

3 minutes ago, cables24h said:

Could that not solve many of the problems?

No, it makes it worse.  Because then they sign up for the account just to get the

Quote

Hello http://fake.viagra.example.com

in the confirmation email.  And it makes it harder for people to actually buy. 

You know how Amazon.com confirms a shipping address?  They ask you to enter your credit card number.  Once you've entered it, you can simply reuse it for the same shipping address.  Similarly, osCommerce authenticates via purchases.  If you put in valid payment information, then clearly your account is valid. 

Social networks have to use confirmation emails because they don't take payment.  But it's clearly an inferior method to checking payment information.  There's lots of work on fraud in payments. 

[[CONTRIBUTION] Ultimate SEO URLs v2.1 - by Chemo]

30 minutes ago, magak2015 said:

I want to export all my dynamic generated HTML URLs to a .csv file or similar. 

I do not know the answer.  But if I were trying to do this, I would look at sitemap Apps. 

Why?  Because they generate listings of URLs and should use the same generation mechanism as osCommerce uses for regular links.  Perhaps not all of them would be compatible with this App, but at least one should. 

[USPS with Dimensions Support v 6.54.1 Install Issue]

Replace all the occurrences of TABLE_WHATEVER with whatever.  E.g.

" . TABLE_CONFIGURATION . " 

would become

configuration

Note that the quotation marks and periods have disappeared in that section. 

This needs done for anything that says TABLE_ in any of the three files (includes/modules/shipping/uspsds.php, includes/classes/packing.php, and includes/classes/xml.php).  It's currently not needed in the admin files, although it would be harmless to do it there as well.  That's part of why I'm not trying to separate the uspsds.php file into things that are called by admin (e.g. the install function) and things that are called in catalog (e.g. the quote function).  Go ahead and change all of them. 

As a general rule, TABLE_WHATEVER gets replaced with whatever (lower case, no TABLE_ at the beginning).  There may be an exception to that, so watch out for lines that say something like

define('TABLE_WHATEVER', 'not_quite_whatever');

and replace occurrences of " . TABLE_WHATEVER . " with not_quite_whatever instead.  The standard osCommerce ones are at https://github.com/gburton/CE-Phoenix/blob/41601da342152b010247083c1a70101aa2468d84/includes/database_tables.php

Also check if any of the DIR_WS entries that have been removed appear in this code.  See https://github.com/gburton/CE-Phoenix/commit/65a7fdc942d043dc442f800c54885b9fb8c54d91#diff-cbf96a696abf49d99741d4219fed49a7 for the list of removed values (those with a red background). 

Have you tried uninstalling and reinstalling the module?  You'd have to reenter the configuration but that might fix certain kinds of issues. 

Inside the module, there are some commented out print_r statements.  Try uncommenting them and running a test order.  This will probably break things more, but it may give useful output.  You may want to change them to something like

print_r([ $request, $xmlResponse ]);

to add the request into the debugging output.  Note the added square brackets. 

Try to figure out what is giving the no shipping methods message and trace back to why it is giving that message. 

[USPS with Dimensions Support v 6.54.1 Install Issue]

If you need it,

 INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added) VALUES ('Postal Code', 'SHIPPING_ORIGIN_ZIP', 'NONE', 'Enter the Postal Code (ZIP) of the Store to be used in shipping quotes.', '7', '2', now());

But you might want to verify that the contribution uses SHIPPING_ORIGIN_ZIP first. 

[USPS with Dimensions Support v 6.54.1 Install Issue]

That may look similar, but it's telling you something different.  Try

require_once('includes/classes/xml.php');

Or maybe

require_once(DIR_FS_CATALOG . 'includes/classes/xml.php');

Also verify that there is indeed an xml.php file in includes/classes/

[USPS with Dimensions Support v 6.54.1 Install Issue]

42 minutes ago, rsthornton said:

that doesn't seem to be working

Please include more details.  It's not working in that

1.  It is giving the same error?

2.  A different error? 

3.  No error, but not doing something it should be doing?  If so, what is it not doing but should be?

The change I suggested should at least get rid of that exact error.  It may reveal a new problem, but we'll have trouble helping you without more details of what that problem is. 

[USPS with Dimensions Support v 6.54.1 Install Issue]

Go through the App file or files and everywhere you see DIR_WS_CLASSES, replace it with DIR_WS_CATALOG . 'includes/classes/'

[HoneyPot Captcha]

1 hour ago, puggybelle said:

I don't know what you mean.

1.  Make sure that you are using the code version with

$_SESSION['security_check'] = "$numero";

2.  Make sure that your logging is set back to the original level so that you aren't getting spammed with meaningless notices. 

3.  Make sure that you have the Maths captcha turned on. 

4.  Try to create an account. 

4.  Assuming it fails, go look in the logs and see if it is the same error (the captcah error) or a different error. 

If it is a different error, then you've at least made some progress.  You can move on to troubleshooting that instead. 

If it is still giving the same error, try changing the logging line in includes/functions/honeypot.php to

            WriteToLog(TEXT_CREATE_ACCOUNT_CAPTCHA . ' /' . $_POST['security_check'] . '/' . $_SESSION['security_check'] . '/'); 

Maybe that will get you more information. 

[HoneyPot Captcha]

56 minutes ago, puggybelle said:

Guess I'm wondering if whatever I did to disable it may be in conflict with the captcha code. 

Not and get the error that you're getting in your log (the captcah error message). 

Now, what could have happened is that when you tried it with the session variable bug fixed, you actually got a different error in your log.  You might try creating another account with the session variable fixed and check your logs then, possibly with logging turned back to the original settings so you'll see the error logged without it being buried in other things.  I probably should have suggested that then. 

[HoneyPot Captcha]

39 minutes ago, puggybelle said:

Captcha is misspelled - could there be typos in the contribution causing a problem? 

Not exactly a typo, but in captcha.php try changing

// set session variable to total
$_SESSION['check'] = $numero;

to

// set session variable to total
$_SESSION['security_check'] = $numero;

to match the usage in includes/functions/honeypot.php

[[Contribution] MaxMind Fraud Detection Service v3.0]

2 hours ago, nrlatsha said:

Hello, I must not have gotten the notifications for these posts until I saw Jason's post.  What is the current ask?

I think that it's two things: 

On 5/3/2018 at 6:33 AM, Stephan Gebbers said:

any chance that this module will get an update to be able to use minfraud score/insights/factors ?

1. Integrate new features that are already supported in the MaxMind API.
2. Update for Phoenix.

• By hardcoding database tables. 
• By hardcoding filenames.
• By hardcoding values that previous were fetched from DIR_WS. 
• Move the language defines into their own files (not in english.php).  Probably includes/languages/english/modules/maxmind.php or conceivably in something called from a hook file.
• Utilizing hooks.  Ideally the module should just be a drop-in install.  Failing that, code should be inserted by adding hook calls.  E.g. an existing one (of four) from includes/template_top.php

        <?php
        echo $OSCOM_Hooks->call('siteWide', 'injectBodyContentStart');
        ?>

If the existing hook calls are sufficient, great.  If not, create a new one. 

It might also be helpful to move the license key configuration out of code and into the module. 
 

[Support thread for JcM Header Stock Banner V1.0 Phoenix]

2 hours ago, JcMagpie said:

No sorry would require editing core files if all the files and functions used have been removed and Iwould imaging the SQL tables will also go.

No it wouldn't require core changes.  Just add a hook file to add

global $cl_box_groups;

foreach ( $cl_box_groups as &$group ) {
  if (BOX_HEADING_TOOLS == $group['heading']) {
    $group['apps'][] = array(
        'code' => 'banner_manager.php',
        'title' => BOX_TOOLS_BANNER_MANAGER,
        'link' => tep_href_link('banner_manager.php')
    )
  }
}

in a listen function.  You can put the necessary defines and requires in the file but outside the class.   This can be hooked into the admin siteStart, as that runs after the variable is built but before it is used.  Any catalog changes from the original banner manager code could likely be implemented as an injectAppTop siteWide hook. 

Then you just upload the files into the right places and run SQL to make any necessary database changes. 

Note that for someone upgrading to 1.0.3.0, they could just skip deleting the files and running the database changes relevant to the banner manager.  The only part that they really need to do is updating the files that reference the banner manager, and the hook files will fix that. 

[Ultimate Seo Urls 5 Pro]

1 hour ago, piernas said:

This hook, if it does what I think, could help avoiding part of the core changes, but it's still not in the current (1.0.28) version.

You could always backport it.  So rather than some big block of changes, you add one hook line.  And then a hook file with the big block of changes. 

You know, something like, "If not already there, just before

  if (tep_not_null($action)) {
    switch ($action) {

add

  $OSCOM_Hooks->call('categories', 'productPreAction');

Then when Phoenix 1.0.3.0 drops, you'll be ready to go from a one line code change to no core code change.  After already managing to move the big block of code outside core.