Jump to content
thirty bees forum

jquery-1.11.0.min.js:3 busy or not responding on BO product page


Recommended Posts


In BO page to edit/create a product I get this error jquery-1.11.0.min.js:3 script busy or not responding

If I do click continue after a while the page work, in other cases clicking continue result in a halt of the browser and eventually a crash.

Clicking stop the script results in not being able to save the changes.

What should I check to debug this?

Thank you.




I begun to see this error after I added a few things: suppliers, manufacturers, attributes, features and relative default values, etcetera...

I reverted step by step and discovered that this issue is caused by the features.

The addition was done via phpmyadmin directly in the database, everything else seemed to work fine, only this jquery issue was triggered, now thinking about this (as noob) I might thing of 3 possible scenarios:

1) in the tables I used (taken from previous prestashop installation I am using) there might be errors and incompatibilities with TB, however I took care to compare the feature related tables structure one by one, all seems fine for each. For what is concerning the values in the tables I took care to check that are consistent, so far I think that are fine, I do not know what eventual special thing need to be checked to avoid inconsistencies or conflicts

2) the character encoding might be wrong for these tables, in fact in the values assigned to features there might be some rarely used character causing troubles, alike °, the diameter symbol, and few others... I do not know if the use of such characters can cause such an issue as a jquery script busy or not responding

3) the amount of features, default values and languages is quite big, over 180 features, about 4800 default values and because there are 10 languages in use over 48000 record in the table feature_value_lang, I do not know if using many features and default features can cause such an issue

Can anyone tell if the size of the tables can cause this problem? (I can start recreating everything from the BO and check now and then while progressing if the page to edit a product start to cause this trouble again, but is a very long work I would like to avoid). IF that of the size of the tables is a known problem I would avoid bothering doing all those tests and search for the proper solution to that...

What about the other two possibilities I am imagining? (I am not expert, I am working according to my understanding and imagination, sorry...)

What do you suggest to investigate first? Any other thing to check in order to solve this?


I found this page on github:


Seems that there are several troubles with amount of categories and product features in prestashop 1.6 and 1.7, as TB is containing large part of PS 1.6 I guess this trouble is inherited.

It is a quite odd trouble, very annoying and a big limitation.

Is TB also still affected?

What do you suggest to circumvent this?

Anything else is known in relation to this issues?

Thank you

Best regards




Edited by Raymond
Link to comment
Share on other sites

You'd have to be a little more specific about that. What error message is there?

But I suppose, @Traumflughas caught the "spinning buttons" bug like any other programmer who relies on the code of PrestaShop 1.6. The tabs cannot be reloaded and therefore a 500 error is triggered.

As a quick'n'dirty solution you can do the following:

  1. Go to themes\default\template\controllers\products\
  2. Search all tpl files (got to be 13) that contain exactly this search pattern: disabled="disabled"><i class="process-icon-loading">
  3. Replace only this search pattern with ><i class="process-icon-loading">, which means that only disabled="disabled" is dropped in each of these 2 cases per file.
  4. Save all 13 files.
  5. To make things as safe as possible, clear the cache afterwards.

This should help to avoid the error message.

Edited by Occam
Link to comment
Share on other sites

Hello Occam

The action and consequent error that comes out exactly is this one:

1) I click on Catalog menu and open the Product list tab, there I click on a listed product edit button to edit it

2) the product edit page is loaded, but is soon halted, I cannot navigate in it, after some more seconds (10 or alike) the progress spinner goes on again and is possible to scroll the page, this already take alike 20 seconds or more, however the page at this stage, still, is unusable.

3) After some other 10 to 20 seconds a popup error message appear telling exactly the message I posted: jquery-1.11.0.min.js:3 script busy or not responding
This popup error message allow to "Stop the script" or "Continue", if one stop the script cannot use the page, of course it becomes useless, if one click "Continue" the script is further processed, so after more dozens of second finally the page becomes fully available.

If the debugger (in firefox) is opened, that same message allow a third option, "Debug the script", if that one is chosen a lot of info comes out, however I am unable to interpreter it correctly.

By the way I have seen that there are quite some warnings about CSS problems, a couple of scripts in which the character encoding is not declared so if used out the frame in which are inserted might show odd stuff, and more stuff, I can post it all if useful...

However, as I am not expert, I am not sure to have searched well in the debugger in order to get the most relevant info for this specific problem, I have the feeling that I saw quite many errors and warnings that might be unrelated.

If you can suggest me what to exactly do with the debugger I can reproduce again the problem and post a full report.

Thank you




Link to comment
Share on other sites

15 minutes ago, Occam said:

I guess I already suggested what to do to avoid the bug. 

yes, I got it, I will try that, thank you

However, as far as I understand, maybe that modification is going to avoid the long response and the error message, I do not know if it is the only trouble... however, I will test it and report.

16 minutes ago, colorful-ant said:

have you too many variants in your products?

Variants... you mean product attributes?

Yes I have many and maybe will add more in future, is very useful function to avoid a lot of product pages and/or avoid confusion to clients and search engines.

However at this stage I am testing with the sample products present at installation time, so a few combinations are in use.

