musicmaster

Does anyone know how to program the mobile hamburger menu button under the Panda template?

I used to have such a thing with Prestashop 1.5. It probably was related to my template. Anyway, I got used to emptying the cache every time I changed the products on the front page. I haven't seen this problem with Thirty Bees.

Are you sure these are all your console errors/warnings? It takes only one unrelated javascript problem and then jQuery isn't loaded and you get all these follow-up errors. With javascript errors you should always look at the oldest first. All the rest can be follow-up errors caused by the first one.

When Jquery doesn't work it is usually because there was a javascript error before it was supposed to be loaded. So I am very curious how your javascript console looks.

I can't recommend a specific module. But I can give you a few considerations: - you have three kinds of attributes. You have attributes that don't affect the stock, such a whether a piece of furniture is polished. You have attributes that have their own stock, such as hard disks when you sell computers. And you have attributes that define a unique type of product. It is the last type that Thirty Bees/Prestashop standard supports. - so when you buy a module you should check which of the other types it supports and whether that fits your situation. - if you want to make a do-it-yourself solution for attributes that don't affect stock you can consider using the customization field.

First of all you should enable debug mode so that you can see which error is the real problem. You mention some errors in the log file, but it is unclear whether they are happening now when you refresh a page or happened somewhere in the past. https://www.prestashop.com/forums/topic/224525-how-to-turn-on-error-reporting-for-debug-information-blank-page-500-internal-server-error/ Besides that I would suggest disabling all non-TB modules. (you can use Prestools for that). If decoding the error message indicates some problematic module you can also disable that by renaming it. It is a crude method but it will at least give you access to the backoffice.

It could be just some local prosecutor who took the initiative. And he may well have been bribed to do so. Most likely we will first see some judicial fights inside Russia - with a lot more people getting involved. If that goes against Nginx the next step will be international. But we still don't know what Rambler wants. Do they really plan to go after the end users or are they just hoping to get some money from Nginx Inc?

Is it possible to duplicate orders? I thought there was an option. But I can't find it anywhere.

I have some troubles with MyParcel. We are using version 2.2.1 at the moment. The problem is that sometimes MyParcel empties the address (just the street and number). The customer has filled them in correctly and they are correctly in the TB_address table. But in the copy of the address in the tb_myparcel_delivery_option table the "street" and "number" fields are left empty sometimes. Postal code and town are always there. Note that the address data are stores in a json structure in the myparcel_delivery_option field. This table has address fields but those are not used (and in the 2.3.6 version removed). On the basis of just a few samples one possible explanation is that the address2 field is the problem. In all the three failed samples I got this field was filled. In two cases the number was in address2. In the third case the number was in address1 but address2 was filled with "hs". Some comment in the code suggests that the number must be in address1. The latest MyParcel version is 2.3.6. So I tried to upgrade in the hope that the newer version might have solved the problem. But after the upgrade my backoffice crashes when I want to look at the orders page. I get the error: "Table 'myshop.tb_myparcel_goods_nomenclature' doesn't exist". Some research indicated that when I install the 2.3.6 module over the 2.2.1 module the upgrade files (like Upgrade-2.3.0.php) that should create the extra tables are never executed. Things got even stranger when I had a look at a fresh 2.3.6 installation (on Prestashop 1.6) and saw that although the tb_myparcel_goods_nomenclature table is declared in the code it is not created. However, for the rest the database structure is quite different from 2.2.1. Does anyone here have experience with either this missing address problem or upgrading? myparcel-v2.2.1.zip myparcel-v2.3.6.zip

After you disable pretty urls (and cleanse the cache!) you have direct links to the images. So they should be there. And if there aren't there you can look in the html source in your browser and follow the link.

If I sounded harsh I apologize. I am just getting desperate. Jonny is helping. But I am amazed by the extent of the upgrade. I adopted Panda 1.5 because I had to for TB 1.1. But this is much more than a few fixes under the hood. And that means extra work for me. MyParcel will not help. Smartlook sounds nice. But as developer I don't have contact with the customers. And to mobilize the commercial people in between is difficult. Not so sure about this. There is nothing wrong with having (clearly marked) routines in software to guarantee backward compatibility. Prestashop 1.6 is full of it - much of which was removed by Thirty Bees. I see such support as a show that you care about the community that uses your software. To assume that software providers will happily jump in to fix things sounds unrealistic to me. Some software is no longer supported - either because the developer stopped or because he focuses on PS 1.7. And Thirty Bees doesn't have the market share that will convince many developers with commercial arguments. I am now maintaining a website that was maintained for some time by a company specialized in Prestashop. They added code written for Prestashop. And I now have to live with that. That is the reality we live in: you are either compatible with Prestashop or not. You cannot pick things where you want to be compatible - specially not when the user only can find out when you are not the hard way: by in depth debugging.

I saw that Prestashop is planning for 1.7.7 to "upgrading all the outdated jQuery versions to the latest version in all stacks without introducing breaking changes, thanks to jQuery migrate". Could that be an idea for Thirty Bees too?

