musicmaster

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.

This is PHP 7.2. Could that be a problem?

The funny thing: all this is working on my localhost, but not on the server. I have refreshed the .htaccess many times but it just doesn't have an effect.

I want to keep the Prestashop linking system. So I copied the link descriptions from my Prestashop installation (see attached picture). But it doesn't work. Neither the category links (like http://www.bilbil.com/34-chocolade), nor the product links (like http://www.bilbil.com/geslaagd/155-snoepblik-geslaagd.html) work. They result in 404s. In addition I have a problem that on my home page some pictures show the file-not-found image. But they do have an image and I can't get the image to show. Take for example http://www.bilbil.com/5722-homedefault/chocolade-munten-50-gram.jpg. This should refer to http://www.bilbil.com/img/p/5/7/2/2/5722-homedefault.jpg. But that image is there and the "pretty url" not.

I will look whether I can make this somehow reproducible. At the moment I can't find the key.

As soon as I refresh the page it is normal. Somehow TB does not preserve its css file in circumstances where PS does so.

I mean that I regularly see my TB pages as below. And that that never happens with a Prestashop installation.

When I reboot my computer and the browser comes up again I will see the webshop under Prestashop as I left it. However, the same webshop under Thirty Bees will look as if the CSS file wasn't loaded. Is there a way to fix this?

@fabsca said in thirty bees Fatal error: no UTF-8 support. Please check your server configuration.: . Or is it a TB problem? If you search the internet for "Fatal error: no UTF-8 support. Please check your server configuration" you will see that it is quite common with Prestashop too and has to do with server restrictions.

Did you fix the ElasticSearch bug that is mentioned here: https://forum.thirtybees.com/topic/2395/update-to-1-0-8-shows-500-server-error/9

In de psorderdetail tabel worden zowel prijzen met als zonder btw opgeslagen. Dus veel win je niet met het aanmaken van een nieuwe tax id. Aan de andere is het ook niet veel werk zo'n nieuwe belasting id te implementeren. Je krijgt zoiets als update psproduct set idtaxrulesgroup=6 where idtaxrulesgroup=2 Waarbij de waarden bij jouw natuurlijk anders kunnen liggen en je ook psproduct_shop moet updaten...

In de backoffice ga je naar Localisatie->Belastingen en pas je het tarief aan. Daarvoor hoef je niet rechtstreeks in de database bezig te gaan.

Ervan uitgaand dat je de prijzen inclusief btw gelijk wilt houden moet je de prijzen excl btw met 106/109 = 0.97247706 vermenigvuldigen. Prestashop slaat alleen de prijs excl btw op dus die moet je veranderen. Je kunt dat rechtstreeks in de database of met Prestools doen. Let wel op dat je geen producten met 21% btw meeneemt.

Oplossing gevonden. Op twee plekken heeft MyParcel ook een spatie voor de keynaam. Laten we hopen dat dit incidenten zijn (Myparcel en Elasticsearch hebben dezelfde auteur). Het is niet echt handig als TB door strengere eisen kunstmatige incompatibiliteit creeert.

Bij mij is alles "vol". Eén product is genoeg. Toen ik mijn eerste product in de mand deed kreeg ik een Xhr error en elke verversing van de pagina daarna geeft een crash. Zodra ik MyParcel uitzet is die weg.

Bij mij niet. Daarom heb ik de upgrade naar 2.2.1 gedaan. Heb je getest met een volle winkelmand?

It turned out that I hadn't adapted my host name (nano /etc/hostname). DO as a default copies the name of the droplet as hostname. But if you haven't adapted it such a name looks like "ubuntu-2gb-ams2-01" (much longer with installed software) and it seems that those dashes are problematic.

I just reported the same [ PSCURRENCYDEFAULT] is not a valid configuration key at line 1005 in file classes/Configuration.php error in the Dutch forum. I have attached the module - a Dutch carrier module - file there. The error happens at the frontside when there is something in the shopping cart. https://forum.thirtybees.com/topic/2402/myparcel-met-tb-1-08-geeft-problemen I don't use Elastic Search

Voor de compleetheid: hier de module: 01545858730253myparcel.zip En hier de Github: https://github.com/myparcelnl/prestashop

Als ik de Myparcel module (laatste versie 2.2.1) installeer op TB 1.08 krijg ik in de frontoffice een error zodra ik iets in de winkelmand stop. [ PSCURRENCYDEFAULT] is geen geldige configuratiesleutel at line 1005 in file classes/Configuration.php

I don't understand that law either. The site says that transport materials are excluded. But what about the normal packaging. Many webshops here have two or three orders a year from Germany....

@traumflug said in Yet another 1.08 bug: Maybe it was a stale cache somewhere. The "healing" took place when I opened the page on a different computer. So it might indeed be some remnant.

Might it be an idea to change this error reporting? The error came from line 848 of AdminController.php. That says: $this->errors[] = Tools::displayError('The object cannot be loaded (or found)'); What about replacing it with: if (PSMODEDEV === true) $this->errors[] = Tools::displayError('The object ".$this->className." cannot be loaded (or found)'); else $this->errors[] = Tools::displayError('The object cannot be loaded (or found)'); It would be still better if you also saw the calling stack.