Link to comment
Share on other sites

1 minute ago, Raymond said:

I do not know if it is the only trouble

Unfortunately, your fear doesn't seem unfounded. This may also be due to the fact that tb 1.1.0 seems to be moving away from the standards of previous versions in some parts. There are undoubtedly good reasons for this. But I strongly hope that the major revision of e.g. the VAT calculation will not affect the functionality of the payment modules. Because I would like to spare thirtybees a fiasco like PrestaShop currently faces with the payment modules - though for other reasons.

Link to comment
Share on other sites

Hello Petr

Tired of prestashop continuous fails, very annoyed by the fact that a good amount of addons I bought for prestashop did not work out of the box, having lost a great amount of time, patience, money, trust... I ran into a real disillusion and stopped dreaming after prestashop.

Prestashop is for me now only a big loss of time. I decided to leave it after I saw how bad is 1.7 version, how they could never ever end any project for good, how much I did not like at all their marketplace, how I do not like also their forum.... and so on.

However I recognized the great potential of prestashop up to version 1.6. When I came to know about Thirty Bees I got very interested as in the meantime looking for alternatives sincerely I could not find something that overall is as much interesting.

Considering the past experience and knowing how painful can be to have a decent shop this time I elected Thirty Bees and to deploy it I created a couple of TB clones to test in steps, one branch to do new things and a "step behind branch" to check and eventually revert, so I have a certain freedom into going forth and back while building up the platform I need.

5 hours ago, datakick said:

If you are on a test/dev account, use core updater to downgrade back to 1.0.8. Then test if the product page works ok, or not. This will tell if your problems are related to 1.1.0 version, or if you've hit limits of thirtybees platform. 

I can do that too and report, but I need some time, by the way, if Tb was not fixed to avoid that issue, very likely is present in TB 1.0.8 as well.

However, if I discover that with TB 1.0.8 I can create all features that I want while in TB 1.1 the limits is a few dozens of features, in general that would be a very strong limitation either ways.

So this test can be done for curiosity I guess, but discovering that version 1.0.8 is not affected won't solve anything for the users as would make little sense to get stuck into the 1.0.8 version.

Tjis issue  is nothing that causes a "no no" answer to the question "would you use thirty bees?", but, still, that kind of limit leads one to say for good in a bit emphatic way "for a big complex shop there might be troubles in certain circumstances".

I think that statement in various extents is true with any platform, but surely it can have a different weight, for instance a big one if the possible circumstances are many and maybe due to some apparently minor things, alike a major page in BO using a script that gets clogged, busy and not responding.

Products can be handled via database eventually using some very efficient tools, but, the point is that in the BO for obvious reasons everything must work well.

Even if the problem can be circumvented and avoided with external/third party means, in general, having such a limit in the BO is not good at all for several reasons, licenses costs, clients needs, clients preferences, employees not having access to special tools but maybe needing to apply few changes on the fly and so on, there are many possible examples...

One example is my own experience with this issue, I resume here what happened and what will likely happen:

I hit this trouble not knowing why except remembering that happened already in prestashop sometimes, consequently did a search to guess what can be, wrote a post here and continued to investigate, got an idea about it and finally saw that is an old prestashop issue due to excessive product features, but also and/or maybe categories and/or attributes, so I reverted, clarified that in my case is the amount of product features, had to reason on it, wrote updates to the post here, now I am deciding to add again little groups of products features in steps to try to guess then which is the limit to not see issue again, after all that, if everything goes fine, knowing the eventual limit I will have to decide how the shop must be pruned to not have the problem....

I do not like the idea to have to guess a limit in order to prune the shop... is not good.

However this is just what I will do as I am unable to solve the problem except try to see if anything good happen with some changes that are suggested or that I can random find on other posts with more extensive searches on internet

That is surely not the convenient and desired workflow I would like to have, but very probably nobody would like to have such an adventure...

