musicmaster

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.

@lesley said in Smarty and PHP 7.2: The need for the button was to offer the later version of smarty that will likely break modules. A push forward so to speak. I don't believe that such a button is a solution. The number of incompatible modules and themes is too large - as far as I can see. And even when a shop might initially work with the new version it might break when the user installs a new module. Most webshop users know little about software and such a crash is for them an absolute taboo. I doubt that many module and theme makers will be prepared to adapt their software - given the still low visibility of Thirty Bees. Many will rather advise their customers to switch to Prestashop. Prestashop dropped Smarty and I believe that was the right decision. By giving up on backward compatibility Smarty proved itself an unreliable partner for the kind of ecosystem that Prestashop is. Of course sometimes software needs to break backward compatibility. But that should be done with a major new version and support for the old system should be maintained for some time. Smarty didn't do that. What guarantee do we have that they won't do the same again in the future? When you build a webshop you expect it to be around without major changes for at least three or four years. But on the TB forum people are advised to use PHP 7.1 - that won't be supported after 1 december 2019. Sometimes people are even advised to use PHP 7.0 - that is no longer supported. This is not right. I see not really an alternative to the kind of solution that I proposed in this post: keeping a compatible Smarty version (that means lower than 3.1.28 as far as I can see) and fixing it so that it runs under PHP 7.2. It is the only way to stay both compatible with the Prestashop 1.6 ecosystem and up-to-date with PHP. My solution was a proof of concept and other people may be able to improve it. But I see no alternative.

@the-rampage-rado said in Smarty and PHP 7.2: @musicmaster I like your attitude here! :D This is not a small issue. With the Panda theme you cannot access the front office under PHP 7.2 in development mode thanks to this little warning. Very likely it isn't the only theme with such a problem. Just a few months ago the announcements on the forum were that with the new year Thirty Bees would start supporting PHP 7.2. And now we are told that that will be implemented with a Smarty upgrade that will break backward compatibility - what isn't a real solution. The plan for Thirty Bees was that it would provide a vision for the future for all the people using Prestashop 1.6 who don't like 1.7. For the short term that meant improvement of the code (more speed, less bugs) and some extra features that provide a concrete incentive for migrating to TB. When enough users had joined would there be the step to TB 1.1 where TB implemented its own vision and gave up on complete backwards compatibility. The code improvement has gone well and is still going well. But the extra features that should seduce people to migrate are a bit of a problem. Elastic Search appeals to too few people. GDPR may never arrive. And now we are told that PHP 7.2 compatibility won't be what it had been suggested to be either.

You might copy the three smarty tables from a fresh install. You can also import the file I attached that contains those three tables. Anyway, clean the cache as soon as possible. 01546953434158lazy.zip

Updating to a PHP 7.2 compatible version of Smarty is the same as switching to another framework. By giving up on backward compatibility in 2015 Smarty abandoned users like Prestashop and Thirty Bees. Smarty has de facto been abandoned code since 2015. But software doesn't age so we happily have kept using it. With PHP 7.2 we have arrived at a point where one single line in the Smarty code gives a problem. We can now fix that little problem or declare such a fix taboo. Smarty itself doesn't maintain this code anymore. So we can feel free to do with it whatever we like. There will never be another update from the Smarty maintainers that might interfere with our fix. It is very nice that the latest Smarty version is better. But so are Twig and other template engines. Switching to each of them will have the same effect at the moment: it will kill Thirty Bees as it will leave it without supporting software. The argument that the code is fetched doesn't make sense to me. Nothing forbids us to include this code into our own code. Nobody will notice those extra 300K in a software package of 40M.

@traumflug said in Smarty and PHP 7.2: That said, such workarounds are pretty exactly what I'd like to avoid. The usage of each() you found is a bug and bugs can get solved by changing the buggy code. The PHP folks didn't introduce such warnings to annoy users, but to detect bugs and help eliminating them. The fact that a function is deprecated does not mean that it is a bug. The PHP people didn't abolish each() because it is buggy. They just found it a poor alternative for foreach(): slower and harder to read. And given that they wanted to clean up the language a bit it had to go. And if you look around the internet you will see that nearly every major software package used to contain it. Rewriting the Smarty code with foreach() is a nice ideal but I find their code a bit hard to understand. This was the only alternative to get things working. I find it a bit easy to call it a workaround. I rather see it as risk-averse: given how complicated this piece of their code is it is very easy to get unwanted side effects when you try to restructure it. Just replacing this function minimizes that risk. But of course I will welcome it when at some point in the future some genius manages to restructure this code the "proper" way. I don't believe upgrading Smarty to a PHP 7.2 compatible version is a viable alternative for TB at the moment. It will break compatibility with almost all the code that was written for Prestashop. And the quality of the error messages means that that is almost impossible to fix.

I have been looking how I could run my TB 1.08 on PHP 7.2 without those annoying warnings. My first step was looking for the highest Smarty version that worked with my shop. It was 3.1.27. Next I looked at the warning that got. I searched the code but there is only one instance of "each()" in it. I found on internet a "myEach()" function that should be able to emulate each() and implemented it. Attached is the resulting code. Only the file /libs/sysplugins/smartyinternalcompilebase.php has been changed from the default 3.1.27. The code comes under the /vendor/smarty directory of the shop. As far as I can see it works. Can other people test it? 01546705970018smarty.zip Follow up: it looks like the version-update wasn't a good idea. It seemed to give hangup problems when run under PHP 7.2. However, the modification of smarty_internal_compilebase.php seems to work well. See below. smarty_internal_compilebase.zip

When you want to debug javascript errors your first step should be to disable minimization (the CCC functions). As far as I can see you didn't do that. Always start with the first error message. In your first picture that is iris.min.js. That doesn't look like a TB file. If you move your mouse over the filename in the console you see its full path and say something about to which module it belongs. ERRBLOCKEDBY _CLIENT most likely means that some addblocker or anti-malware software that you installed blocked a file.

@rubben1985 said in error 500 when activating debug mode: anyone with programming knowledge can tell me if I did something wrong with the code I introduced in the validate file? (code was to make work a module). In the actual state when I activate debug, site breaks so I can not use it but I need the code inside the file (but maybe I made something wrong even if the module now it works) No way anyone can tell you how that will work out. Both functions that you have added include an external file that you haven't added.

It might be that DO had to redo things for Ubuntu 18.04. I set this droplet up two months ago and probably since then they repaired some bugs (in my install there was no Mysql password). I used to prefer Virtualmin but the fact that nowadays they don't even activate php reduced my trust. One curious question: I understand that my pretty url's did not work without overrides enabled. But what puzzles me is that on the homepage most of the images (80% at least) were shown correctly despite being a pretty url. How could that be?

Thanks for the tip. As a tip from me: your blogpost on installing TB on DO doesn't mention this allowoverride stuff (or that you need to add modrewrite for it). It might be good to add it.

Thanks, that fixed it.

@lesley said in Product links don't work: Not overrides in your installation allow overrides in apache, https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride Sorry, this evades me. I thought we talked about TB/PS overrides and suddenly you refer to Apache overrides. What is your point? Is there something wrong with my Apache configuration?

Localhost is on php 5.7. The servercode is a copy of the localhost code. Both have overrides enabled.