musicmaster

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.

I believe it to be a very big mistake to make core files dependent on modules. This was not an error of my database. I can't see a reason why it would consider a module installed of which it never had heard.

@traumflug said in Yet another 1.08 bug: You experienced thirty bees self-healing magic :-) Maybe it was a stale cache somewhere. Should it happen again, please look up back office -> Advanced Parameters -> Configuration Information. This lists, among other stuff, changed and missing files. Thank you for your reaction. Nice to hear that I can find something under configuration information. But I much prefer the previous situation where I could see which object was missing. Now I can't see that - not even under development mode. Neither in an error log.

Strange. This bug resolved itself. I no longer have it.

Having solved the vatnumber bug I already have the following bug in my upgraded 1.08 installation. When I go in the backoffice to Customer service I get an "Object not found" error. I tried a fresh 1.08 installation and there it works. Unfortunately Develop mode doesn't work here.

@yaniv14 said in A mail problem: Are you able to send emails from command line, like: "sendmail youremail@com" -> enter -> "some text" -> ctrl+d? When I try that I get the following in mail.log. host smtp.secureserver.net[72.167.238.29] refused to talk to me: 554 p3plibsmtp01-13.prod.phx3.secureserver.net bizsmtp IB103. Connection refused. 82.196.3.125 has a poor reputation on Cloudmark Sender Intelligence (CSI). Please visit http://csi.cloudmark.com/reset-request/?ip=82.196.3.125 to request a delisting.

I upgraded my shop from 1.04 to 1.08. Now when in the backoffice I want to look at an individual order I get halfway the page an error: Fatal error: requireonce(): Failed opening required '/home/xxxxxx/publichtml/modules//vatnumber/VATNumberTaxManager.php' (includepath='/home/xxxxxx/publichtml/vendor/pear/archivetar:/home/xxxxxx/publichtml/vendor/pear/consolegetopt:/home/xxxxxx/publichtml/vendor/pear/pear-core-minimal/src:/home/xxxxxx/publichtml/vendor/pear/pearexception:.:/usr/share/php') in /home/xxxxxx/public_html/classes/Product.php on line 668 The orders overview page works ok. But when you want to edit an individual order you get a page that looks like the css hasn't loaded. When you scroll down you see the error message that you see above. One suspect thing are the two slashes between "modules" and "vatnumber". On closer inspection this isn't a problem. There are four files where erroneously a slash is used after the PSMODULEDIR constant. But things still work. The real problem is that the vatnumber module wasn't installed yet it was required. After I installed the module the problem was solved. In my opinion it is a mistake to make this a module when it is called from core files like product.php.

@yaniv14 said in A mail problem: So from what I understand you are sending mails from your server with phpmail. Sure, that is what Thirty Bees/Prestashop always does. DO won't block your ports unless you have some spams or something worst coming out from your server, and they will probably inform you about it. They haven't notified me. And I wonder whether you can notice that in your mail log (one of my previous questions). Did you try something simple like restarting postfix or checking that its active? I tried a lot. Like rebooting and even upgrading the server and TB. I noticed that with sending to a Gmail address I get a different message: "This message does not have authentication information or fails to pass 550-5.7.1 authentication checks." The result is still the same.

I am using Postfix. I checked mail.log. It has 17000 lines for just three days. Lots of "SASL LOGIN authentication failed" and an occasional timeout. But I see the same with another server that still works. Isn't it possible to set up things so that external login is impossible and only php scripts can access the mail server? Anyway, I looked for some of my test mails in the log and found the error message "Client host rejected: cannot find your reverse hostname". Looking this up I found that this is about MX records. And indeed I haven't set a MX record in DO. However, neither do I have that with the other server and neither did I have that in the past. I suppose that these log file entries mean that it isn't DO that blocks me. Or am I wrong?

I have a little problem with my webshop: suddenly it doesn't send emails anymore. The test-mail doesn't work, the notification don't work and mails that customers wrote in the contact form aren't forwarded either. I strongly suspect that it is not the webshop but the server. But I haven't made recent changes and I have no idea what could have caused the problem. It is a self managed server at DO so it can't be the hosting provider. Does anyone have a suggestion how I could try to solve this problem?

I can make nothing from those pictures. The texts are too small to read and nowhere it is indicated where on those huge pictures we should look. As Traumflug said, please supply urls and category names. The obvious step for solving this kind of problem is looking for similarities that discern bad from good dysfunctional parent categories. But you don't provide enough information to do that. Also, did you try to rename parent categories?

Hi Angstony, Prestools doesn't move favicons. And the fact that Prestools picks up the favicon of your main shop says nothing about which database Prestools is working on. It is just a function of your browser and server. You can easily check which database Prestools is working on by making some innocent change (like a minor text change) and looking in which shop it appears. There have in the past been some problems with two shops on the same server but these were fixed at that time. Just for your information the technical side: Prestools looks for your TB settings file in the config directory and it uses that to access the database. Almost all operations of Prestools access only the database. This looking for the settings file happens in the function connecttodatabase() in login1.php.

You might have a look at the config file of my free script Copy_shopdata: https://www.prestashop.com/forums/topic/445453-copy-shopdata-script-for-copying-shop-content-for-upgrade/ It is really a long list. Going from multi to single store shouldn't be a problem. You should watch out for language id conflicts. And for maintaining passwords it is necessary that you maintain the same keys in the config file. If you get unique key errors you didn't make the transit from 1.6.0 to 1.6.1 the right way. These are just some remarks for inspiration. You can try to use the script. And otherwise you can try posting details of your problems. "Strange results" is a bit vague.

I would love to see this "module" released from its composer encapsulation so that it becomes easier to see how much of the job is done and what still needs attention.

I think the more effort you put in it the better it goes: - adding a feature is basically just one sql line like: INSERT INTO psfeatureproduct SET idproduct='113',idfeature='18',idfeaturevalue='810' - the point is of course that you need to know the numbers. If you have a table that links "black" to feature "18" and feature_value "810" then it is simple. - the thing to watch for is conflicting values. If you try to assign the same color twice or a different color to something that already has a color assigned you will get an error. - with such a table and a bit of php you could achieve what you want.

I will have to think about that. If I have an idea I will let you know.