This trouble as far as I understood is inherited from prestashop, in that post on github I linked ( https://github.com/PrestaShop/PrestaShop/issues/9809 ) presta people admit it and in many occasions apologize to persons writing heavy complaints about this issue, mainly spotting out how it is a strong limit impeding having things right in a growing shop or anyway a big shop (as I read because they feel alike being ignored, a feeling that in general is not hard to recognize in the prestashop thing)

While developing any project being continuously stopped by some little stones in the shoe is really not nice, especially if one find no easy way to remove it...

In general one want to just go on and publish at least having the basic things well done right, the rest can be done later on.

As anyone can imagine even working onto a perfect bug free platform there is a lot of work to be done to have a working shop.

My greatest wish giving trust to the TB project is to become able to concentrate much on that commercial part and not have all kind of technical problems meanwhile I do work on selling products.

That in the latter sentence might be a reasonable goal also for developers of an any business software platform as when micro and small business find a lot of difficulties to start or to grow a HUGE amount of potential future customers are cut out of the game while the few notorious big and monster giant companies gather everything at faster speed.

This is not a critic, I just wanted to describe what/how it all happens and why things alike these can be very frustrating.

That said while I try to fix my thing here, within my limits, I am very keen on helping, ask me anything and I'll contribute as a final user tester as much as I can.

Thank you for the help

Best regards


Edited by Raymond
Link to comment
Share on other sites

because of the many variants / combinations, I have asked. I had once created a product that had too many combinations and it took forever, until I could edit the article further. In any case, there were too many, because the product page for the customer has too long loaded. the query system / server / database was far too much in that case. Unfortunately, I do not remember how many combinations it was. But it was a lot for a product.
I do not know how it is with you with the amount and what your server can handle.

  • Thanks 1
Link to comment
Share on other sites

I have tried on my local installation running 1.1.0 to create many features:

  • 356 features
  • 201332 default feature values
  • 604002 feature value lang

This is much more features than you have (according your first post).

The product page is indeed sluggish -- the readystatechange event handler run for 3 seconds, and the page is non-responsive until this finishes. Moreover, switching to Features tab takes 4 seconds, even after the page loads. This was on chrome. When I tested on Firefox, I got worse measurements - it took 8 seconds to open features tab.

The same results are in 1.0.8. So (unfortunately), this is nothing new. It's indeed inherited limits of thirtybees platform.

When I tried with the less features (180 features, 4800 default feature values) it worked quite fast, thought. There was some performance degradation, but it wasn't really noticeable. 

My initial investigation shows that the problem is in huge amount of DOM nodes. Basically, for every feature and every feature value, DOM nodes are created and inserted into the page. Browser can't handle so many of them on one page.

There is no quick fix -- the product page needs to be reworked to use some data lazy-loading (Instead of displaying 200k DOM nodes upfront, we would only display 356 features and load feature value only when necessary via ajax). But, unfortunately, this is a big change. It's not realistic to expect it anytime soon.

Sorry for the bad news

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Hello Petr And Colorful Ant

I guess that when the combinations are too much the same happens maybe for the same reason Petr explained for the features.

9 hours ago, datakick said:

My initial investigation shows that the problem is in huge amount of DOM nodes. Basically, for every feature and every feature value, DOM nodes are created and inserted into the page. Browser can't handle so many of them on one page. 

So, for what is concerning the amount of combinations of a product, as too many are going to affect also the speed at which the Front office product page is shown to the potential customer, maybe the only solution is to keep the combinations at minimum necessary.

Eventually a workaround is to create another similar product with the other combinations left, maybe adding a link in both the products page to see in each the other similar product with extra combinations (hoping that the potential customer see that link, often clients are very fast in dismissing pages).

As far as I know there might be a module that solve the product combination generation trouble, but I am not sure that the FO slow page problem is solved.

For the features I do not recall to have seen slow pages in the Front office, the trouble is confined in the BO as far as I know (to be checked tough).

Also in the layered navigation system there should be no big problem in th FO, when I had it up with all those features everything seemed to work fine, maybe a bit slow, but, for who understand how much useful is that filter should not be a problem to wait some more seconds to have it ready (that was in prestashop 1.6, but I guess will be the same in TB1.1 if not better)

That overall to me means that at the moment, due to the old prestashop architecture in this respect, a TB shop might not contain a great amount of features and/or products with a lot of combinations.

Until one build a shop for own use knowing these limits helps to keep it reasonable, eventually the BO trouble is bypassed using some tools alike phpmyadmin, store manager or the like.

The situation is different if one is preparing the shop for a client, in that case one have to warn that having a lot of features there might be troubles in the BO and troubles in the FO if products must have a lot of combinations, that is a different and more complicated scenario. It is always hard to explain to a potential client why a solution is good even if it contains special limits, besides that a client might be concerned about the possibility to be able to use the shop in case the need of using lots of features and combinations might arise in a future, (or plain simply need that great amount of features and combinations since start, case for which would be hard to opt for TB).

Than you

Best regards

Link to comment
Share on other sites

Hi @Raymond
I am using a module from Presto-Changeo to deal with allow of combinations.
Its working perfect for me, but in my case I don't need price increase/decrease per combination so I am not sure about all capabilities of this module.
This is the module: 

You can see it on my site: https://www.lens.co.il/1-day-acuvue-moist
The front office is without any cache and working really fast, I am using bleeding edge version here.

Link to comment
Share on other sites

Hello Yaniv

I also used this module in a old 1.5 prestahop installation, it worked very well as it eliminates that bulky thing the prestashop people thought (practically an automatic obstructor machine as it was originally conceived).

I confirm that the AWP module eliminated all the attributes trouble in my old PS shop.

I am very encouraged by your comment, is a pretty good info the fact that you already successfully tested it on TB.

So far, coincidentally with your reply that I read now, I installed and tested the 1.8 version right today on TB 1.1 using the ST Transformer theme, but I see troubles in the FO

To start with to fix this I think I really need to get the latest version (it is the only declared by Presto Changeo to work with TB), secondly I found a bit hard recognize how to exactly modify all the files in the transformer theme.

One thing that is a bit complicate when installing this module is to avoid errors adding all those lines in all those files, especially if the theme used if quite different from the default one...

I am waiting now to receive the updated version, I will test it as soon as possible, I am pretty confident that should work well, I just hope to succeed to properly modify the transformer theme files.

Thank you.

Best regards


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...