Hi Brian,

Thanks again for getting in touch, and no worries at all about the number of tickets. My name is John, and I'm happy to assist you. I sincerely appreciate your patience while we worked to get back to you.

Regarding the issue you're experiencing, there are a few important things to consider. First, please check the System Status section inside LayerSlider to see if anything is flagged there. That might point you in the right direction immediately.

The 400 error you're seeing is a fairly general HTTP status code. While it doesn't reveal much on its own, it typically indicates a server-side issue. In many cases, it's not caused by PHP or WordPress directly, but rather by the web server itself, such as Apache or Nginx.

One common cause we've seen is that web hosts often have security modules or content filtering tools in place, like mod_security, that silently block requests if they hit a predetermined limit, such as request body size. When saving a slider, especially one with many layers or assets, the plugin can send a larger amount of data, and the server might reject this without returning a detailed error message. You can also test saving in a newly created and mostly empty LayerSlider project. If that goes through without problems, it's quite certain that this causes the issue.

To investigate further, it would be helpful to check the relevant server logs, such as the web server or PHP error logs. However, only your hosting provider has access to these and the ability to change the underlying configuration, such as adjusting request limits or disabling overly aggressive filtering. We can't access or override these settings from within WordPress, so I recommend reaching out to them as well.

Of course, we're happy to continue helping you as far as we can from our side. Just keep us posted on what you find; we'll gladly advise further.

Thank you so much for the detailed update, Brian. We truly appreciate your thoroughness and especially how proactive you were in diagnosing and working around the issue. I'm glad to hear you were able to get the project saving again, even if the underlying problem still looms as a potential limitation down the road. Roadblocks like this can be frustrating, and I completely understand how you feel. Please allow me to clarify and address the concerns you raised.

You actually ran into something that's part of the Undo/Redo system, not the Revisions feature. These two are easy to confuse, so let me quickly explain:

• Revisions are saved versions stored in the database. They allow you to go back to earlier versions and visually compare the changes you made. When you disabled revision tracking and chose to delete revisions, those database entries were likely removed as expected.
• Undo/Redo history, on the other hand, is an internal mechanism of the editor. It records your recent actions and allows you to step backward or forward while editing. Unlike revisions, this history is stored within the project data itself. However, it's a rotating system that keeps only a fixed number of recent entries, and each entry contains only the actual changes made, so they're typically very small in size.

When duplicating a project, the Undo/Redo history is intentionally kept. That's usually helpful if you want to experiment right away without losing your previous work.

Professional-grade tools like LayerSlider naturally generate larger payloads as they offer a rich set of features with lots of options. While it's understandable that limits are imposed on shared hosting environments, this particular one serves no purpose in my opinion, and hosts should ideally accommodate modern use cases like this. Sadly, we can't adapt the behavior of all features around external, undocumented limits, especially when we can't detect them reliably or get proper error responses.

It's worth mentioning that while issues like this do happen from time to time, they are not common. The vast majority of hosting providers do not impose such low request size limits.

Just as a future workaround, if you ever run into something like this again, you can manually clear the Undo/Redo history via the browser console. To clear the active slide's history, use:

LS_activeSlideData.history = [];

Or, to clear all slides in the project:

for( let slideData of lsSliderData.layers ) { 
    slideData.history = [];
}

Once done, save the project and reload the page.

Thanks again for the great feedback. Your notes are very helpful, and we'll consider adding an option to set a custom limit on the number of Undo/Redo entries. However, I hope you understand that there's very little we can do from our side. Depending on the server setup and use case, this wouldn't help in many situations without addressing the underlying cause.

If you had tried to add a new slide with multiple layers instead of just a single link, then clearing the history likely wouldn't have been enough. In your case, it was just a small change where clearing the history data helped, but that usually frees up only a small amount of data and, in most cases, wouldn't be sufficient.

Also, we can't treat important features like Undo/Redo as bloat. While it was a trivial sacrifice for you, it's sadly not a universal solution, especially for a problem that a third party causes and we have no control over.

If we could reliably detect this particular problem, we'd also display an explainer in the editor as we do with many other things.

Thank you for your kind words and feedback — it really means a lot and is genuinely helpful.

I didn't mean to suggest you considered Undo/Redo as bloat. I only wanted to rationalize (partly for myself 😄) why we're cautious about changing or limiting certain features and behaviors, like ensuring the history stack is preserved when duplicating projects. These small design choices can support meaningful workflows, and removing them might take away valuable use cases. Still, your case raised some good points and helped us look at this from a new angle.

For example, we're now considering switching from a standard POST request to a file upload-based method. While that's a bit unconventional for this type of use case, hosting providers usually allow much higher limits for file uploads. If it turns out to be a viable solution, we'll likely include it in a future update.

Feel free to let me know if there's anything else I can help with. Otherwise, I hope you have a great rest of the week.