Demitry

@ecartz Matt, ..you're awesome!! I don't know shell scripting ..so this will not only help me, but anyone else who comes across this thread. I have not removed these files just yet. I'm still waiting to see if my hosting company comes up with an answer before cleaning that entire sub-domain. I did see that stackoverflow.com post when searching for an answer but there were no solutions offered on that post. And though I still use Dreamweaver (old habits die hard), this is the first time I've experienced this problem. And you might be right on point with this outdated software. Tough to let go of that comfort pillow. lol Thanks Matt.

Update: I was given a shell script by my hosting company to clean all of these files out at once, which is a huge help because I had to do it manually the past few times. However, I have not cleared all of these files out just yet. I want to give the hosting company techs plenty of time to figure this problem out before removing it from the server. Here is the script in case someone else runs across this same issue. find /home/change_to_your_own_directory/public_html/ -type f -name "*.mx" -exec rm -rf {} \; Please be very careful before using anything like this, and back-up entire site and all files (along with the .mx file) before running this script. If you don't know what you're doing, don't mess with it!

hi, I'm trying to figure out why I keep getting a ton of these .mx files inserted as copies of all the .php files on the sub-domain I am working on. The files look like this: .mx.99063925.mx though with different numbers for each file,.. and when you open one of these files, its content is identical to one of the .php files I have in the same directory. These .mx files are not generated for any other extension except for .php and each of the .mx file sizes matches the same .php file. They are basically clones of all the .php files. I cleaned them out of every folder and a day later they all reappeared. That happened three times now. This file type is commonly associated with email files, but these are not email files and have nothing to do with that. They are also not desktop files as detailed in this article. https://www.reviversoft.com/file-extensions/mx I called my hosting company several times and they have no idea of what it is. The only thing I was told, was that their higher tier tech support came across this problem once before with a WordPress site and after running a shell script to clean all the .mx files, the issue never came back. They are now trying to figure it out and doing a full site scan. I thought it might be a hack, but this is unlikely. I've done a number of scans for viruses & malware and they all came back clean. I have nothing in my error log and no noticeable issue browsing the site. There is also nothing in the console via Chrome Developer Tools. The .mx files just add clutter to the directory structure and nearly double the size of the osC software. I searched everywhere on this issue (including osC forums) and could not find anything of value. I'm just wondering if anyone has come across this issue before and how it was resolved? Here is an image of FileZilla showing these .mx files.

Ugh! I got it. I know exactly what this issue is. The language file is too deep in my laptop directory and was excluded because of this when I zipped the package. I will upload it now as an update. Thank you for letting me know. The only way for me to know this was to download it and unzip it and now I see that this language file is not in there. Here it is posted here, if you want to just copy and paste it into your own. <?php /* $Id$ Customer Feedback at Checkout Version 1.0 for BS Mod by Demitry osCommerce, Open Source E-Commerce Solutions http://www.oscommerce.com Copyright (c) 2020 osCommerce Released under the GNU General Public License */ define('MODULE_CONTENT_CHECKOUT_SUCCESS_CUSTOMER_FEEDBACK_TITLE', 'Customer Feedback at Checkout'); define('MODULE_CONTENT_CHECKOUT_SUCCESS_CUSTOMER_FEEDBACK_DESCRIPTION', 'Show Customer Feedback Form on the checkout success page.'); define('MODULE_CONTENT_CHECKOUT_SUCCESS_CUSTOMER_FEEDBACK_HEADING', 'And Now, We Need Your Help!'); define('MODULE_CONTENT_CHECKOUT_SUCCESS_CUSTOMER_FEEDBACK_TEXT_REQUEST', 'What "almost" kept you from completing your purchse today?'); // must be the same text in header_tags module language file define('MODULE_CONTENT_CHECKOUT_SUCCESS_CUSTOMER_FEEDBACK_TEXT_MSG_SENT', 'Your message was sent. We truly appreciate you and your business.<br /><br /> Please make any <strong>available selections</strong> on this page and click the Continue button to save your changes.'); ?>

KG, what language file issues. I would certainly like to fix them, but am not sure what you are referring to. If you mean like having the modal window display the "message sent" message, I was not planning on it. The modal closes automatically upon (an error-free) submission and the "message sent" message is displayed on the checkout_success.php page just below the heading title for this module. I could add that message to display in the modal, but then the customer would have to manually close that modal and I'm not sure then,.. what would display on the reloaded checkout_success.php page.

