musicmaster

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.

As far as I know there are only three options that can produce this result: - something is wrong with your setting for "webhost". You have added your own settings in addition to "localhost" and something there may be wrong - an .htaccess is redirecting the link so that it doesn't work. It might be on any level. - some anti-malware program is blocking Prestools. Put some textfile (example.txt) i the root of your shop and see if you can access that with the browser.

@steve said in I accidentally deleted the wrong files when I downgraded with XAMPP, can I still solve it?: I also can't access that login page. (I navigate to http://webshop/admin169x8dwpn/rescue/login1.php) Does TB know what admin folder I'm using if I copied it from an older store like I said before? What do you mean "can't access"? What do you get? You should always be able to have access as long as the database connection is good. @steve said in I accidentally deleted the wrong files when I downgraded with XAMPP, can I still solve it?: Can I install a fresh copy of TB and copy all the unique files (my theme, modules etc) And then also copy over the DB again? Are my settings in those files or is eveything on default again? See my previous question. You are "repairing" things that most likely aren't broke and may in the process introduce new problems.

@lesley said in Smarty and PHP 7.2: Just curious, what percent of non thirty bees maintained modules do you think work with php 7.3? No idea. But the changes seem more esoteric as with 7.2. Each() and Count() are very common. @traumflug said in Smarty and PHP 7.2: Whenever there is a problem we recommend people to switch on development mode. That is not possible for those people [using PHP 7.2]. It is. I run PHP 7.2 myself and get this many times a day. A box with the error report appears (created by xdebug) and if this box gets into the way, one simply reloads the page. These Smarty errors happen during template compilation and once a template is cached, the box no longer appears. Not sure how things appear visually without xdebug, but it certainly works. The average webshop owner is not a computer specialist but a commercial person who knows just enough about software. He will install TB on PHP 7.1 - as advised - and at the end of this year be unpleasantly surprised when his hosting provider announces that his account will be upgraded to PHP 7.2. It is very nice that you know how get around the Smarty error. But how many of the people developing with their Panda theme (that advises to set the switch to "always recompile" while developing) will find that too? Webshop software is a thing that should work out of the box.

The .htaccess in the root of your shop. You can use Prestools to delete the cache (under Shop Rescue).

Try deleting .htacces (you can regenerate it later). If that doesn't help: delete the cache.

Did you have a look at the content of the file? Some 200 times this comment: -- Tabelstructuur voor tabel tb_access -- Fout bij lezen van tabelstructuur van tabel webshop.tbaccess: #1932 - Table 'webshop.tbaccess' doesn't exist in engine -- Fout bij het lezen van gegevens voor tabel webshop.tb_access: #1064 - Er is iets fout in de gebruikte syntax bij 'FROM webshop.tb_access' in regel 1 You will need an older sql file to achieve anything.

My impression is that it has something to with the way you transported the database. Normally you should transport databases by exporting and importing an sql file. Instead you transported the files. Probably something has gone wrong there. You can try mysql's repair functions. But I am afraid the problem lies deeper.

configuration is usually the first table consulted. So I doubt that there is any table at all. Did you do the tests in phpmyadmin I asked?

Nothing unique. You can copy all those directories from a fresh install of TB of the same version.

The sql I sent contains a create command for this table. So you might have a look in phpmyadmin whether there is such a table or not. And if there isn't you might try in the SQL console of phpmyadmin whether you can create a table from there. If you aren't one possibility is that you don't have writing in the mysql/data directory. Of course it might also be another rights problem.

@traumflug said in Smarty and PHP 7.2: @musicmaster, would you please stop spreading fear here? thirty bees supports PHP 7.2 already. With development mode turned off, which is (hopefully) true for any production shop, it works just fine. Really? Then why recommends the documentation maximal PHP 7.1 - what I also see recommended many times on the forum. Whenever there is a problem we recommend people to switch on development mode. That is not possible for those people. So I believe this is not a thing you can easily discard. It is very nice that some smart people are even able to run TB on PHP 7.3. But what I am talking about is what the common webshop owner gets "out of the box". That should work. Period. And it shouldn't be that entirely predictable bugs force him to the forum to get a solution (most people will just jump to WooCommerce or another package). And it should work with PHP 7.2 as otherwise he will within a year find himself with an outdated shop. So if you have a solution that works now: fine. Please implement it! But if its is still all still in development and will take some time please implement my "kludge" so that TB users can safely use PHP 7.2 now. You can always later implement the system you prefer. But don't give the users half-finished products with the promise that you will fix it when they find a problem. That is really implementing "kludges".

@steve said in I accidentally deleted the wrong files when I downgraded with XAMPP, can I still solve it?: @musicmaster I can't download your attachment. I have replaced the file with a zip.