- This topic has 40 replies, 3 voices, and was last updated 22 hours, 2 minutes ago by
.
-
Posts
-
After latest update, every save of the newsletter takes longer, exponentially longer. Something is wrong.
Hello Robert,
we didn’t change anything in last update that could lead to slowness while saving options or newsletter editing. Do you experience slowness or unresponsive behaviours in WordPress or in other plugins as well?
Michael
If you try to edit & save another newsletter, is it slow? Is the settings panel slow as well?
Michael
I’m not sure what you mean by “not updated”. It’s the plugin as a whole that got updated, newsletters are just data inside the plugin. Anyway, it could be that single newsletter that got corrupted somehow. Try to duplicate it and test saving responsiveness in the duplicate.
Michael
the file is taking so long to open now it absurd. Any ideas of how to save the details in this newsletter and create a new one?
Hello,
this is weird. try this: go to Newsletters > All newsletters, locate the faulty one in the list, at the extreme right there is a “T” icon. It creates a template out of a given newsletter. Click it, and then try to create a new newsletter: select the newly created template from the popup panel. Check if it’s still slow.
Michael
I believe this issue is resolved by creating a template of the compromised file so a new file can be created.
I am experiencing slower than normal saves again, but not nearly as bad as before. Will advise. Might need to build a new file from the start and test that.
Created new file and response was good until populating it with text and graphics. Now beginning to slow down again. Will keep going and see results.
clarification: when saving, the newsletter app green alert says “Saved” immediately, but it takes increasingly longer times to see the newsletter appear on the screen.
the delays are approximately 6 seconds longer each time I save until I can see the file again.
Changed from Safari to Crome browser. Crome alert says “page unresponsive” before finally displaying.
Speed test show 1249Mbps clear connection.
Hello,
I think the culprit here is the way you’re creating the newsletter or the content you’re trying to parse. Could you please tell me specifically which blocks are you using in your template?
Michael
not doing anything different at all that I have done for years, across several newsletters. I am copying the old newsletter each week, deleting old material and adding new. I’ve never seen any delay at all after saving. Working on two newsletter every week, the problem is suddenly the same with both.
The issue is not saving, it’s display. I get the header within a few seconds. It’s the elements that take so long to display.
preheater; image; separator; text; text, image; separator; image, text; text; separator;
then image,; text; separator (repeated 33 times)
social; footer; company info
Hello Robert,
no, every duplication creates a new newsletter so that’s not the problem. I’d focus on the images, are they optimized? How much do they weigh on average? It seems that you have quite a few active at the same time, that could lead to slowness (but it’s still weird because you never experienced it before). Would you mind recording a screengrab video of the whole process from when you click save to when the UI becomes responsive again? That would help a lot.
michael
I have created a newsletter from blank new file. there are no delays yet. As I populate it, I’ll keep track of any delays in display after save.
I will try that video record just to show how crazy slow it has become today.
We highly optimize every image, that’s not the core issue, although an image that has somehow become corrupted could lead to delays in display. Average 62k per image.
I have confidence in starting from scratch, which will take time and I’m on tight deadlines. Will do my best.
Thank you, as always, for personal attention when I get the point of not being able to problem solve alone.
tried opening these WordPress files on other computers, other browsers, no change.
Must be an image or link that is corrupted. Will try to identify.
I am able to easy create the newsletter as a template with no delays in screen display, so theoretically I can create these newsletters as templates without issues.
I see no way to convert this template into a newsletter I can send. What is the procedure?
To be clear, the same exact issue is happening with two different newsletters of completely separate content, so I have eliminated the issue a a corrupted graphic. In several cases, a graphic used the external URL option, which I eliminated, but I don’t think that was the issue. Newsletters save quickly, but the time it tales to redraw the page is increasingly lengthy in the composer. There are no issues in creating a template.
I can always create newsletters without saving the file often. That cuts down on the delays but there is always a chance of losing some work if a version is not saved at regular intervals.
OK, I created a new newsletter and used the template I correctly created. It seems to save and display just fine. Not sure how that could delay in display might have happened to multiple newsletters on multiple domains at the same time.
When I begin to make updates to the newsletter created from the template, the slow behavior begins again. At first, a short delay, but after another save, a longer delay to see the display. On and on, until the delay is so long it seriously affects productivity.
Hi, I also noticed this behaviour today and took a look at the source code (in composer mode and in the preview). The problem becomes apparent immediately:
When the newsletter is loaded in the composer/editor, an empty DIV line with the class ‘tnpc-row-actions’ is inserted between all TABLEs of the blocks. This doubles after each save. Earlier today, the last newsletter (that the people I support were working on) had over 2,800 of these lines… waiting time: 20 seconds.
I just looked at the changes in WP-plugin-TRAC and there were some changes affecting JQuery seek+deletions of ‘tnpc-row-actions’ and ‘tnpc-row-action’ elements. I suspect that errors snuck into version 9.1.3?
My dirty quick fix for newsletters that need to be finished right away: remove the nonsensical<div class=\”tnpc-row-actions ui-sortable-handle\”><\/div>lines using, for example, the browser inspector, then save – the newsletter is fast and clean again. Unfortunately, the problem builds up again after the next save iterations …
As a temporary solution, could we perhaps revert to 9.1.12 for now?Hi Robert and hi Jan,
we already have our devs on this. I do really thank you for your feedback, I’ll update this thread as soon as we have any news.
Michael
I have already installed the new version and now composing is working fine, thank you. It took me a little while to remove the old DIV content from the existing newsletter drafts, but now it’s all good.
Thanks for the feedback Jan, glad the new version solved that issue. Did you update, Robert?
Michael
- You must be logged in to reply to this topic.