Today I had a talk with a customer. The verdict of our TB 1.1 Bleeding Edge with Panda was rather negative: - persistent problems with the MyParcel carrier module that sometimes doesn't transfer the right address data to its fields. The MyParcel module - still maintained by Michael Dekker - officially is only supported up to TB 1.04. - regular complaints of customers who cannot complete their orders. As I am several steps away from the process I still don't know the exact problem. But I suspect that the out-of-stock problem I mentioned in my previous comment in this thread plays a role in at least some of them. - problems with the Panda layout - specially with mobile. Still not sure whether my own legacy code plays a role. Sometimes I get the feeling that I see a replay of the adoption of Prestashop 1.7 with Thirty Bees. With Thirty Bees too all kinds of changes are made to "modernize" the code. And it looks like that in TB too that leads almost inevitably to bugs. The way things go at Thirty Bees is not the way I had hoped the project would work. All kinds of changes are made in the code without communication. Even the introduction of a new version is not accompanied by some statement what has been changed. I miss any kind of plan or vision - even for the short term. I have always believed that Thirty Bees should stay close to the PS 1.6 standards for a very long time. I even believe that Thirty Bees should make tools available that enhance PS 1.6. Its survival is in its interest. Unfortunately I get the impression that the TB team is rather eager to give up compatibility with Prestashop. I found it frightening to see that SunnyToo felt compelled to bring out a new "TB 1.1 compatible" version of Panda. What does that mean for the compatibility of Prestashop themes? I haven't yet given up on TB. But if I can't get my problems fixed I may be forced to do so.

Very likely something is going wrong in one of the many product related database tables. I recently had a problem where groups where not allocated. In your case something similar might happen. The only way to find out is by having a very good look at your database. If you pm me credential I could do that for you.

I am still on the bleeding edge of a few weeks ago. One serious bug that I encounter - but haven't pinned down enough to make an error report is that I regularly see "out-of-stock" messages during the checkout. This despite the fact that this is a shop without stock keeping. What makes it complicated is that this happens only with a minority of the products with a sub-zero stock. As I haven't heard of this problem being addressed I thought it should be mentioned here.

It is hard to do it in the files as they don't contain the original text but only some hash. For me and most people translations work ok. The only annoying thing is that you need translate a word like "order" dozens of times - once for each place where it is present in the code. I have been considering writing something for it in Prestools but it has low priority. If you have a problem that when you translate some text at some location and that translation is later reverted it would help if you could provide a concrete example. Only with such reports people can try to reproduce your problem.

My experience is that webshops tend to recover spontaneously from the problem after a week or two. The internet is full of ideas what can be done: disable mod_security setting, change some settings in configuration table (PS_COOKIE_LIFETIME_BO,PS_COOKIE_CHECKIP,"PS_CIPHER_ALGORITHM"), check ps_shop_url, make changes in ps_advice table, change theme, switch off multiviews. The Prestashop forum is full of ideas. Just search and experiment.

Your story leaves me puzzled in several ways: - if you have a problem you start with what you have. In this case there were blank screens. That is how php errors usually look with debug mode off. But you can look in the error log of the server. - you are talking about an error. But the point of the "admin login loop" is that there is no error. If your password was correct you don't get any error message at all: you are just redirected to the login page. But as you don't describe your "error" we are left in the dark here. - the first suspects with problems are always third party modules and overrides. You can switch them off in the backoffice.

I just noticed that this is also a problem when editing a customer. Now I need to check all customers too...

I just noticed that when editing a customer in the backoffice the company name field is missing. Am I overlooking something?

With a tool like Winmerge you can compare whole directory trees. And you can also rather easily the content of the differences. Only problem is that the compared trees have to be on the same (Windows) system.

I once considered making such a thing for Prestools. But I discarded the idea when I saw how Prestashop constantly changed the database structure - the indexes the most. Even core indexes were sometimes different - as an extra field was included. As many of those database variations will be maintained in shops moving to Thirty Bees my expectation is that you will see a wide variety of structures and most of those differences will be irrelevant. My suggestion would be to divide the output in three categories: - the really critical: missing tables, fields, indexes and field properties. The user should be recommended to fix these. - the potentially problematic, such as the NOT NULL field you mentioned. The user should be recommended to fix those only if there are problems and he has checked that they aren't used by some module. - the nearly certainly innocent - such as id fields with length 10 instead of 11. Making a dump of the repaired tables might help when things go wrong.

I like the idea. But I have doubts about the proposed implementation. In my experience missing tables, indexes and auto-increases are the main source of problems. The chance that fixing them will cause problems is small. But extra fields and fields that are bigger than default are a different story. Those are usually implemented for a reason and encouraging users to undo them might easily damage the working of modules. Panda has an extra "hover" field in the tb_image table and I have implemented a change in the tb_feature_value_lang table that allows you to enter more than 255 bytes. I wouldn't want someone who maintains my websites when I am on holiday to fix those "critical" "problems".

That makes no difference.

When in the backoffice menu I access the option "Invoices" (the second option in the orders menu) I get an "access denied" error screen. After some research I found that the error came from Eolia's GDPR compliancy module (v2.0.6). The funny thing is this module was installed but not enabled. There was an override connected to this module (classes/Module.php) but deleting this made no difference. Only uninstalling this module allowed me to access this functionality. Why is a not enabled module having such an effect?