musicmaster

Not a bug, just a little inconvenience... I have a shop that was upgraded from Prestashop. Under PHP 7.2 it gives those annoying count() warnings for the file cheque.php of the cheque module - even when it is not installed. When I checked it was still the Prestashop module. So I had a look at a fresh TB installation. It contains a /modules/cheque directory with a translations subdirectory. But it is not in my list of modules that I can install in the backoffice. So I am a bit puzzled how Thirty Bees is dealing with this module. Does it have such a module or not? If it has it would be nice when this PS version is overwritten during migration.

That depends on how you set up multishop. If you defined that every shop can have its own text then you won't be able to change that text when multistore is enabled.

You can look at the content of the returned Ajax call. When you have debug active that will contain somewhere in its text a php error. To do that go to the browser's console, chose Network, choose at the left side the Ajax call and then look at its content. See the attached picture.

I want to switch a webshop from Prestashop to Thirty Bees. One of the modules I need to replace charges the customer a fee for the use of Paypal. Unfortunately the search for a replacement isn't going very well. Alabaz wrote: "Thirty Bees is an ecommerce platform "based" on Prestashop but it is not Prestashop. What's more, Thirty Bees expectations for improvements are totally different from those that prestashop has foreseen, which is why it is a "bifurcation" (fork) of the original. If you wish we can budget you to adapt the module for this ecommerce." BestKit wrote the best option yet: unfortunately our module will not work with TB and this payment modules without manual adaptation. For this modules on TB we need to edit source code of payment modules and pass modified total (incl. fee/discount). We can't make clear estimation about this task, basic installation (including manually inserted code to modify total) we can do for free, but if you will not be satisfied with rounding, invoice view, admin order view all future changes will be handled for a fee only Does anybody use such modules on TB?

I read on another post: In 1.0.9 error reporting was revamped, and the display_errors php settings in dev mode was disabled. That means that the theme will work just fine on php7.2 (you will still see the warnings / notices in error log, but not in the page itself).  That doesn't sound like a solution to me. It will make you miss errors so that you can't solve them as soon as they appear and it makes development a lot more work as you need to download the error log each time you make a change. For me it will be reason enough to disable this feature and keep my own solution. I hope that it won't be too difficult to do that. Note that in PHP 7.4 or 7.5 the "each()" function will disappear and this 1.09 kludge will no longer work. The solution I proposed - on the other hand - will keep working. I use it in production and I haven't seen any signal yet of problems. Not on my site and also not on Stackoverflow. As for solutions with a new Smarty version: I have yet to see them working. Until now there isn't even a test version available. The idea of a inserting a new version with a switch back option (like PS 1.4) strikes me as a bit optimistic. I would rather start with a version where the old Smarty version is the default and the new is presented as a kind of "turbo" option. That way you avoid mixing up the existing TB-PS compatibility problems with those caused by the Smarty version incompatibilities. It is also a good way to get a better view on the problems that might be involved.

I found out that this happens when Windows reboots. When you close down or reboot Windows without closing the browser then it will remember which pages you had open and restore those after the restart. In that case Prestashop is restored correctly but Thirty Bees isn't.

Have a look at my tool Copy_Shopdata: https://www.prestashop.com/forums/topic/445453-copy-shopdata-script-for-copying-shop-content-for-upgrade/ It copies the business data but leaves the configuration data of the new installation untouched.

It is a well known problem that Panda's front office doesn't work with PHP 7.2 and debug enabled.

Try Prestools. It is free.

The most common error uploading themes is uploading a zip file that is not the theme but a collection of files - one of which is the theme. Did you check for that?

The usual questions: - what are you seeing in the url field of your browser/ - did you create a database. If you look at it now: has anything been inserted? - did you notice a javascript error? - did you see a php error in the error log of your server?

The only zero it can divide by is CompareSize. I don't know the code very well but my suggestion is to experiment with the (comparison)-period.

If it is a module or override you might find it with a text search - either for "order_history" - the relevant database table - or an api-function that could have been used.

