"parsererror" toast messages when opening a page in the CMS #141
Comments
|
@micmania1 mentioned that he's seen this on a private project using SilverStripe 4 on SilverStripe Platform, but not using CWP. This could mean it's caused either by core and/or by one of the CWP modules, but not directly by CWP itself. |
|
These are what we're directly pulling in. composer.json |
|
I suspect this is related to the comments module somehow. I can't reproduce it on mediumtest-uat (running CWP 2.1.0) unless I open a page that has comments enabled on it. Unfortunately I still can't reproduce this locally using the same code base with Steps to reproduce on UAT:
From here you can toggle between the blog and the blog post in the SiteTree to continue to get the error. It's worth noting that this doesn't happen if you refresh your browser and toggle between the pages in the SiteTree, so perhaps it's an issue with something that is or isn't loaded via AJAX when switching from campaigns into the CMS, which is or isn't loaded when you load the CMS edit URL directly. |
|
Update: it looks like it's being caused by the colymba/gridfield-bulk-editing-tools module trying to load its Javascript file via PJAX. Removing the |
|
Update: colymba/gridfield-bulk-editing-tools 3.0.0-beta2 doesn't cause the problem. Must be caused by something between silverstripe/silverstripe-gridfield-bulk-editing-tools@3.0.0-beta2...3.0.0-beta3 |
|
This could be the same problem: silverstripe/silverstripe-gridfield-bulk-editing-tools#176 |
|
Seeing the same "parsererror" on an SSP site. Required modules: silverstripe/framework 4.1.0 What i've found is that in this case, it only occurs when accessing the site via the CloudFlare CDN (i.e. if you bypass there's no error) - perhaps you only see this on CWP due to Incapsula? I was able to resolve by deploying 3.22.2 which ensures the same timestamp on files over distributed servers - https://docs.platform.silverstripe.com/changelog/#3-22-2-12-september-2018 In this case it was a request to |
|
@jakedaleweb thanks - that would make sense as to why it's not reproducible locally. Do you have any ideas about fixing this from a platform angle? |
|
@robbieaverill Well the fix on SSP was to ensure that all servers in the load balance pool had the same modified times on the files as this is something required by core (I think ?). However in the case of mediumtest it is a single server, so not impacted by the same issue. So essentially, the issue I encountered has already been fixed on SSP by manifest version 3.22.2 and I don't believe it has the same cause as the issue you've described. |
|
We’ve made this logic more stable on multi-server environments by ignoring the file modification time parameter when computing client-side requirements via Can you check if all of the environments having this issue are load balanced, and could be prone to having file generation timestamps getting out of date between filesystem copies in different webservers? |
|
My |
|
I'm seeing this in the new CWP demo which really isn't nice. I'm getting this in line for the upcoming sprint |
|
Problem goes away when: |
|
🤔 Load a normal I notice that the javascript file identified above loads via an XHR rather than as a JS file (i.e. filtering on each type in the dev tools). I would assume that this confirms it is loaded via the CMS on-demand directive, rather than as an in-content |
|
Indeed, the parse error still occurs when the preview pane is shut.
Also interesting that this is an underscore and a timestamp. All CMS provided includes use an |
This is our
Also interesting in that script is that the |
|
At this point I suspect one of two things:
|
|
Probably should have just started here really :/
Also stops any other It's |
|
Injector is asked to make a transformation after it's instantiated. Along comes |
|
@Cheddam recommends that perhaps the strategy needs to happen here. The bulk editing JS will need to load always ( Or we go about making some hefty changes to Injector to allow it to accept components and/or transformations after it boots. Which seems... complicated. |
|
"parsererror" should be resolved on an update :) However that doesn't solve the underlying cause, which will also see that bulk editing grid field items do not work. |
|
To be honest, that sounds like a separate issue to me. We can review that module's JavaScript during the stabilisation work which still needs to be completed. Note that the module is still in beta phase. Related issues: silverstripe/silverstripe-gridfield-bulk-editing-tools#176 silverstripe/silverstripe-gridfield-bulk-editing-tools#188 |
|
Indeed, this particular issue is done. The fix is present in |
|
I've come across this again in a UAT version of the CWP demo, running CWP 2.3.rc1 (which I would have assumed included the latest version of admin). Given this site is running a RC and is a UAT environment. I won't reopen the issue just yet - but I suspect I may have to soon... Also, I'm not seeing any console errors with the parse error. It can be recreated by simply adding a new page. |
|
Thankfully, there was an issue with the UAT environment above. This can no longer be recreated. Ignore my comment above :) |
Version: CWP 2.0.1 and CWP 2.1.0-rc2
Context: I have two fluent locales and two subsites with a variety of pages created in each.
Tested on a vanilla CWP 2.0.1 and CWP 2.1.0-rc2 code base.
When I log into the CMS, go to Campaigns, go back to Pages again and click on one of the pages in the tree, I see a success toast message in the top right corner saying "parsererror".
This appears to come from jQuery or jQuery changetracker somewhere, but I wasn't able to find out why at a quick investigation.
The text was updated successfully, but these errors were encountered: