New 
ecartz
-
Posts
3,864 -
Joined
-
Last visited
-
Days Won
69
Posts posted by ecartz
-
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
Quotein 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.
-
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.
-
Replace all the occurrences of TABLE_WHATEVER with whatever. E.g.
" . TABLE_CONFIGURATION . "
would become
configurationNote 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.
-
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.
-
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/
-
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.
-
Go through the App file or files and everywhere you see DIR_WS_CLASSES, replace it with DIR_WS_CATALOG . 'includes/classes/'
-
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.
-
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.
-
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
-
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 ?
- Integrate new features that are already supported in the MaxMind API.
- 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.
-
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.
-
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.
-
39 minutes ago, maxmind.jason said:
Dear nrlatsha,
Please get in touch with us at MaxMind (info at maxmind.com) if you would be interested in collaborating on updating your plugin for more advanced minFraud features. We'd be happy to work with you.
Jason
@maxmind.jason, it looks like @nrlatsha last posted to this thread more than four years ago and last visited the forums three years ago. So I'm not sure that your message is likely to get read by its intended recipient. If you wanted to take over this module more directly and post a more up-to-date version, that would be fine.
-
10 minutes ago, raiwa said:
It's not the Apps Area, it's the uploaders 😉
That's what I was saying. The Apps area is not designed for the way that people have been uploading.
There are changes that could be made to the apps area that would make it better, even *with* the way that people try to use it. For example, a simple fix would be to allow people to mark uploads as incremental and offer a filter based on that. Of course, then we'd need a fix for people who pick the wrong one. E.g. voting on such tags.
-
@LeeFoster, if you get this working consistently, it would be helpful if you could upload a new package with all the changes/instructions. The hardest part about fixing this was finding a download that had the file! The Apps area is not really designed to support incremental updates.
It's also not clear to me what changes are necessary in general and what were specific to someone's store.
-
1 hour ago, LeeFoster said:
I've just installed this on Phoenix and for the most part it works however if I have no Stores set to pick up from I get the below errors.
In includes/modules/shipping/multipickup.php, around line 61, find
while ($store = tep_db_fetch_array($qstores)) {
and change to
$this->quotes['methods'] = array(); while ($store = tep_db_fetch_array($qstores)) {
One line added. No existing lines changed.
-
To answer the last question (however belatedly), it costs nothing to offer Amazon Pay on your website. If someone uses it, Amazon charges transaction fees. $.30 per transaction plus 2.9% of the transaction amount. There may be other fees as well in certain circumstances. E.g. 3.9% for cross-border transactions and $20 for a chargeback dispute.
Phone Orders
in General Add-Ons Support
Posted
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.