I am not an expert in how to solve this kind of things as I don't know the details of how the software works. I hope someone else who knows will bring in something in. But I will indicate how I would approach the issue: - forget about the products. They are not a problem. You can always attach them to other categories. You can either access them with Prestools' product-solo or by editing another product in the TB backoffice and then changing the product id. - the challenge is to get a coherent tree of categories again. There are two ways to approach that. One is to ignore the unlinked categories. Just make them inactive and move all products attached to them elsewhere. And create new categories to replace them where needed. - a more risky strategy - that I am not certain of whether it will work - is recreating the missing link(s). For this you need to know which categories with which id's are missing. You will need to temporarily remove the auto-increase from the tbcategory table to insert it. And don't forget also to also insert records in tbcategorylang and tbcategory_shop. After you have done this you should immediately randomly insert a category in the shop in order to force it to implement the changes (nleft-nright if you are technical). - anyway: make a backup before you start. And start with just one change and then test whether everything works as it should.

If you have Prestools installed: can you run Integrity Checks? That has a check for categories without valid parents. It cannot repair it but then we at least know for sure what is wrong.

Did you trying emptying your cache?

@lesley said in Smarty and PHP 7.2: @musicmaster are you using any third party modules besides your own? Shipping modules? Real payment modules that connect via an api? These are the types of modules that we are having the most trouble out of. So while the core would be fine, who would use thirty bees if they could not use any 3rd party modules? At the moment I am busy setting up the main part of a shop. I expect to work on the modules next week. But I expect more problems from PS-TB differences than from PHP versions.

@drmasterchief said in Smarty and PHP 7.2: I read this with a lot of interested. But... do you really think every provider will cancel the support or will not offer hosting with PHP 7.0 and 7.1 in the next months? I dont think so. There are still thousands of offers with PHP 5.x with an separate support (without extra costs) for these hosting accounts. I am still using PHP 5.x for my actual webshop (not tb). Is there really such a hurry for PHP 7.2 ? imho i think PHP 7.1 will accompany us for the next 3-4 years without any problems at hosting ! I have seen myself several providers that upgraded from 5.6 to 7. Refusing was not an option. There are stories on the Prestashop forum about the issue too. Sure, if you look around you can still find another hosting provider that does support older PHP versions. But for many people moving a webshop to another provider is major operation. And even if you do everything right you can run into problems with the PHP setup of the new host. I I bet that a lot of people who are moving to TB now are people who are driven by these PHP version problems.

@datakick said in Smarty and PHP 7.2: @musicmaster said in Smarty and PHP 7.2: Do you experience any errors with php 7.2? Or is it just notices / deprecation warnings? I experience just the just those notices / deprecation warnings. I know enough about software not to be too afraid of where things will go. My point is that I need to recommend webshop software to customers and other people. And then it is a serious issue when I know that if I recommend Thirty Bees people will have a problem at the end of the year.

@datakick said in Smarty and PHP 7.2: On related note: we should also fix the debug mode. As I understand it, this whole thread is mostly about the warnings and notices that get mixed within HTML (and more importantly JSON) responses. These makes the site unusable. If we overhaul debug mode reporting to something from this millenium, this whole class of problems will cease to exists. For me the main point is the PHP 7.1 recommendation. I don't believe that it is a good idea to recommend people at this point of time to start a webshop with that PHP version. Within a year many of them will be automatically upgraded by their hosting provider to PHP 7.2. And as many people apply code changes instead of overrides - so that they cannot easily upgrade TB - that means that quite a few people will have a serious problem. Starting a webshop based on PHP 7.1 at this point of time is just a bad idea. Unfortunately I don't see much of a sense of urgency on this forum to fix this issue.

@steve said in I accidentally deleted the wrong files when I downgraded with XAMPP, can I still solve it?: Edit: got a duplicate bug, sorry! ????

Yes, clearing the cache and regenerating .htaccess

I don't want to check your vhost files for you. What I mean is that you should be able to see http://webshop/example.txt when you have that file placed at the location that "webshop" is supposed to link to.

That is nothing. You should be able to find a file in your file system back on webshop - and see a change on webshop when the file changes. Only then are you sure that the link is there where you believe it to be.

Start with the most basic thing: webshop. As long as you cannot access something on that domain speculating about .htaccess makes no sense.