musicmaster

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?

While entering prices in the backoffice I encountered the following little issue: This shop is only in euro's. Yet the prices are quoted as "USD 1.99 €". Does anyone know where this USD comes from?

Unfortunately this is not an option on this server. I tried changing the image a bit but that didn't have any effect.

I have the problem that my logo keeps being deleted. I have uploaded it many times but usually it disappears after a few hours. The file - with a name like mysite-logo-1546274668.jpg - matches the template name {$logo_url}. I solved it for the website by hard coding another url in header.tpl. However, the pdf files are harder to solve in a neat way. They want a local path from the root of the harddisk - not an url - and I can't find a template variable that provides that. I tried replacing the extension in the filename but it looks like there is some check for the existence of the file. So {$logo_path} - as it is called in the pdfs - is empty when the image isn't there. So my questions are: - what could be deleting my logo? - how can I refer to images in the pdf header? I am running Panda 1.5.2 (the latest version) on the bleeding edge of two weeks ago.

One thing I have considered - but I believe should be done with direct access to the backoffice - is price calculation. You should enter a cart number or an order number and see a complete explanation of how the pricing is processed and what system settings play a role. The script should both make its own calculations and retrieve the values that the TB functions have calculated. Rounding questions regularly come back on the forums and with such a functionality people could provide a screendump with all the relevant information.

Nice initiative. With the Integrity Checks page in Prestools I provide some consistency checks too. Feel free to copy.

Depends on what you want. You can make multishop as complicated as you want. The same applies to ASM. There is no limit to complexity of the needs of some customers. For some even Magento needs to be heavily customized. My motto would be: pick your fights. Make a deliberate choice what you want to include and what not. And don't include something just because one customer asked for it. If you don't want to support features you can always choose to leave them in the database but to make them inaccessible in the software interface.

For Prestools I reverse engineer things and I found several times that Prestashop had implemented things more simple than I had expected from looking at the database. I can't remember concrete examples but you should expect more of this kind of issues. Note also that the great majority of the shops are not multishop. For them all those extra checks make the code just more complicated and slower.

Quite a good guess. After some search I found that the origin of the first of the two queries was the Order.php override file from Greenmouse's gmnumeric. However, the real cause appeared to be a faulty import. There were orders in the database but the auto-increase index was zero.

About the other error: the order that cannot be submitted. Here is how a timeout looks: I put some code in it to see what queries are processed. The first 152 queries look to be normal processing. But then it gets in an endless loop sending the following two queries again and again: SELECT `AUTO_INCREMENT` FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'snoeptb9' AND TABLE_NAME = 'ps_orders' LIMIT 1 SELECT * FROM `ps_orders` a0 WHERE (a0.`reference` = '0')

That is a choice and I can live with that. But I want to share my impression that Prestashop after the transition to 1.5 may have concluded that they had overdone it. That too many things had shop options and that as a consequence the software became too complex and too hard to understand for people who worked with it. And that as a consequence the development of modules might suffer. They couldn't undo the addition of the ps_group_shop table. That might break modules. But I doubt that is a coincidence that my shop always kept working with just one entry in this table.