musicmaster

Are you under Windows?

What is your php version?

There is also an option to do it without using the schema. In pseudocode: select * from ps_order_state limit 1 $row = mysqli_fetch_array() if(isset($row["active"])) ...

Isn't it a better solution to use SHOW COLUMNS? Something like: 'show columns from ps_order_state where field="active"'?

Thank you for the explanation.

This problem happened when I pressed "My Shop" in the back office. I got the screen below - the home page with an error on top. This happened in the new 1.1 version. One thing to note it that if you look good you see that the cart contains zero items. After I refreshed the page - as the error suggests - the cart contained one product. It should be noted that this is a product with combinations. I checked the javascript console but didn't see any errors. I probably added that product yesterday but I don't remember all the details of what I did then.

This is not just about analytics. The consequence of this error is that lower on the page the productscategory and crossselling modules show only the name of the products and not their picture:

You can use Prestools for that. The function Attribute List in the menu. Prestools is free.

When online (not on localhost) I get the error "MBG is not defined" on my product pages (not on the category pages). This error is caused by Google Analytics. But I have no idea where to look for the problem. This is with the new 1.1 version.

When I make a bankwire payment in the new 1.1 version the next screen is an error screen that there is a query for a column "active" in the table ps_order_state. Indeed when I checked this column doesn't exist in this table. When I look at the code it seems that this is some kind of coreupdater check that is done for many tables and goes wrong here. I "solved" the problem by manually adding an active field to this table. When I checked on my server - where I had started with a direct payment instead of bankwire - I noticed that the system had added there an active field by itself.

I found exactly the same problem with the Panda template. Note that it doesn't happen in all configurations. In a fresh installation with only the default carriers I didn't see the problem. However, In a live shop with installed carriers I did see it. That isn't strange when you how deep the routine is in the code.

Previously your error message was: Property Order->total_discounts is not valid The purpose of my improvement was to show after that message the content of that total_discounts variable. You didn't show that content in your last post. Even if it was empty at least the dash (-) would be shown.

You need two changes in /modules/coreupdater/classes/GitUpdate.php. In both cases you check whether the first char of $adminDir is a backslash and if so you remove it: In the function downloadFileList() (around line 425) the following part will be changed: $fileList = false; if ($response) { $fileList = []; $adminDir = false; if (defined('_PS_ADMIN_DIR_')) { $adminDir = str_replace(_PS_ROOT_DIR_, '', _PS_ADMIN_DIR_); if($adminDir[0] == "\\") $adminDir = substr($adminDir,1); /* new */ $adminDir = trim($adminDir, '/').'/'; } The beginning of the function downloadFiles() (around line 870) will become: protected function downloadFiles() { $adminDir = false; if (defined('_PS_ADMIN_DIR_')) { $adminDir = str_replace(_PS_ROOT_DIR_, '', _PS_ADMIN_DIR_); if($adminDir[0] == "\\") $adminDir = substr($adminDir,1); /* new */ $adminDir = trim($adminDir, '/').'/'; }

That looks like the html was entered in something like TinyMCE and converted by the program.

I saw there was a dot missing in my code: now repaired.

<p><p>text</p></p> is perfectly legal html and shouldn't show the second p as unprocessed html. I assume PC149Y comes from the description or short description field and those fields are enclosed by <p> Of course this is easy to work around. But the root of the problem is a riddle for me.

Some thoughts on debugging this: - the "total_discounts" field for the order is checked for being a float and that check fails. - so it is interesting to know what its contents is. - to see that you can change line 1037 to throw new PrestaShopException($message." - ".$this->$field);

As far as I know this can only be done the "dirty" way. You can add some text to config.inc.php at around line 50 that looks like if($_SERVER['REQUEST_URI'] == ....) header('Location: https://www.mynewsite.nl/jewelry'); It becomes a bit more complicated to also redirect the products but I assume you can improvise that yourself.

You have two options. If you want to bring the images there you should take care of the image https://terresebrekm0.com/img/p/9/4/94.jpg All image formats (like 94-home_default.jpg) are derived from this image when you regenerate the images. The other option is to let Thirty Bees do the work and assign the image id numbers. In that case you should just copy all images to a folder and link to them with a full url in your csv file. I usually make a tmp folder and copy them there.

Let me take one product as an example: Alcachofa It has product id 11 and an image with image id 94. It is one of missing images. Only the demo product images are present. The full url of the image is https://terresebrekm0.com/img/p/9/4/94-small_default.jpg?time=1563174516522 The logical next step would be to look on the harddisk (or with ftp) to see what images are present in the https://terresebrekm0.com/img/p/9/4/ directory. As far as I can see there is nothing there - what would be problematic.

Pretty (or friendly - or whatever you call them) url's is basic stuff. You really need to invest some time to understand what you are doing. When there is no .htaccess you get the natural urls. They look something like www.myshop.com?id_product=123 or www.myshop.com?id_category=45 (it may be a bit different as it is a long time ago that I have seen them...). Also the links for your pictures become something like www.myshop.com/img/p/7/8/9/789_home-default.jpg. Pretty urls are just what the name implies: varnish. They allow you to write www.myshop.com/widget instead of www.myshop.com?id_product=123. The .htaccess file serves as a kind of translation table that makes sure that behind the screens www.myshop.com?id_product=123 is called when you just typed www.myshop.com/widget. So when you enable or disable pretty urls you should always clean the cache and start at the home page as all the internal links of the shop will be different too. Now back to your pictures. The first thing we need to know is what file is looked up and whether it is there or not. That is a lot easier to do when you see a real link to the picture than when you see some kind of pretty url that is translated somewhere mysteriously behind the screens.

Did you also regenerate .htaccess (in SEO&urls)? If that doesn't work the next step would be to disable pretty urls and look what happens.

You need to regenerate the images.

Just provide an url in your csv file and make sure that the image are reachable there.

Tried to install it today: Constants may only evaluate to scalar values I am still on php 5.6 so that may be a problem. Something different. Just curious. TB 1.1 has a lot of new hooks. Prestashop 1.7.6 has 200+ new hooks too. Is there any coordination?