11

I'm using Magento 2.2 with Porto theme and getting an [object Object] javascript error at customer-data.js line 90 in the console after logging into the store and refreshing the page or switching to another page.

I tested this in Firefox, Chrome, IE 11 and Edge and it's only showing up in Firefox (the browser I mostly use).

It isn't causing any serious problems (not as far as I can see), but I would like to resolve this issue.

object Object error

line where the error happens

Line 90 of the customer-data.js file is: "throw new Error(jqXHR);".

Inside the jqXHR object is a JSON response message:

{"message":"\"paypal-billing-agreement\" section source is not supported"}

I've seen a couple of suggestions out there, but most of them revolved around cleaning cache and static files.

I tried: clearing firefox cache and cookies, cleaning Magento static files, cache and storage cache, but nothing worked so far...

And i'm not really sure what else to do...any help would be appreciated.

Edit/Solution

The cause of the error was that I had disabled the Paypal module but didn't clear the browser local/storage cache.

Inside this cache was a certain call to the paypal module which couldn't be processed so it returned a JS error like this.

Clearing this cache fixed the issue.

4
  • First, check what inside the Object jqXHR. The construct method of the Error class expected the string message (or Object with toString method). Nov 15 '17 at 14:14
  • @SiarheyUchukhlebau I edited the question with the jqXHR contents.
    – Lez
    Nov 15 '17 at 15:03
  • where did you find the jqXHR Oject?
    – krybbio
    Mar 26 '18 at 17:37
  • @krybbio You can see it while debugging on line 90 of the customer-data.js file. You can also see it in your browser debugger on the network tab (name depends on browser) --> you will see a "400 error code - bad request" and inside the request you will see the request url and response message.
    – Lez
    Mar 26 '18 at 17:50
46

I have literally wasted a few days trying to debug this issue and finally got a definite solution or work around I would call it. Hopefully it can save a few other people the headache I currently have!

I first noticed this error appears when I switch from Client-Side to Server-Side Compilation in Stores->Configuration->Advanced->Developer->Frontend Development Workflow

Then I determined that customer-data.js uses the localStorage within the browser itself to store a variety of information, so you can clear the Magento Cache all you want and you will still have issues.

TLDR:

The fix in Google Chrome is hit F12 to open the Developer Toolbar, then select the Application tab. Clear the Local Storage, Session Storage, and Cookies. Reload the page and all should be well. You will have to do this on your admin page as well.

Credit: https://github.com/magento/magento2/issues/6410#issuecomment-243704461

6
  • 5
    How to fix this for all users of the shop? I can see that many users see this error in new relic and I guess they won't clear their local storage (but they likely just leave the page).
    – bpoiss
    Apr 30 '18 at 5:45
  • Thank you for this answer - it saved me many hours :)
    – artwoz
    Dec 4 '18 at 9:58
  • I too got this error, it turned out it was caused by headers already sent error by another module. It helps to add a console.log(jqXHR) just before the error is thrown. See also magento.stackexchange.com/questions/198333/… at the bottom
    – Isolde
    Dec 7 '18 at 14:36
  • I tried all things those u said but same issue. screencast.com/t/XEueQ00Foqs3 Dec 31 '18 at 9:36
  • thankfully found this before spending many hours, I had tried to invalidate wrongly named section at some point, and this was cached.
    – Joel Davey
    Feb 13 '19 at 10:41
1

This error says that source data is not specified in the sectionSourceMap located at the Magento\Customer\CustomerData\SectionPool class. The paypal-billing-agreement data is defined in the file vendor/magento/module-paypal/etc/frontend/di.xml:

<type name="Magento\Customer\CustomerData\SectionPool">
    <arguments>
        <argument name="sectionSourceMap" xsi:type="array">
            <item name="paypal-billing-agreement" xsi:type="string">Magento\Paypal\CustomerData\BillingAgreement</item>
        </argument>
    </arguments>
</type>

So, probably the paypal module was disabled in the store or some third-party module has disabling it in the not-a-right-way.

To debug that problem open the file vendor/magento/module-customer/CustomerData/SectionPool.php and check what sections is loading in the getSectionsData method. Additionally, you can try to call the method getSectionsData(['paypal-billing-agreement']) somewhere from a custom code, and check step-by-step why this data is not loading.