@kgtee @ecartz KG, Matt, Thank you both for your help and advice. I had some challenges with this addon, but finally got it working. It is now available: Customer Feedback at Checkout For anyone else reading this thread, this is NOT a support thread for this addon.

hi Matt, That's actually a pretty good idea that I didn't even think of. Plus, I am already adding a footer script via a header_tags module for the JS validation for that feedback form. So, I'll add the modal and see how that works.

I get the concept, but as far as I know an email has to be structured as a form and if I included it as a module in the checkout_success block, then it will become nested inside of that page's order form. What I can do is add the module as a request for the customers feed back and when they click on the link (which would be a feedback question), that would open a modal window with the email form inside of it. The modal code would then have to be added to that checkout_success.php page after the main order form. Or, I could add it as an on-page form directly on that checkout_success.php page after the main order form. Either way, I would have to alter a core file, which is something I was trying to avoid.

@kgtee Thanks KG, I always thought nesting forms was bad coding practice. I'll read through that stackoverflow link and see what I can get out of it.

Hi, I’m finishing up a module for the checkout success page. It’s a short email form designed to get customer feedback on their purchase experience right at the final step in the checkout process. I could store their feedback in the database, but this is bad because it will quickly bloat the database. There are two issues that I am facing with this modification. First: While writing this module, I realized that this checkout_succes page contains all of the modules inside a form. I’m a bit confused about this form because It is designed to update any customer changed data inside of it (such as product notifications and/or PWA keep account), but the button included inside this form is the Continue button, which redirects the user to the index.php page. So, if a customer makes changes on this form and does not click the Continue button, but instead closes the browser tab, then all of their changes are not saved to the database, right? The point is, many other osC pages apply the Continue button to load the index.php page. Having been on the site, a customer quickly becomes aware of this and may opt to not click that button on the checkout_success page because they are finished shopping and do not want to go to the home page. Additionally, they are likely to believe that their selections on that page are automatically saved upon any changes they make. Why? ..well, because there is no button to save the changes. Therefore, shouldn’t that Continue button be renamed to Update Changes or Save Changes? And, there should be a message displayed on the index.php page post redirection, to let the customer know that their changes were saved. Second: I am now faced with a challenge where (in order to avoid nested forms), I must add my module. I would need to either add it below this form in a separate module block or include it as a button/link to a modular popup. Any ideas on how to better structure this, where I can include the module with the other checkout_success modules and be able to use the related sort order feature to position it where I want?

ok man, ..we're waiting on your version. ...whenever you get time.

I did not know that. I assumed that they would have been removed if they were not going to be used. Ah, that is part of the module, but I could never figure out what that description meant because it did not make much sense to me. Here is the screenshot of it below. Thanks for explaining it.

Jack, thank you for the explanation. The CC module adds only the card number, expiration date, and card type to the customers database table, but so do the other CC processing modules. And even the latest version of osC Phoenix has these columns in the customers database table. what do you mean by split option? I could not find anything related to this. ~~~~ Vicent, I did not plan on it because it was removed from osC and introducing it back in as an addon will likely conflict with the underlying purpose of why it was removed in the first place. As Jack said, it was a PCI compliance issue, but I am not 100% sure if this was the only reason. There may have been other security issues that were part of that decision to remove it as well. Aside from that, I do not use the left or right columns in the osC layout so, my CSS is not structured for that layout - specifically, when resizing the browser. Here is a screenshot of what my payment page looks like. I am currently just using these modules for testing and only plan on having a CC module (via a merchant account) and a PayPal module as payment options.

@domiosc hi Vicent, Thank you for that information. Actually, I redid the old Credit Card module (cc.php) for BS Edge. I have not tested it yet, but it should work for what I'm looking to do before actually getting a merchant account. hi Matt, I took a look at the customers database table and even in the latest version of Phoenix there is a column for credit card numbers. I'm not sure if these are now encrypted or as per Vicent, you still have to get a separate addon installed for that. Anyway, having these in the customers table does not kill the PCI compliance. I ran a PCI complaisance test on my BS Edge site on https://www.immuniweb.com and it came back with everything good except for the Content Security Policy, which goes in the main htaccess file. See screenshot below. @Jack_mcs hi Jack, From our prior conversation, you mentioned that the Credit Card module was removed for PCI non-compliance, however, I ran a test with that module redone for BS Edge on https://www.immuniweb.com and it came back clean for PCI compliance. I'm not sure if there is something else that was the cause, but I just wanted to let you know my findings.