AlwaysSkint

My take on this. Successful e-commerce requires stability and jumping on the latest bleeding edge software always has an element of risk. Continually moving the PHP minimal version is not good practice, IMO. Development of ClicShopping should strive to work on a range of environments and not be tied to a specific version of PHP, for example. I have a number of e-commerce sites that have been running securely and successfully for over 10 years, with only minor updates to their software. It is MUCH more important to squash bugs and improve on existing functionality, rather than impose/introduce the latest trend/fad. Good luck, going forward.

INSERT INTO `clic_languages` VALUES(1, 'Anglais', 'en', 'gb', 'english', 1, 1, 'en_US.UTF-8;en_US.UTF8;enu_usa'); ??? INSERT INTO `clic_languages` VALUES(1, 'English (GB)', 'en', 'gb', 'english', 1, 1, 'en_GB.UTF-8;en_GB.UTF8;enu_gb'); INSERT INTO `clic_languages` VALUES(3, 'English (US)', 'en', 'us', 'english', 1, 1, 'en_US.UTF-8;en_US.UTF8;enu_usa');

Congratulations on the latest release! With the latest release, I'll just rebuild one of my test stores. It would be useful if there were notes on the best way to upgrade an existing store. Personally, I know how to do it manually with Meld and importing SQL but might be more useful for others. (I wish I'd spotted the need to change the SQL statement from Anglais to English in the languages table. )

Significant installation issues have been sent to @ClicShopping - I'm finally nailing down the install routine, so that I can now install manually - what a slog. Phew! 😟

Try to avoid sendmail. To achieve proper email credentials (SPF,DKIM,DMARC) use SMTP. Trust me, you won't regret doing so and (maybe) your hosting provider will be grateful that you do.

@Patrick A quick mention that I have an open Pull request with some updates, plus some English corrections on ClicShopping itself.

I've now figured out this was the wrong way around and now corrected to.. 'group_tax' => (int)$data['customers_group_show_tax'], 'group_order_taxe' => $data['customers_group_tax_exempt'] There is an issue with ClicShopping 'group_tax' = 0 should be Excluding Tax and 'group_tax' = 1 should be Including Tax. Also, I can't use 2 other fields because they are the opposite of the original meaning.. Originals are: 'group_payment_allowed' and 'group_shipment_allowed' ClicShopping: 'group_payment_unallowed' and 'group_shipment_unallowed' 😢

If I manually remove AUTO_INCREMENT from the target customers_groups table, then the migration works. So I need a simple means of removing this prior to the migration, then add it back in once the data has transferred.

@Foster Thanks for trying to help but that is essentially what I was doing when I discovered the data corruption. Hence looking to change the table structure. I'm not looking to append to the existing data, which is irrelevant - it's required to replace it. Fundamentally, the source database begins customers_group_id at zero, whereas ClicShopping begins at 1. I'm now at the stage of dropping the table and trying to recreate it. After a few hours, I've discovered "OM" appears to have a dbdelete function but not a simple dbcreate function. This got me looking into creating a custom\schema but seems overly complex for something quite simple. 😕 I'll perhaps backtrack and reanalyse the problem.

It is the primary - has autoincrement and a different default. This appears to cause a corruption during migration.

I'm looking for a little bit of help here.. Customer groups wont migrate due to a slightly different table definition, so I'm trying to temporarily alter it but it returns a mysql syntax error. //****************************************** //Customers Groups //****************************************** /* Inverted restrictions 'group_payment_allowed' => $data['group_payment_allowed'], 'group_shipment_allowed' => $data['group_shipment_allowed'] */ // Set default to match original db $Qalter = $this->db->prepare('ALTER TABLE :customers_groups CHANGE customers_group_id customers_group_id INT(11) NOT NULL DEFAULT 0 '); $Qalter->execute(); echo 'temporary structure change<br>'; $QcustomersGroups = $mysqli->query('select * from ' . $this->PrefixTable . 'customers_groups '); echo '<hr>'; echo '<div>table_customers_groups</div>'; echo '<div>' . CLICSHOPPING::getDef('text_number_of_item') . ' : ' . $QcustomersGroups->num_rows . '</div>'; echo '<hr>'; while ($data = $QcustomersGroups->fetch_assoc()) { $sql_data_array = [ 'customers_group_id' => (int)$data['customers_group_id'], 'customers_group_name' => $data['customers_group_name'], 'group_tax' => $data['customers_group_tax_exempt'], 'group_order_taxe' => (int)$data['customers_group_show_tax'] ]; $this->db->save('customers_groups', $sql_data_array); } // Return structure to original $QalterRevert = $this->db->prepare('ALTER TABLE :customers_groups CHANGE customers_group_id customers_group_id INT(11) NOT NULL AUTO_INCREMENT '); $QalterRevert->execute();

The banner ID is assigned INT(11), so there is very little danger of a store owner using up the number of possible banners! The most banners that I have seen used in a large store (10s of thousands of products) has been about 25 and it begins to look silly. 😉 About to attempt to submit v1.1 osCmax20.php plus revert some of your changes.. If I can get it to work.

It would be extremely useful if the default logo ID could be changed to say 1000. This should have no impact on any new stores and will allow migrations to keep existing banners. Even for existing stores, there should be no (or very rare) issues. UPDATE `banners` SET `banners_id` = '1000' WHERE `banners`.`banners_id` = 1;

Added a comment on one of the commits, regarding banners - I think that you may have misunderstood me. (Managed to delete & remake my github repo.)

Yes, I did say that I couldn't understand github. 😢 I'm trying to just have one repo called AlwaysSkint, that pulls updates from your master when it gets updated. Then I can make proposed alterations to my fork/branch whatever. I can't even figure out how to delete my fork and start again! I'm getting too old/stupid for this. 😢

Import to a newly created db.. osCmax 2.0.25 Demo Data

Do note that the following may be restricted in some server environments: ini_set('memory_limit','256M'); set_time_limit(0); This is likely to throw a 500 error.

I'll have a look around my local repos for v2.0x demo data - I can't send you my client's data. Once I have v2.0x (nearly) finalised, I'll begin osCmax 2.5 testing - there were a few db changes though nothing major.

This is why I asked. Note: I forgot to test 'newsletters' I'll check that for version 1.1

I notice that you haven't adopted my changes to ImportData Prevent duplicate key errors when resubmitting a migration and ensure no old orders (for example) remain. The current truncates seem arbitrary. Prevent the default Logo banner from being erased (it's not obvious how to recreate it).

Typo above. "adjust" --> "adjusting"

Can you be more specific with your osCmax issue? (It's not OscMax). You may wish to add a note to the readme.md "Larger stores may need to temporarily extend PHP memory and timeout - 256MB and 120 (seconds) should cater for most stores. This is often done by adjust php.ini or .user.ini" Thanks.

I've managed to do something on github. 🤪 Can you merge the two branches and I might be able to add further updates, when available?

Re: purchase of the tool. Please ignore: I got confused by a similar one for a different cart. Re: github - never could get my head around that but can try, I guess. Used SVN in the past. Would be much easier to just post an attachment or provide an upload location eg. netxcloud.

Now that I have the store software running much better, I've had time to test migrations again. I wish I'd realised this tool is now included for free but don't regret the relatively little amount paid for it. Hey, at least it has given me something to work from. 🕵️‍♂️ I have an updated ImportDatabase.php Classes file that truncates many more tables, making migration considerably easier. I also have a new osCmax20.php (note the correct capitalisation) that is now on version 0.8 and is migrating a substantial amount of data now. Would you like these? What's the best/easiest way to get them to you? P.S. I'm using HTML::outputProtected now on some fields.