Skip Navigation

[Resolved] Layouts css resets after browser restart

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 9 replies, has 3 voices.

Last updated by Nigel 3 years, 2 months ago.

Assigned support staff: Beda.


I am trying to: continue working on Layouts css after closing and restarting Browser

I visited this URL: Layouts CSS & JS editor page

I expected to see: the changes I made preserved

Instead, I got: a cached previous version of my edits

I use to have a lot of tabs open in my browser, usualy Firefox. I have set the browser so that after a restart the tabs that were open at browser shutdown are reopened.
After a restart of the browser I noticed the changes I made in the Layouts CSS editor were not preserved in the tab. The editor was showing a pevious version of my CSS file. I had to reload the tab in order to get back the last changes I made.
This looks like a browser caching problem interfering with the CSS editor.
It is especially tricky since you easily oversee that some parts of your CSS code are missing if you haven't refreshed the tab after a browser restart. In case you make a new edit and save the CSS, the missing parts are lost permanently.

It would be very useful if the editor could force a reload of its content stored in the database after a browser restart.




Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Hi Erik

Thanks for describing the issue in detail, I understand what the problem is you are describing, but can I clarify something before discussing with the Layouts team.

In a browser tab you make changes to the custom CSS.

Two questions.

1. Do you have any other tabs open on the same page?

2. Are we talking about unsaved changes, and when you close and re-open the tab it reverts to the previously saved version? Or, at the time you close the browser any changes have been saved, and then the browser re-opens the tab with an earlier state of the page before you saved the changes?

Actually, a third question.

3. Do you use Firefox exclusively or have you observed the same in other browsers?


Hi Nigel,

1. I am not 100% certain but quite sure I had the Layouts CSS editor open in one tab only. Good question though, I will pay special attention to that next time.

2. I was talking about saved changes.

3. I use Firefox as my main development browser, mainly because I prefer the Inspect Element function over Chrome's. (Even after Firebug is discontinued). I have not observd this in other browsers, as I have not been working with toolset in other browsers.


I have just replicated the issue. I had added some css to the Layouts CSS editor and I had saved this. Then I shutdown my browser (Firefox). After reopening I noticed the last changes were not in the CSS editor. I checked the newest file in wp-content/uploads/ddl-layouts-tmp folder and saw the missing lines were saved there.
I compared the file in the Layouts CSS editor with the last saved files in the wp-content/uploads/ddl-layouts-tmp folder using file compare in Notepad++. I noticed the file in the Layouts CSS editor matched the 3d newest (!) file in the wp-content/uploads/ddl-layouts-tmp folder.
Hope this helps debugging this error.



Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Hi Erik

Thanks for the detailed update, that is really useful.

I'm going to try to replicate the issue locally, and, in any case, will discuss it at the morning Layouts team meeting to get their opinion.

I'll keep you posted.



Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Hi Erik

I discussed this with the Layouts team this morning, and they say there is not much they can do about it, it relates to how the browser builds its caches.

In testing this myself I found that when you re-open the tab which has an older cached version of the custom CSS on the page, you simply need to do a page refresh and the page will update with the correct, current, version of your custom CSS.

Alternatively, when you make changes to the custom CSS and save them, if you refresh the browser at any point before closing the tab, then the tab will re-open with the correct content.

If you use an extension such as cache disabler (or cache killer for Chrome) it will prevent this from happening as it won't load the page from the cache.


Is it not possible to force a page refresh when the tab is opened after a browser restart? I know other applications that do just this. For example: I use InfiniteWP (an open source admin panel for multi WP site maintainance). I have this tab always in my Firefox browser. When I restart the browser and selct the InfinitWP tab, the tab starts automatically reloading the data from the websites I manage. I haven't yet reverse-engineerd this, but I presume this can be done with Javascript/jQuery.

The thing is that leaving it this way forces users to change their behaviour, i.e. make it a habit to always refresh the tab before continuing editing. Because if you don't, the previous edits are lost and you end up with a css file that has lost previous edits. I know I forget this sometimes.



Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Hi Erik

I spoke with the Layouts team who were reticent about introducing a browser history management system but did say that they would be willing to add an action hook that is triggered when the custom CSS editor is saved so that you could use that to trigger a page reload with a snippet of custom code.

When I hear back from them with the details of that hook I will provide you with the code required.

Thanks for your patience.


This is a feature request, that has been added to our list.

I suggest to close this ticket as I cannot state any ETA on this.




Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

Let me update here to say that this issue was fixed in the recent update to Layouts 2.2