Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • First Name
  • Last Name

SBD's Achievements


Newbie (1/14)



  1. In summation; 1-click does not work with even a default install. I provided the server overrides to place in .htaccess that appeared to help, the upgrade completed rather than timing out or dropping tables with varying results. But the backend still did not function without SQL database manipulation (copied/linked to original thread) to correct access permissions. It's also mentioned there or elsewhere the backend access problem has been long reported. A real store may or may not work from this point, I didn't test the clean install further. a standard process ThirtyBees upgrade worked far better, but for some reason breaks cart functionality in the conversion, upgrade 1.08-1.2.0 process. Might be worth investigating further, maybe the cart may have worked before upgrade? copy_shopdata 1.6.24 clone to ThirtyBees 1.2.0 fresh softacalous install, is encountering DB user access problems, with a simple accesstest php script confirming all database variables are correct. It's looking simpler to give up and continue using the old store, as I've already been doing with >12mths failed 1-click update tests. My new season is about to start in a month, July-August then shuts down again, times ticking. Alternatively, I start from scratch and possibly attempt to manually port some data such as original appearance theme and customer database from the failed conversions. Every failed upgrade conversion that is presented as a working solution, reduces confidence in the Prestashop platform when it fails to perform. The pay per everything model of 1.7 falls apart when the underlying structure can't be updated. A few hundred hours into redesigning from scratch is making more sense than wasted effort chasing bugs. Likely far less to restart, I documented most/all of my alterations and used the recommended override method of the default Theme. In my instance, repeat customers are so few I could enter them manually and send a new password. Simpler to host an offline maintenance version of the old store if I think there's a use for old data.
  2. I was editing and expanding my reply ..... it should address those points now. Following your original suggestion of the copy shopdata code it took a few days... I didn't realise at first the second comment was from yourself also. Server settings were part of the problem. Log was not useful as it would sometimes attempt to work on a table, other times drop it due to timeouts. Once settings allowed the "upgrade" to "complete" the backend was non-functional. It would appear that the 500 errors were result of corruption from insufficient resources under server settings, which is why I have listed everything that resulted in a partial successful upgrade. not reduced rights, the core admin account has no access to the backend after 1-click upgrade. Superadmin is part of the quote from the quoted thread, along with the solution. all files are 755 directories, 644 files etc as per an usual installation.
  3. Noone had asked prior to your suggestions. I was delving into the debug log, which was not particularly helpful. That is a beyond the key problem of the 1-click not working as implied when following it's instructions and lack of. After uncovering some more server settings, I managed to get most of it, but not all, and only for a fresh default installation, nowhere near upgrading an actual store. For those attempting to get somewhere with the 1-click module, on a clean fresh 1.6.24 install; Add these to the end of the .htaccess; it may correct some server level settings, timeouts etc. This at least prevented the upgrade falling over partway through. === .htaccess === php_value memory_limit 512M php_value max_execution_time=300 php_value max_input_time=-1 php_value upload_max_filesize 10M php_value post_max_size 20M On top of this, ensure that your PHP settings under CPanel, or server configuration have the following enabled; In my case cURL, iconv, OpenSSL were not available for selection, but confirmed with host and testing that they were turned on. But even with this, the backend is non-functional following an 1-click upgrade. There's a few threads around discussing a long overdue bug requiring you to reset the admin privileges. Ie... if this manual step is required, the 1-click is not functioning as 1-click 1.6.24 to 1.7.x access not complete until resetting admin account; In CPanel, start PhpMyAdmin, select the Prestashop database, and in the SQL tab enter; alter psjz_ to whatever prefix your tables may have... =part way there, but nowhere near a successful migration. It shows even a fresh install can run into problems with hosting settings, and that 1-click screws up the admin permissions in the database. As far as I can tell the need to reset database has been reported for the past 18months or more. Thank you for that, having given up on the 1-click, I've spent the past few days on the thirty-bees 1.2.0 conversion option (default thirtybees migrate/upgrade to 1.2.0 resulted in shopping carts that empty themselves on checkout), and so today I tried the copy_shopdata path instead. Another brick wall unfortunately, even with running through prestatools, cleaning etc. Without inspiration, I'll need to start from scratch or piece together some of the migrated data into a fresh install, or ... give up. Trying to run copy_shopdata results in "MySQL error 1045: Access denied for user" This is not the obvious stuff up of users, servers, passwords... or % characters in passwords. Resetting password etc multiple times, entering into store clone and successfully viewing the frontend... ... as testaccess.php next to the copy_shopdata.php file in the destination admin/prestatools/ directory of a thirtybees Cpanel-softaculous installed version, the following script indicates a successful connection. Variants of localhost etc also tested. I'm stumped on this one. I also tried adding the .htaccess limits and timeouts I posted above into the destination store directory.
  4. Thank you for the suggestion, but migrating to a fresh install then upgrading, is not going to work, when a fresh default install can not be upgraded either. The upgrade process is severely flawed if I can not work on a fresh clean presta 1.6.24 installation with zero user data. I'm attempting for the last time with some php timeout settings, before looking for a new eCommerce solution. I may test the thirty bees option. I am not even that set on keeping customer data, order history, and with only a handful of active products, it is more the site appearance integration that I wished to preserve. But wasting 30-50 hours trying to upgrade copies of Prestashop, that's a significant portion of the effort it took to customise it in the first place. Yes I tried disabling all theme over-rides etc.... The upgrade does not work on a default 1.6.24 installation, so it is nothing to do with my site at all. All PHP requirements confirmed as active, last possible option timeouts and memory limits. I originally chose Prestashop for being able to set sales units as grams, and a fast loading time with limited products. Perhaps the sales units can be replicated in other platforms for the same overall coding time investment. The pay for an addon for each basic functionality platform has grown old also. The lesson to test payment platforms before investing time into designing store was valuable though, several payment modules from Australian providers have clearly never been tested as they contained fatal flaws.
  5. Does this module currently work at all? I have tried numerous times over the past 12 months to upgrade a clone of my store. It is a good thing I tested with clone, it has failed everytime including setting to defaults, clearing cache etc etc... Time for a TRUE TEST. I did a FRESH INSTALL of I activated the 1-click module. I attempted the suggested upgrade of to .... and I get the same result as with trying to upgrade my clone of, which uses default modules only, and has been customised with the recommended override method. BUT since it even fails in the same way with a default install of, I do not think there is actually any issue with my store. Well, consider this a contact, the problem does persist. It was a default fresh install 5minutes old. It still won't upgrade with the 1-click module. Did I miss a magic window of versions it would actually upgrade? Has this been tested as working successfully?
  6. I got this last night. The key is in Errors red message. Although it says your server has 128M allowed for memory, and it tried to use only 64M, the fix was to set the PHP memory limit to 512M. This was under PHP 7.2. Perhaps a smaller increase would work, but the error is garbage anyhow as it states there is double the required amount of memory available. From the few hours reading I spent getting the upgrade to work, uninformative errors and difficult problem tracking seem to be normal for upgrade process. Hope this helps. It's not looking like it is worth upgrading Prestashop from 1.6 to 1.7 Basically would have to recreate site from scratch on a clean install rather than deal with errors in migration, hopefully with ability to import existing customers intact from the "upgrade". I fully documented all original development, so it could be replicated... but... I eventually succeeded in upgrade, I needed to set themes to default as expected. But also had to set language to en-us and remove australian english to prevent errors in updating database. My site only has a dozen products, a few hundred customers. Only one additional module for Payment. No other third party content. Theme was an override of default, which was easily reset for upgrade. After successful update to 7.4.2. The expected mess and need to redesign the site.... First problem, the top horizontal menu wont allow any categories to be assigned to it. This may be left from the 1.6 version, as the module is called Top horizontal menu, yet in clean install it is Main Menu. In either case I cannot add existing categories in the upgraded site, either in the Top Horizontal Menu, or Man Menu modules. My very first action since upgrade, all caching off. It appears the import of existing categories didn't work properly, not a good sign, who knows if products and customers went well. Seems it's not ready for upgrade if such a simple store cant migrate. I'll leave the 1.6 running, (if it's not broken, don't touch it. I don't have EU clients for privacy problems) and likely spend the development effort on a different platform. If you need to rewrite your site from scratch, it's only worth doing on a stable, tested platform. My reading uncovered there's recently only four in=house developers at PrestaShop and dozens of Marketers. So it's relying on the community to fix all the problems... eventually.
  7. Next, you will find that Login with PayPal doesn't work, no solution. Express Checkout (ignores shipping, gets lost if cart contents are altered). All up, one of the better payment gateways for Prestashop... Make sure to test all variant's of customer use, and that amounts paid match invoices, that taxes are included etc. Standard Paypal checkout seems to work, forget about guest, express etc.
  8. Localisation, > Countries > .... EDIT for address formats, compulsory fields etc. should help most of the questions in this old thread for current 1.6 versions. There's too many things broken in Prestashop... "There is 1 error alia is required. "What a great intuitive error message, telling the customer they should have given an "address title" Calling it an address reference such as work, home etc would be a start. But as for the error, cant even find where it's generated and mispelled.
  9. Thank you, I did see that. They fixed the Hour stamp, and shuffled a little code. Also still assumed that reaching the payment gateway meant the module worked, ie. still untested, it doesn't complete the transaction in Prestashop. Additionally, only installable by replacing old version, otherwise it cannot be selected for Australian currency (nice code shuffle) Looking at the controller code in success.php, which does get called despite SecurePay's claims (a simple echo statement proves that), it appears it isn't actually written to complete the transaction at all Seems I'll need to make a copy of the bankwire module, and tell customers to send via paypay to an email address if they wish to use credit... then deal with the paypal problems. About all I've time for this season, I'm >>12hrs/7days
  10. If SecurePay Australia did not offer the module download for PrestaShop, (as a current up to date solution too!) there wouldn't be a problem, just an unsupported cart. I could probably fix it, but I've no time left, it's harvest season, 6 weeks for 12mths income. I wouldn't advise writing a module for it, apparently there's zero demand for it since 2010 given the existing code errors alhough it may have worked for PrestaShop1.2 back then. Certainly in the past 14 months, noone else has used the gateway with presta, so there's no market for a fixed module.
  11. https://www.securepay.com.au/get-started/integrated-shopping-carts/prestashop/ The two provided modules are attached. presta_securepay.zip v1.0.1-secureframe (1).zip This is supposedly a payment gateway for PrestaShop, "Download our SecureFrame PrestaShop module, compatible with the latest versions of Prestashop" Signing up with SecurePay involves a lengthy rigamarole, business bank accounts only, layers of validation, verification, processing periods. Them testing your store, policies, terms & conditions etc. It's a shame the same diligence is not applied to their provided gateway. First attempt to use generated a "Fingerprint Error" I was given information for the 2010 dated, SecurePay version, then found the equivalent in the SecureFrame module... Error unfixed for six years! The code has an error with timedate stamps, requiring timedate stamps in 24hr mode, but the code is 12hr. The files in the module were last updated in May 2015. Evidently noone's used the module for at least that long, and then the next error, proving it's apparently never used, and never tested at all. With the code no longer generating a fingerprint error, due to the timestamp, it "apparently" processes a transaction. But the cart never clears, it does not return the payment as processed. I've been told the fault was my SSL (lets encrypt on a test copy of server... fair enough) But it still failed with a Trustwave SSL. "Oh, the validation module is not responding... test it with this online tool" ... with the inference there is some fault in my server set up. Test fails... open the file..../module/secureframe/validation see the zip attached.... ITS NOTHING BUT COMMENT, SAYING THE FILE IS DEPRECATED I wonder why their server can't deliver a paid status to that file..... To put it mildly, I'm livid. Not the first time either, I looked at SecurePay and Prestashop, due to similar faults with eWay and XCart (illegal zero tax errors, no receipt for surcharge functionality etc). Doesn't anyone test code anymore?
  12. A recent google maps update now requires the creation of an API key to access the maps feature. For a time, URL's previously used to access the map will continue to function, but new stores will require their own key. This results in the store map feature; Preferences => Store Contacts => Show simplified store locator=NO first showing the map briefly, then an error message; "Oops! Something went wrong This page didn't load Google Maps correctly. See the JavaScript console for technical details" js?sensor=true&region=AU:32 Google Maps API error: MissingKeyMapError https://developers.google.com/maps/documentation/javascript/error-messages#missing-key-map-error A guide to obtaining and implementing the key is here https://developers.google.com/maps/documentation/javascript/get-api-key#get-an-api-key But, I've no idea how to get it into Presta Shop, I can't find where the maps function is called from. Obviously the interface is going to need to be altered in future to allow a key to be entered. For the time being, does anyone know where it can be edited in?
  • Create New...