2
  • 1
    Seems I has the Paypal module disabled in app/etc/config.php but it wasn't disabled "in the right" way so it caused this issue. Thank you for the suggestions!
    – Lez
    Nov 16 '17 at 12:42
  • @Lez I'm glad to help you Nov 16 '17 at 12:43
1

For me I could see the issue had something to do with the item I had just added to the cart.

enter image description here

So I ran the following query on the DB to remove all quote items from my user account:

DELETE FROM quote WHERE customer_email = 'my.user.email@example.com';

After that the issue went away :)

1

In my opinion the accepted answer is only partially correct.

Clearing your localStorage will clear this issue for your specific user. However for other visitors that still have this value in localStorage they will still trigger the error on their browser - and thus in NewRelic.

Specifically, this is the section of concern: mage-cache-storage-section-invalidation. For example, if you removed the instant-purchase module, there may be some visitors who have the value of {"instant-purchase":true} in localStorage for key mage-cache-storage-section-invalidation

A call to customer/section/load for this endpoint would likely result in a 400 status code as the PHP wasn't written smart enough to check if the index your passing in exists or not. (or maybe that was from a customization we made... I forget)

Regardless, Magento did not expect you to remove their code bloat (like the instant-purchase module and thus they didn't build a method to prevent this pointless hit to the server. Below is my suggestion on how to prevent it however.

Ideally we should delete a removed section from the visitors localStorage. I was moving quick and didn't add that feature... Instead I just removed that section from the list of sections to be called to the server.

In vendor/magento/module-customer/view/frontend/web/js/customer-data.js add this at the top of the reload function. This modifies the list of sections being called in the hit to customer/section/load.

var sectionsToExclude = [ 'instant-purchase' ];
for( var i = 0; i < sectionsToExclude.length; i++ ) {
    var indexMessages = sectionNames.indexOf( sectionsToExclude[i] );
    if( indexMessages > -1 ) {
        sectionNames.splice( indexMessages, 1 );
    }
    if( sectionNames.length == 0 ) {
        break;
    }
}

Additional sections can be added to this array if needed.

Also add this logic to vendor/magento/module-customer/view/frontend/web/js/section-config.js

Replace this core line of code: return _.union(_.toArray(actions), _.toArray(sections['*']));

With this logic:

var mergedSectionNames =  _.union(_.toArray(actions), _.toArray(sections['*']));
var sectionsToExclude = [ 'instant-purchase' ];
for( var i = 0; i < sectionsToExclude.length; i++ ) {
    var indexMessages = mergedSectionNames.indexOf( sectionsToExclude[i] );
    if( indexMessages > -1 ) {
        mergedSectionNames.splice(indexMessages, 1);
    }
    if( mergedSectionNames.length == 0 ) {
        break;
    }
}
if( mergedSectionNames.length > 0 ) {
    return mergedSectionNames;
} else {
    return false;
}

Of course don't edit core code - make a proper extension of these files and edit them that way. I'm just highlighting what needs to be changed to prevent these errors.

One final comment: the more I've dug into how customer/section/load is implemented the more I hate it's flaws... It prone to too overuse which can impact your server and site performance. This is just one of too many areas I've had to implement. Some of my changes I'm likely to submit to core at some point to try and address fundamental flaws, but finding the time to work through their submission process hasn't been a top priority yet.

One example is that ANY AJAX POST/GET/DELETE request will trigger customer/section/load to be called. But what if that POST request was just to send some tracking data? Nothing changed on the server, so why should we hit it again? Many 3rd party modules make calls like this and they are causing un-necessary hits to customer/section/load (AheadWorks Product Questions and Answers, Mirasvit Rewards, and Facebook Business Module are some at the top of my mind.)

1
  • +1 for the effort and analysis. Overall these kinds of issues should be fixed during development, but if it reaches production, then obviously clearing local storage is just a solution per browser (customer) and is not a valid solution. So your approach makes sense in those situations. It just sucks that the Magento team keeps adding many uesless modules in general that requires so much effort to remove...
    – Lez
    Nov 10 '21 at 15:07
0

Please delete records of "Porto Theme" entries from "theme" table. The records will auto create again. And reassign Websites with this Porto theme again and check.

0

After transfer of data from live server to the dev server, the cookies (dev-server, pre-transfer!) were still stored in the browser. After cleaning of the cookies, everything is fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.